Криптография и свобода
Шрифт:
Как я уже отмечал выше, я никогда не состоял в штате банка. Все работы с банком осуществлялись от имени моей частной фирмы ИЧП «Альба», в которой самое главное было – наличие банковского счета. Других признаков предприятия – наличия офиса, секретарши, бухгалтера и вообще какого-то иного персонала, кроме директора, там не было. Но существенно было другое: такая схема взаимоотношений позволяла мне сохранять за собой права интеллектуальной собственности на разрабатываемые программы. Банк финансировал разработку, получал за это право неограниченного тиражирования программ, но у меня оставалась возможность самостоятельной продажи этих программ другим заказчикам. Более того, В.К.Тяпкин неоднократно повторял, что он всячески готов поддерживать мои поиски других заказчиков на 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.