Криптография и свобода

Вылавливать и исправлять различные программные глюки – это занимает едва ли не 90% времени разработчика-программиста. Но для того, чтобы это успешно сделать, необходимы какие-то исходные точки анализа: глюк должен быть устойчивым, регулярно повторяться, обладать какими-то закономерностями. Причинами глюка, чаще всего, являются ошибки в программе (программ без ошибок, так же как и абсолютной истины, не бывает), но иногда могут быть и конфликты с какими-то другими работающими программами, неверное распределение памяти, некорректное использование внешних устройств и куча всяких иных причин. Здесь же глюк был какой-то случайный, проявлялся редко и в различных ситуациях. Банк по-своему находил из него выходы: информация, содержавшаяся в «черных дырах», перекладывалась в другие пакеты и в них уже благополучно доставлялась по назначению. А я на все вопросы о возможных причинах этого глюка просил дополнительной конкретной информации: содержания пакета при отправке и при приеме (это сложно сделать, все автоматизировано и доступен только конечный результат), чем он отличается от других пакетов (ничем – такой был стандартный ответ), каких-то других «зацепок», по которым можно было бы понять причину глюка. Банку проще было раз в три месяца смириться с глюком, чем ковыряться с причинами его возникновения, и так прошел почти год.

В конце концов одна энергичная девушка из какого-то филиала все-таки дожала управление информатики банка по поводу этого глюка. Какими-то правдами или неправдами в банке смогли выловить то, что выдавал при глюке в канал связи Pegasus mail и что принимали в филиале. И оказалось, что есть различия! Тут уже у меня появилась конкретная пища для размышлений и в конце концов причина была выявлена: несоответствие в одном редком случае результатов кодировки MIME, осуществляемой Pegasus mail и внутренними процедурами, используемыми в моем любимом Borland C++ Builder v.3.0. Немного домыслив, мне пришлось слегка модернизировать процедуру приема, чтобы исправить эти огрехи.

Программист никогда не может считать себя застрахованным от подобных ситуаций.

Готовые чужие программы, к которым нет исходного текста, – это, как говорят в математике, «черный ящик», слепо верить тому, что все в нем работает так, как утверждается в его документации – можно, но осторожно. А вообще, при таких ситуациях лучше руководствоваться этически может быть и не совсем корректной, но математически очень правильной и надежной логикой: никому и ничему не верю, пока не проверю все сам. Даже если под словом «чужие программы» понимаются программы, созданные столь уважаемой и даже, более того, обожаемой мною фирмой Borland.

А в целом, оригинальный криптографический интерфейс позволил, как это ни странно, ускорить разработку TeleDoc и быстрее добиться его устойчивой работы. Ведь технология CAPI-CSP в то время также была еще новой, хорошую документацию по ней найти было очень сложно, поэтому то время, которое потребовалось бы мне чтобы разобраться во всех ее тонкостях и деталях, могло бы оказаться весьма и весьма значительным.

Но оригинальный криптографический интерфейс требовал и оригинальной ключевой системы: системы выработки секретных и открытых ключей, системы подтверждения подлинности открытых ключей, их рассылки и смены. Здесь Microsoft также предлагает всем разработчикам использовать свои стандартные решения: различные форматы файлов с секретными ключами, сертификаты открытых ключей и сертификационные центры для распределения открытых ключей. Но во время разработки первых двух версий TeleDoc все это также находилось еще в зачаточном состоянии, а поэтому, пожалуй, единственным способом обеспечения устойчивой работы системы распределения ключей в огромной сети W-банка была разработка оригинального программного обеспечения для менеджера системы распределения ключей.

Эта система честно отрабатывала установленные ей W-банком функции: примерно раз в полгода в час «Х» проводила полную смену всех ключей у всех пользователей TeleDoc в банке. И это было довольно разумное требование: банк – большой организм, какие-то сотрудники, работавшие с TeleDoc, за полгода могли уволиться, потерять свои секретные ключи, ценность самой информации, обрабатываемой с помощью TeleDoc, за полгода менялась, в общем периодическая полная смена всех ключей была одним из весьма существенных элементов информационной безопасности банка. И в конце концов эта весьма непростая операция стала проходить в банке спокойно, без сбоев и нарушений непрерывного процесса электронного документооборота. Но одну интересную возможность системы TeleDoc при смене ключей банк так и не использовал – это рассылку по электронной почте новых секретных ключей.