Проблемы использования электронной цифровой подписи в банковских системах

БЕЗОПАСНОСТЬ

После двух лет подготовительной работы закон об электронной цифровой подписи (ЭЦП) в конце прошлого года стремительно прошел через Государственную Думу, Совет Федерации и 10 января 2002 г. был подписан президентом. Многие законодатели, правительственные чиновники, политические деятели - словом, все неспециалисты в данной области, имевшие возможность высказаться, выражали единодушное одобрение по этому поводу, подчеркивая, что Россия практически не отстает от развитых стран по срокам принятия подобного закона и получает мощный импульс для развития самых современных электронных технологий.

К сожалению, технические специалисты не столь оптимистичны в своих оценках. Встать на верный путь - еще не значит быстро двигаться по нему. Принятие этого закона было необходимым, но не достаточным условием для ускорения развертывания в России электронных технологий с применением ЭЦП. К тому же, очевидно, что любой закон, содержащий не вполне удачные формулировки, может не только не ускорить, но даже затормозить процессы, которые он регламентирует.

Рассмотрим, например, использование ЭЦП с точки зрения обслуживания рядовых граждан. В Германии после вступления в силу в мае 2001 г. закона об ЭЦП началась реализация программы Bund-Online-2005, направленной на создание так называемого “электронного государства”. По этой программе граждане смогут к 2005 г. с помощью персональных смарт-карт, содержащих закодированную ЭЦП, улаживать в онлайне около 1200 различных бюрократических вопросов, вплоть до получения водительских прав через сеть. В ближайшие годы из федерального и земельных бюджетов выделяется на достижение этой цели 12 млрд. марок. Выдвинутая же федеральная целевая программа “Электронная Россия на 2002-2010 годы” носит гораздо менее определенный характер и пока практически не финансируется, что не позволяет ожидать существенных сдвигов на этом направлении в ближайшие годы.

Стимулирование электронного бизнеса немыслимо без применения ЭЦП, но здесь возникают две группы проблем:

1) юридические, связанные с ограничительным характером некоторых положений закона об ЭЦП, в частности проблемы правомочности ЭЦП (она признается равнозначной только личной подписи, а для признания ее эквивалентной подписи и печати по-прежнему требуется письменное соглашение между сторонами), а также использования иностранных криптоалгоритмов ЭЦП;

2) технические, связанные с несовместимостью в общем случае ПО разных отечественных производителей, которое реализует функции удостоверяющих центров ЭЦП, и выпуском цифровых сертификатов на базе российского криптоалгоритма ГОСТ Р 34.10-94, а также с применением этих сертификатов.

В целом ситуацию с ЭЦП в сфере электронного бизнеса в России можно охарактеризовать как многообразие выбора при отсутствии единых подходов даже при реализации типовых схем в одной и той же области, другими словами - как технологический хаос.

Иллюстрацией к вышесказанному является положение в банковской сфере, где ЭЦП применяется наиболее интенсивно.

Каждый банк, стремящийся использовать современные технологии, имеет основанную на ЭЦП электронную расчетную систему обслуживания крупных клиентов (юридических лиц) типа “банк - клиент”. Банк заключает с клиентом соглашение, оговаривающее условия обслуживания и взаимного признания ЭЦП. После этого на выделенном компьютере клиента банковский специалист устанавливает соответствующий программный модуль системы и начинается обмен информацией в электронном виде. Клиент через сеть распоряжается своим банковским расчетным счетом, отсылая платежные поручения и заявки на другие операции, подписанные двумя ЭЦП - главного бухгалтера и руководителя. От банка поступает в основном информация справочного характера о состоянии счета клиента. Таким образом, схема построения системы достаточно проста и единообразна для всех банков, чего нельзя сказать о ее реализации.

Некоторые российские банки строят свои системы на западном алгоритме ЭЦП (RSA) и на различных программных пакетах иностранных производителей. Но большинство ориентируется на применение российского стандарта ЭЦП (алгоритма Р 34.10-94) и ПО отечественных производителей с разными характеристиками и интерфейсами. Процедура ЭЦП реализуется на базе цифровых сертификатов (как на основе общепризнанного международного формата сертификатов Х.509, так и специфических внутренних форматов) или самым элементарным образом на основе ведения на банковском сервере базы данных открытых ключей клиентов без их сертификации в электронном виде.

Около трети банков, к сожалению, не уделяют должного внимания процедуре разбора конфликтных ситуаций с использованием ЭЦП. Они либо не имеют документа, определяющего порядок разрешения разногласий, что затрудняет работу согласительной комиссии, либо не заверяют открытые ключи сторон в виде, доказательном для арбитражного суда, а это не дает возможности провести объективное судебное разбирательство. Если, например, распечатанный на бумаге открытый ключ ЭЦП с указанием его принадлежности, подписями и печатями обеих сторон вполне убедителен даже при судебном разбирательстве, то вариант, когда стороны обмениваются дискетами с копиями своих открытых ключей в опечатанных конвертах, хорош только на этапе согласительной комиссии.

