Технологии Работы С Электронными Подписями

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

Встраивание электронных подписей в прикладные системы

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

Их криптографическая сила основана на математических задачах, которые невозможно решить за разумное время.

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

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

В «западном» мире широко используется сертификация решений на соответствие Единым критериям; В России процесс сертификации средств криптографической защиты осуществляет ФСБ России.

При этом средства криптографической защиты информации (СКЗИ, этот термин широко используется в РФ) могут иметь самое разное представление: от программных библиотек до высокопроизводительного специализированного оборудования (Аппаратный модуль безопасности, HSM).

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

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

Интерфейсы доступа к СКЗИ

Сегодня получили распространение один промышленный стандарт работы с СКЗИ и один (фактически два) фирменный интерфейс от известной компании Microsoft. ПККС#11 PKCS#11 (Стандарт криптографии с открытым ключом №11) — это платформонезависимый программный интерфейс для работы с аппаратно реализованным СКЗИ: смарт-картами, HSM, криптографическими токенами.

PKCS#11 иногда используется для доступа к программно реализованным криптографическим библиотекам.

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

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

Этот стандарт поддерживается во многих проектах с открытым исходным кодом, использующих криптографию.

Например, Mozilla Firefox позволяет хранить сертификаты и приватные ключи для аутентификации через SSL/TLS на токенах, работая с ними с помощью PKCS#11. Если прикладное ПО «может» работать с PKCS#11, то производителю СКЗИ необходимо реализовать программную библиотеку, которая будет раскрывать интерфейсы, описанные в стандарте, снаружи, а внутри реализовывать необходимую логику СКЗИ: работать напрямую с криптографическим устройством или реализовывать необходимые криптографические алгоритмы в программном обеспечении.

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

Это обеспечивает взаимозаменяемость различных устройств и их библиотек для прикладного ПО и прозрачное использование СКЗИ в различных системах.

Технологии работы с электронными подписями

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

Microsoft Крипто 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, «провайдерам криптографии» для выполнения математических преобразований.

Но алгоритмов генерации и проверки электронных подписей существует множество.

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

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

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

ПККС#7 PKCS#7 (Стандарт криптографии с открытым ключом №7), или CMS (Синтаксис криптографических сообщений) — это стандарт, опубликованный и поддерживаемый той же лабораторией RSA, который описывает синтаксис криптографических сообщений.

PKCS#7 также опубликован под номером 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-подписи».

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

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

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

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

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

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

Заключение

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