Технология работы с информационной системой ЭЦП

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

В случае, если электронная подпись используется в критичных приложениях (например, для выполнения юридически значимых действий), реализация криптоалгоритмов в обязательном порядке проходит процесс сертификации на соответствие требованиям безопасности. В «западном» мире широко используется сертификация решений на соответствие Common Criteria, в России процесс сертификации средств криптографической защиты проводит ФСБ России. Дополнительно, средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительных специализированных железок (Hardware Security Module, HSM).

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

Интерфейсы для доступа к СКЗИ На сегодняшний день широкое распространение получили один промышленный стандарт работы с СКЗИ и один (фактически два) проприетарный интерфейс всеми известной компании Microsoft.

PKCS#11.

PKCS#11 (Public-Key Cryptography Standard #11) — платформонезависимый программный интерфейс для работы с аппаратно реализованными СКЗИ: смарт-карты, HSM’ы, криптографические токены. Иногда PKCS#11 используется для доступа к программно реализованным криптографическим библиотекам.

PKCS#11 представляет собой довольно обширный документ, опубликованный RSA Laboratories, который описывает набор функций, механизмов, алгоритмов и их параметров для работы с криптографическими устройствами или библиотеками. В данном документе четко прописаны правила, в соответствии с которым будет работать прикладное программное обеспечение при вызове криптографических функций.

Данный стандарт поддерживается во многих open source-проектах, использующих криптографию. Для примера, Mozilla Firefox позволяет хранить сертификаты и закрытые ключи для аутентификации через SSL/TLS на токенах, работая с ними по PKCS#11.

Если прикладное программное обеспечение «умеет» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая наружу будет выставлять интерфейсы, описанные в стандарте, а внутри реализовывать необходимую СКЗИ логику: работа непосредственно с криптографическим устройством или реализация необходимых криптоалгоритмов программно. В этом случае прикладное программное обеспечение должно «подцепить» необходимую библиотеку и выполнять необходимые действия в соответствии с рекомендациями стандарта. Это обеспечивает заменяемость различных устройств и их библиотек для прикладного программного обеспечения и прозрачное использование СКЗИ в различных системах.

Единственным существенным минусом PKCS#11 является отсутствие рекомендаций по работе с сертификатами открытого ключа, что предполагает либо использование проприетарных расширений стандарта, либо использование других средств для работы с сертификатами.

Microsoft Crypto API 2.0.

Операционная система Microsoft Windows, независимо от версии, довольно сложная система, которая помимо всего прочего занимается вопросами обеспечения безопасности пользовательских и корпоративных данных. В этих задачах традиционно широко используется криптография.

С целью унификации доступа к криптографическим функциям компания Microsoft разработала проприетарный API: Microsoft Crypto API. Широкое распространение приобрела версия Crypto API 2.0. Парадигма Microsoft Crypto API базируется на использовании так называемых криптопровайдеров, или, по-русски, поставщиков криптографии.

Спецификация Crypto API описывает набор функций, которые должна предоставлять библиотека криптопровайдера операционной системе, способы интеграции с ней и спецификации вызовов. Таким образом, производитель СКЗИ, выполняющий правила Crypto API, имеет возможность интеграции своего решения в операционную систему Microsoft Windows, а прикладное программное обеспечение получает доступ криптографическим функциям посредством унифицированного интерфейса. Дополнительным плюсом является то, что компания Microsoft реализовала над Crypto API довольно большое количество функций, отвечающих за выполнение прикладных задач: работа с сертификатами, формирование различных видов подписи, работа с ключевой информацией и пр. Также Crypto API, как нетрудно догадаться, тесно интегрирован с операционной системой и ее внутренними механизмами.

Но расплатой за удобство становится платформозависимость и необходимость тесной интеграции решения в операционную систему.

В Windows Vista Microsoft представила новую версию криптографического программного интерфейса — Microsoft CNG (Cryptography API: Next Generation). Данный интерфейс базируется уже не на поставщиках криптографии, а на поставщиках алгоритмов и поставщиках хранилищ ключевой информации. В силу того, что распространенность Windows XP все еще довольно велика, CNG в прикладных системах используется крайне мало.

Проприетарные интерфейсы Наличие стандартизованных интерфейсов никогда не было препятствием для существования проприетарных библиотек со своими интерфейсами. Примером этому может служить библиотека OpenSSL, работа с которой осуществляется по собственным правилам. Стандарт PKCS#11 предполагает возможность использования проприетарных расширений. Фактически, это добавленные производителем функции, не описанные в стандарте. Обычно они служат для выполнения специфических операций с устройствами или реализуют необходимые, по мнению производителя, функции.

Форматы электронной подписи Описанные выше интерфейсы для доступа к криптографическим функциям позволяют обращаться за выполнением математических преобразований к различным, как хорошо было замечено Microsoft, «поставщикам криптографии».

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

Для решения этой задачи также предлагается ряд стандартов.

PKCS#7.

PKCS#7 (Public-Key Cryptography Standard #7), или CMS (Cryptographic Message Syntax) — стандарт, публикуемый и поддерживаемый все той же RSA Laboratories, описываемый синтаксис криптографических сообщений, также публикуется в качестве RFC с номером 2315.

Синтаксис CMS описывает способы формирования криптографических сообщений, в результате чего сообщение становится полностью самодостаточным для его открытия и выполнения всех необходимых операций.

С этой целью в PKCS#7 размещается информация об исходном сообщении (опционально), алгоритмах хеширования и подписи, параметрах криптоалгоритмов, времени подписи, сертификат ключа электронной подписи, цепочка сертификации и т. д.

Большинство атрибутов PKCS#7 являются опциональными, но их обязательность может определяться прикладной системой.

Отдельно следует отметить, что PKCS#7 позволяет ставить несколько подписей под одним документом, сохраняя всю необходимую информацию в сообщении.

Формирование и проверка PKCS#7 реализованы в криптографических «надстройках» в Microsoft Crypto API, речь о которых шла выше. Но сам формат довольно хорошо специализирован и его поддержка может быть реализована нативно.

XML-DSig.

W3C разработала и опубликовала рекомендации по составлению подписанных сообщений в формате XML.

Фактически XML-DSig решает те же вопросы, что и PKCS#7. Основное отличие в том, что в PKCS#7 данные хранятся в структурах, сформированных в соответствии с разметкой ANS.1 (фактически, бинарные данные), а в XML-DSig данные хранятся в текстовом формате в соответствии с правилами документа «XML Signature Syntax and Processing».

Область применения XML-DSig — веб-приложения и веб-сервисы.

Сырая подпись Описанные выше форматы электронной подписи необходимы при взаимодействии разнородных систем, когда информация об отправителе подписанного сообщения минимальна.

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

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

Это позволяет значительно упростить процедуры выработки и проверки подписи, так как отсутствуют шаги формирования и разбора сообщений в соответствии с каким-либо форматом.

Перспективы развития информационной системы.