Михаил Масленников - Криптография и свобода

Но в первых двух версиях TeleDoc технология CAPI-CSP не используется. Первая версия – это DOS-версия, для DOS эта технология была еще в зачаточном состоянии, а вторая версия для Windows-32 разрабатывалась на основе первой версии TeleDoc, наследуя все ее свойства. Да и по времени разработки второй версии (98 год) – в то время технология CAPI-CSP не была еще так широко распространена.

Была и еще одна весомая причина, по которой в 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 при смене ключей банк так и не использовал – это рассылку по электронной почте новых секретных ключей.