Кроме того, некоторые банки строят эксплуатацию своих систем по принципу “защитим финансовые интересы клиента от внешних злоумышленников, а со стороны банка ему ничто не грозит”, хотя у клиента может быть другое мнение по данному вопросу. Неприятность состоит в том, что клиенты, не имеющие в штате экспертов по информационной безопасности, просто не догадываются о том риске, которому они подвергаются. Имеется в виду ситуация, когда для упрощения процесса инсталляции и эксплуатации системы банк поставляет клиенту на своих носителях уже сгенерированные пары открытых и секретных ключей ЭЦП клиента. При этом клиенту, как правило, предоставляется возможность самостоятельной смены пароля для контейнера своего секретного ключа. Это, по логике банка, исключает злоупотребления с его ЭЦП. Подобная методика не выдерживает критики.

Клиенту следует четко осознавать, что пара ключей его ЭЦП (открытый и секретный) должна быть сгенерирована не на банковском сервере, а на его компьютере с помощью инсталлированного банком клиентского модуля, причем далее для заверения банку должна передаваться только копия открытого ключа.

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

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

Справедливости ради необходимо сказать, что указанные выше недостатки характерны для работы не только российских банков. Изучение текстов аналогичных договоров и технических условий использования электронных систем иностранных банков, имеющих филиалы в России, позволяет сделать любопытные выводы. Западные банки достигли впечатляющей унификации в области применяемого ПО. Более чем в 1700 банках мира в качестве электронной расчетной системы типа “банк - клиент” принят пакет MultiCash (с алгоритмом RSA для ЭЦП). Это предоставляет клиентам возможность стандартизованного обмена информацией с разными банками как для отправки платежных инструкций, так и для целей отчетности. (Российские банки если и не считают делом чести создать собственную уникальную систему, то во всяком случае мало заботятся об унификации.) Однако клиент российского филиала иностранного банка в среднем более ограничен в различных аспектах своих прав. Достаточно упомянуть, что в стандартных договорах иностранных банков не всегда присутствует ключевая юридическая фраза о взаимном признании сторонами эквивалентности электронных документов, подписанных корректными ЭЦП, их бумажным аналогам, что с формальной точки зрения может послужить поводом для арбитражного суда отказать в разбирательстве иска по конфликтной ситуации.

Вернемся к российским банкам и рассмотрим ситуацию с точки зрения удобства работы клиента. Когда клиент имеет расчетные счета в нескольких банках, то наличие разных электронных расчетных систем с различными пользовательскими интерфейсами, с отдельными ключами ЭЦП и шифрования на разных носителях порождает ошибки и недоразумения (пропорционально числу задействованных систем). Для клиента было бы идеально использовать для связи с разными банками один и тот же программный пакет и одну и ту же ЭЦП, т. е. достижение полной унификации банковских операций. Закон об ЭЦП предоставляет теоретическую возможность добиться этого в отношении электронной подписи: юридическое лицо может получить в федеральном удостоверяющем центре цифровой сертификат ЭЦП, который в соответствии с законом должен признаваться не только при проведении всех банковских операций, но и при подписи вообще любых электронных документов. При этом необходимость заверения открытого ключа клиента в конкретных банках отпадает. Беда в том, что для отечественного алгоритма ГОСТ Р 34.10-94 все упирается в несовместимость разнородного ПО, в данном случае - банковского. А для алгоритма RSA все обстоит наоборот - по этому алгоритму совместимость сравнительно легко достижима, но сертификационный центр ЭЦП, выдающий сертификаты на RSA, не сможет получить лицензии и статуса удостоверяющего центра, поскольку по закону обязан внести в федеральный реестр свой собственный самоподписанный сертификат, а для RSA это невыполнимо, т. к. федеральный реестр будет вестись в соответствии с законом только для отечественного стандарта ЭЦП. До тех пор, пока электронная расчетная система коммерческого банка остается замкнутой, т. е. корпоративной, в ней могут использоваться любые криптоалгоритмы по усмотрению банка, но если ее пользователи выходят на межбанковский уровень, то начинают действовать требования закона в отношении информационных систем общего пользования, что резко усложняет ситуацию.

Подводя итоги, можно сказать, что с точки зрения использования ЭЦП российская банковская сфера напоминает страну, раздробленную на удельные княжества, в каждом из которых жизнь течет по своим законам. Приходится констатировать, что, как ни парадоксально, в преодолении раздробленности гораздо больше заинтересованы клиенты, чем сами банки, не меняющие без крайней необходимости дорогостоящее ПО, а это не может не наводить на грустные размышления относительно перспектив.

Что касается ситуации с применением электронных технологий, базирующихся на ЭЦП, в целом в коммерческой сфере, то пройдет еще немало времени, прежде чем юридический успех с принятием закона об ЭЦП будет поддержан успехами технологическими. Достаточно заметить, что пока ни одна государственная структура не взялась за координацию действий фирм-производителей соответствующего ПО и за выработку недостающих стандартов для обеспечения совместимости ПО, оперирующего с ЭЦП на отечественном алгоритме. Сертификаты ФАПСИ на программные модули гарантируют в соответствии с функциями лицензионного центра ФАПСИ только правильность реализации криптоалгоритмов, случайность генерации ключей и т. п., но никак не совместимость с другими сертифицированными пакетами.

С автором статьи, главным специалистом ОАО “Аэрофлот” по вопросам информационной безопасности, можно связаться по адресу: vnpnmrv@ok.ru.