Была и еще одна весомая причина, по которой в TeleDoc я стал использовать оригинальный криптографический интерфейс. Это – надежность, устойчивость работы системы в огромной сети W-банка. Собственный криптографический интерфейс – это исходные тексты программ, с помощью которых затем можно разобраться практически в любой сбойной ситуации, понять причину сбоя и устранить ее. Такие ситуации неоднократно возникали на практике, во время повседневной эксплуатации TeleDoc в W-банке. Одну такую ситуацию в банке прозвали «черной дырой» и для того, чтобы понять и устранить ее причину, потребовалось больше года. Дело в том, что к тому времени почтовые «аппетиты» W-банка выросли, дорогостоящая Sprint-Net перестала его удовлетворять, TeleDoc уже достаточно прижился и потихоньку созревал для собственной почтовой системы с использованием протоколов SMTP и POP3. Но пока он созревал, W-банк закупил специальную почтовую систему Pegasus mail, которая также использовала эти же протоколы. Когда же TeleDoc дозрел, то в качестве наказания за долгое дозревание ему была поставлена задача: обеспечить совместимость с Pegasus mail. Все бы ничего, дело нехитрое, протоколы-то одни и те же, но только вот тогда и появилась эта проклятая «черная дыра».
Вся информация, передаваемая из Центра в филиалы, отправлялась с помощью почтовой системы Pegasus mail (TeleDoc осуществлял только подготовку к отправке, включая шифрование и подпись), а в филиалах принималась по протоколу POP3 с помощью внутренней почтовой системы TeleDoc, а критерием успешного приема была проверка электронной подписи. Все принималось успешно, за исключением «черных дыр», которые регулярно возникали в разных филиалах примерно один раз в три месяца. На этих «черных дырах» проверка подписи давала отрицательный результат, повторная отправка, проводимая как в автоматическом, так и в ручном режиме, давала то же самое, случайные искажения на линии связи были исключены, управление информатики звонило мне домой, как к главному экстрасенсу, специалисту по черной программной магии, и просило, по возможности, расколдовать эти заколдованные мессаджи.
Вылавливать и исправлять различные программные глюки – это занимает едва ли не 90% времени разработчика-программиста. Но для того, чтобы это успешно сделать, необходимы какие-то исходные точки анализа: глюк должен быть устойчивым, регулярно повторяться, обладать какими-то закономерностями. Причинами глюка, чаще всего, являются ошибки в программе (программ без ошибок, так же как и абсолютной истины, не бывает), но иногда могут быть и конфликты с какими-то другими работающими программами, неверное распределение памяти, некорректное использование внешних устройств и куча всяких иных причин. Здесь же глюк был какой-то случайный, проявлялся редко и в различных ситуациях. Банк по-своему находил из него выходы: информация, содержавшаяся в «черных дырах», перекладывалась в другие пакеты и в них уже благополучно доставлялась по назначению. А я на все вопросы о возможных причинах этого глюка просил дополнительной конкретной информации: содержания пакета при отправке и при приеме (это сложно сделать, все автоматизировано и доступен только конечный результат), чем он отличается от других пакетов (ничем – такой был стандартный ответ), каких-то других «зацепок», по которым можно было бы понять причину глюка. Банку проще было раз в три месяца смириться с глюком, чем ковыряться с причинами его возникновения, и так прошел почти год.
В конце концов одна энергичная девушка из какого-то филиала все-таки дожала управление информатики банка по поводу этого глюка. Какими-то правдами или неправдами в банке смогли выловить то, что выдавал при глюке в канал связи Pegasus mail и что принимали в филиале. И оказалось, что есть различия! Тут уже у меня появилась конкретная пища для размышлений и в конце концов причина была выявлена: несоответствие в одном редком случае результатов кодировки MIME, осуществляемой Pegasus mail и внутренними процедурами, используемыми в моем любимом Borland C++ Builder v.3.0. Немного домыслив, мне пришлось слегка модернизировать процедуру приема, чтобы исправить эти огрехи.
Программист никогда не может считать себя застрахованным от подобных ситуаций.
Готовые чужие программы, к которым нет исходного текста, – это, как говорят в математике, «черный ящик», слепо верить тому, что все в нем работает так, как утверждается в его документации – можно, но осторожно. А вообще, при таких ситуациях лучше руководствоваться этически может быть и не совсем корректной, но математически очень правильной и надежной логикой: никому и ничему не верю, пока не проверю все сам. Даже если под словом «чужие программы» понимаются программы, созданные столь уважаемой и даже, более того, обожаемой мною фирмой Borland.
А в целом, оригинальный криптографический интерфейс позволил, как это ни странно, ускорить разработку TeleDoc и быстрее добиться его устойчивой работы. Ведь технология CAPI-CSP в то время также была еще новой, хорошую документацию по ней найти было очень сложно, поэтому то время, которое потребовалось бы мне чтобы разобраться во всех ее тонкостях и деталях, могло бы оказаться весьма и весьма значительным.
Но оригинальный криптографический интерфейс требовал и оригинальной ключевой системы: системы выработки секретных и открытых ключей, системы подтверждения подлинности открытых ключей, их рассылки и смены. Здесь Microsoft также предлагает всем разработчикам использовать свои стандартные решения: различные форматы файлов с секретными ключами, сертификаты открытых ключей и сертификационные центры для распределения открытых ключей. Но во время разработки первых двух версий TeleDoc все это также находилось еще в зачаточном состоянии, а поэтому, пожалуй, единственным способом обеспечения устойчивой работы системы распределения ключей в огромной сети W-банка была разработка оригинального программного обеспечения для менеджера системы распределения ключей.
Эта система честно отрабатывала установленные ей W-банком функции: примерно раз в полгода в час «Х» проводила полную смену всех ключей у всех пользователей TeleDoc в банке. И это было довольно разумное требование: банк – большой организм, какие-то сотрудники, работавшие с TeleDoc, за полгода могли уволиться, потерять свои секретные ключи, ценность самой информации, обрабатываемой с помощью TeleDoc, за полгода менялась, в общем периодическая полная смена всех ключей была одним из весьма существенных элементов информационной безопасности банка. И в конце концов эта весьма непростая операция стала проходить в банке спокойно, без сбоев и нарушений непрерывного процесса электронного документооборота. Но одну интересную возможность системы TeleDoc при смене ключей банк так и не использовал – это рассылку по электронной почте новых секретных ключей.
При смене ключей все эмоции отбрасываются, работают чисто математические рассуждения и модели. Зачем проводится смена ключей? Для ликвидации возможных последствий компрометации каких-то ключей. А можно ли при смене ключей новый секретный ключ шифровать с помощью старого? Эмоции в сторону, считаем все ключи скомпрометированными и вся информация, обрабатываемая с их помощью, доступна потенциальному злоумышленнику. А тогда ему становятся доступными и новые ключи, зачем же в этом случае затевать столь дорогостоящую и трудную операцию по их смене? Следовательно, шифровать новый ключ с помощью старого нельзя, в этом случае смена ключей не может дать 100% гарантии безопасности.
Но банк большой, ключевая система, по его требованию, централизована, т.е. выработка почти всех секретных ключей осуществляется в Москве, в центральном офисе банка, а филиалы есть во Владивостоке и на Камчатке. Как бы удобно было не посылать людей за дискетами с новыми секретными ключами из Владивостока в Москву, а выработать ключи на месте или, на худой конец, выслать им файлы по электронной почте! Но выработка секретных ключей на местах почему-то не устраивала W-банк, управление безопасности считало централизованную выработку более безопасной и надежной. И вот тогда появилась идея рассылки секретных ключей по электронной почте, при которой новые ключи шифруются с помощью абсолютно стойкого шифра – случайной и равновероятной одноразовой гаммы. Здесь, конечно же, тоже возникали организационные сложности, связанные с одноразовой гаммой, но одной дискеты с такой гаммой должно было хватить филиалу на все смены ключей в течение 50 лет. Идея была очень заманчивой, более того, уже реализованной в виде специального программного обеспечения, которое оставалось только применить на практике. Но тут энтузиазм банка почему-то угас, до практического внедрения рассылки секретных ключей дело так и не дошло. Видимо, успешно работающая система защищенного электронного документооборота стала для банка большой ценностью, которую он не хотел подвергать каким-то дополнительным испытаниям, опасаясь при этом возможных сбоев и нарушений производственного процесса.
