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

Глава 6. TeleDoc

Глава 6. TeleDoc

Russia. Examples.

Сразу предупреждаю: сам не видел, а только слышал от местных жителей. Своими глазами видел только ту глухомань, по которой течет река Молога, да ту деревню Горки, километров 20 выше по течению от моего Гузеево, о которой пойдет речь.

Молога счастливо избежала участи многих подмосковных речек, превратившихся в сточные канавы для отходов советских промышленных предприятий. Наверное, просто потому, что и предприятий-то таких там особо и нет, кое-что, конечно, сливают, но сравнительно немного. А потому и рыба пока еще водится, хотя ловят ее иногда не с помощью примитивных удочки, мережи, сети, а электроудочкой. Выезжают ночью на лодке с аккумулятором, от которого питается автомобильная фара, и свет от этой фары направляют на воду. Рыба, в том числе и крупная, плывет на свет, тут и бьют по ней колом, оглушают и ловят подсачеком. Просто и понятно, снасти тоже доступные для местных жителей. С обычной удочкой после такой ловли на реке неделю делать нечего.

Но даже при такой ловле еще остается на Мологе достаточно рыбы и иногда можно поймать крупный экземпляр щуки, судака, леща, язя. Но речь сейчас пойдет не о них, а о соме.

Около деревни Горки на Мологе были омута, в которых водились сомы. Сом – это нечто вроде поросенка, всеядный, ему можно скармливать любые отходы, и вот вся деревня Горки дружно взялась откармливать одного сома. Все знали место, куда он приплывает на откорм, и сом всегда находил там чем поживиться. Так прошло все лето, а ближе к осени сома решили выловить.

На трактор «Беларусь» приспособили лебедку с крюком от тракторного прицепа, насадили на нее наживку и закинули в омут, в место сомовьего откорма. Доверчивый сом, не ожидая от людей такой подлости, по старинке схватил съестную подачку, а трактор «Беларусь» взревел своим мотором.

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

End of example.

Автоматизированная система электронного документооборота прижилась в W-банке. Начальство и простые сотрудники почувствовали ее удобство и постепенно она стала охватывать все новые и новые сферы деятельности в банке. Сначала ей доверяли самые простые банковские документы – статистические отчетности, балансы, различные банковские формы, затем перевели на нее платежные документы, подтверждения векселей, паспорта валютных сделок и еще много всяких других документов, о существовании которых мне, непосвященному в тонкости банковских технологий человеку, никогда не приходилось раньше слышать. Для нее придумали специальное название – TeleDoc – и оно также прижилось в банке. Название это появилось не сразу, сначала были различные варианты: Криптоцентр-V, Омега, но в конце концов выбрали TeleDoc. Тут еще приходилось учитывать российскую специфику: сертификата ФАПСИ на эту систему, естественно, не было, приставку «крипто» в названии лучше не упоминать. Десятки раз мы обсуждали эту проблему с В.К. Тяпкиным, но всякий раз единогласно приходили к выводу – соваться в ФАПСИ по этому поводу – бесполезно. Финансовые затраты на проведение подобной экспертизы будут сопоставимы со стоимостью ее разработки, а гарантии положительного результата никакой нет. И не потому, что система плохая, нестойкая, с какими-то «дырами» и т.п., нет, здесь банк был сам заинтересован в гарантированной стойкости, поэтому все криптографические и программные решения, перед тем, как их использовать в TeleDoc, неоднократно обсуждались и проверялись с Тяпкиным и управлением безопасности банка. Проблема была в другом – сертификатов в то время (1996 – 1998 гг.) не выдавали практически никому, кроме Московского филиала Пензенского НИИ Автоматики, которому патронировал Генеральный директор ФАПСИ, сам выходец из Пензы. Сертифицированные конкуренты были ни к чему, а создать систему зажима для чиновников, особенно в такой сфере, как криптография – привычное дело. Поэтому даже постановка вопроса в ФАПСИ о сертификации TeleDoc вынудила бы меня длительное время заниматься подготовкой различных справок, описаний, разрешений и прочих чиновничьих премудростей, а развитие самой системы при этом бы застопорилось. Но самое главное, что вся эта суета оказалась бы бесполезной и даже вредной: сертификата получить заведомо нельзя, можно только «засветиться», раздразнить ФАПСИшных «гусей».

Систему TeleDoc, под именем Омега, я подробно описал в книге «Практическая криптография», и если читатель заинтересуется связанными с ней техническими подробностями, то там он сможет найти полную документацию по этой системе. Здесь же я постараюсь описать наиболее интересные перипетии ее создания в условиях суровой российской действительности.

