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

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

Дефолт подкрался незаметно и проверил на прочность российские банки. Система взаимоотношений (и денежных расчетов) между банками свелась к простейшей формуле: «Никто никому не верит». А как быть в такой ситуации с прямыми электронными расчетами? Вот тут-то W-банку очень пригодилась система TeleDoc, автоматически посылающая подтверждение получения, заверенное электронной подписью получателя. W-банк окончательно поверил в TeleDoc.

Глава 7. Частное предприятие

Russia. Examples.

То лето выдалось в Гузеево жарким и сухим. Дождей не было чуть ли не два месяца, болота в лесу все высохли и, как обычно, начались пожары. Потушить горящее торфяное болото практически невозможно, огонь уходит вглубь, тлеет, а затем разгорается вновь. Так и будет это болото тлеть до осени или даже до зимы, пока осенние дожди или снег основательно не пропитают его водой. Люди в такой ситуации могут лишь немного притушить огонь, не давать ему выйти на поверхность, не допустить верхового пожара. Но все равно, ходить по лесу невозможно, дым разъедает глаза, нечем дышать, ветра нет. Этот дым окутывает и близлежащие деревни, но там днем все-таки появляется ветерок и хоть немного его рассеивает. Но на ночь все равно приходится плотно закрывать все окна. Лучшее спасение – у реки, там ветра побольше, дыма поменьше.

И вот в один такой день мой 10-летний сын Антон со своим приятелем поехали на великах на рыбалку. Дорога на самые лучшие места шла вдоль реки, места им были хорошо знакомые и даже обжитые современной детворой. Каждый вечер они собирались здесь на тусовки, разводили костер, пекли картошку, приносили различные консервы. И вот в одном таком месте впереди метрах в 20 от их великов прямо на дорогу выбежал зверь, похожий, как он мне потом сам говорил, «на большую лохматую собаку». Это был медвежонок, настоящий, дикий. Они с медведицей, по-видимому, жили на болоте, но пожары вынудили их покинуть места своего привычного обитания и отправиться на поиски менее дымных мест. А река их очень даже устраивала: не так много дыма и на берегу – еда, остатки консервов от человечьих тусовок.