Криптография и свобода
Шрифт:
Сколько раз я предлагал 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,
Была и еще одна весомая причина, по которой в 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.