Первая DOS-версия TeleDoc (TeleDoc-1) просуществовала в банке с 1995 по 1998 года, она, конечно же, была немного неуклюжей, но честно отрабатывала положенные ей функции. Следующая версия (TeleDoc-2) разрабатывалась уже под Windows 32 и была намного более совершенной: в ней появились специализированные базы данных входящих и исходящих документов, специальный интерфейс для работы с ними, различные автоматические режимы, системы централизованного управления и прочая, прочая, прочая. Все это шаг за шагом добавлялось, накапливалось в реально действующей, «боевой» системе без нарушения производственного цикла банка, без задержки документооборота хотя бы на день. Мне нравилась система взаимоотношений, установленных с банком: составляется Техническое задание на год, в котором прописываются самые общие требования к разработке. Все конкретные текущие вопросы, возникавшие у меня при написании программ, оперативно решались с Тяпкиным по телефону без дополнительных бумаг. Примерно раз в неделю – встреча в банке, я привожу им свои программы, они их проверяют, дают свои замечания. В конце года ТЗ принимается, после чего реально работающая в банке версия TeleDoc обновляется. В такой схеме взаимоотношений чиновничьих извращений было по-минимуму, а поэтому работать с банком мне было интересно. Ну а банк, в свою очередь, получал уникальную, разработанную под его требования систему по весьма низкой цене.

Как я уже отмечал выше, я никогда не состоял в штате банка. Все работы с банком осуществлялись от имени моей частной фирмы ИЧП «Альба», в которой самое главное было – наличие банковского счета. Других признаков предприятия – наличия офиса, секретарши, бухгалтера и вообще какого-то иного персонала, кроме директора, там не было. Но существенно было другое: такая схема взаимоотношений позволяла мне сохранять за собой права интеллектуальной собственности на разрабатываемые программы. Банк финансировал разработку, получал за это право неограниченного тиражирования программ, но у меня оставалась возможность самостоятельной продажи этих программ другим заказчикам. Более того, В.К.Тяпкин неоднократно повторял, что он всячески готов поддерживать мои поиски других заказчиков на TeleDoc, и реально оказывал мне в этом посильную помощь. Ведь самое трудное – объяснить потенциальному заказчику все особенности и преимущества подобной системы, а сделать это можно лучше всего на примере реально работающей системы в реальном банке.

Сколько раз я предлагал TeleDoc Центральному Банку! Не те времена, не те люди теперь там были. «Несертифицировано!» – вот и весь разговор. Чиновники везде одинаковы, минимум перемен, минимум новизны, минимум ответственности. Вообще-то банковская структура должна быть разумно консервативной, но где провести ту грань разумности? Некоторые эпизоды из жизни ЦБ, которые мне пришлось наблюдать, были явно за этой гранью.

Упоминавшаяся выше моя программная система «Криптоцентр-АВИЗО», не имевшая сертификата ФАПСИ, успешно работала уже около 3 лет в двух крупных подразделениях ЦБ: Центральном Операционном Управлении (ЦОУ) и в ОПЕРУ-1. Но навязчивая идея руководства ФАПСИ прибрать к рукам ЦБ постепенно привела к мысли заменить все несертифицированное программное обеспечение сертифицированным. Казалось бы, нет ничего проще: опробованная, успешно работающая программа посылается на сертификацию, проводится ее экспертиза, по результатам которой делаются возможные доработки, устраивающие как экспертов, так и реальных пользователей. Но это – в теории, на практике, в реальной жизни все не так. «Сделаем свою программу и насильно заставим всех в ЦБ ее использовать» – так решило это могучее Ведомство.

ОПЕРУ-1 ломать налаженные технологии и использовать ФАПСИшное творение отказалось наотрез. В конце концов чиновники ЦБ уступили напору этих девушек, обслуживающих счета всех крупнейших государственных организаций, в том числе и самого ФАПСИ. А вот ЦОУ (точнее, его руководство) сдалось, безропотно разломало все что я у них налаживал за эти годы. Потом мне довелось встретить в ЦБ девушку-операционистку из ЦОУ, которая работала с моей программой, и она, чуть не плача, поведала мне о своей новой жизни в условиях ФАПСИшного сервиса.

Ни разу и ни от кого за все мое посткгбэшное время я не слышал положительных отзывов о ФАПСИ. Везде одно и то же: запретить, навязать свое, которое работает хуже, зато сертифицировано. А от ребят, оставшихся дослуживать в этой Конторе, приходилось слышать: «Гниет там народ, интересной работы нет, многие просто спиваются». Зато административного ража, желания «всех пригнуть», подчинить, заставить кланяться – хоть отбавляй. Один раз газета «Московский комсомолец» в коротенькой заметке поведала, что ФАПСИ активно проталкивает идею оснащения всех контрольно-кассовых машин (любимых всеми торговцами ККМ) автоматической системой электронной подписи. Якобы меньше будет уклонений от налогов. А мне сразу представляется такая картина: по какому-нибудь вещевому или продуктовому рынку под ручку с розовощеким милиционером шагает ФАПСИшник с полными сумками. Электронную подпись проверял.

Не было у меня ни малейшего желания идти с системой TeleDoc на поклон к ФАПСИ. Я вложил в нее уйму труда, делал ее с удовольствием, ради удобства людей, ради внедрения своих идей, которым посвятил практически всю сознательную жизнь. Ведь, естественно, никаких криптографических алгоритмов типа ГОСТ или DES я в ней не использовал, только то, что выросло из «Ангстрема-3». Это все хорошо просчитано, основательно проверено, оригинальные криптографические решения. А такие оригинальные решения – это еще один рубеж защиты от потенциального злоумышленника, от различных продвинутых хакеров, научившихся воровать секретные ключи из оперативной памяти компьютера. И теперь объяснять все это чиновникам, мечтающим о контроле за вещевыми рынками?

Сейчас прошло уже почти 10 лет с момента появления первой версии TeleDoc и можно оценить, что же в ней было сделано правильно, а что, наоборот, не выдержало проверки временем и немного порассуждать о перспективах развития подобных систем. На мой взгляд, первая основная особенность TeleDoc – нестандартный криптографический интерфейс. Что это означает?

Работы по созданию мировых стандартов криптографического интерфейса велись с начала 90-х годов, и где-то к середине 90-х уже появились первые результаты. Если разработчик программного обеспечения хочет использовать в своих программах криптографические функции шифрования и электронной подписи, то для этих целей Microsoft подготовил и внедрил в Windows начиная с Windows-95 специальный интерфейс – CAPI – Cryptography Application Programming Interface. Этот интерфейс использует для выполнения криптографических операций динамические библиотеки, удовлетворяющие определенным требованиям Microsoft. Такие библиотеки принято называть еще CSP – Cryptography Service Provider. Для разработчика программного обеспечения вся прелесть технологии CAPI-CSP в ее универсальности, возможности выбора различных CSP от различных производителей, и возможность использования всех других богатых интерфейсных возможностей, предоставляемых пользователям Microsoft. Например, для организации закрытой электронной почты (когда письма отправляются в зашифрованном виде и с электронной подписью) достаточно, например, в таких известных почтовых программах, как Microsoft Outlook или Microsoft Outlook Express использовать встроенные в них возможности технологии CAPI-CSP. Таким образом, простейший путь к созданию системы защищенного электронного документооборота – использование уже готовых решений Microsoft и стандартного интерфейса CAPI-CSP.

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

При смене ключей все эмоции отбрасываются, работают чисто математические рассуждения и модели. Зачем проводится смена ключей? Для ликвидации возможных последствий компрометации каких-то ключей. А можно ли при смене ключей новый секретный ключ шифровать с помощью старого? Эмоции в сторону, считаем все ключи скомпрометированными и вся информация, обрабатываемая с их помощью, доступна потенциальному злоумышленнику. А тогда ему становятся доступными и новые ключи, зачем же в этом случае затевать столь дорогостоящую и трудную операцию по их смене? Следовательно, шифровать новый ключ с помощью старого нельзя, в этом случае смена ключей не может дать 100% гарантии безопасности.

Но банк большой, ключевая система, по его требованию, централизована, т.е. выработка почти всех секретных ключей осуществляется в Москве, в центральном офисе банка, а филиалы есть во Владивостоке и на Камчатке. Как бы удобно было не посылать людей за дискетами с новыми секретными ключами из Владивостока в Москву, а выработать ключи на месте или, на худой конец, выслать им файлы по электронной почте! Но выработка секретных ключей на местах почему-то не устраивала W-банк, управление безопасности считало централизованную выработку более безопасной и надежной. И вот тогда появилась идея рассылки секретных ключей по электронной почте, при которой новые ключи шифруются с помощью абсолютно стойкого шифра – случайной и равновероятной одноразовой гаммы. Здесь, конечно же, тоже возникали организационные сложности, связанные с одноразовой гаммой, но одной дискеты с такой гаммой должно было хватить филиалу на все смены ключей в течение 50 лет. Идея была очень заманчивой, более того, уже реализованной в виде специального программного обеспечения, которое оставалось только применить на практике. Но тут энтузиазм банка почему-то угас, до практического внедрения рассылки секретных ключей дело так и не дошло. Видимо, успешно работающая система защищенного электронного документооборота стала для банка большой ценностью, которую он не хотел подвергать каким-то дополнительным испытаниям, опасаясь при этом возможных сбоев и нарушений производственного процесса.

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

Оглавление книги