- PVSM.RU - https://www.pvsm.ru -
Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.
Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.
RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:
Развитием этих стандартов стал стандарт CMS. CMS кроме определенной заголовком статьи подписи поддерживает операции шифрования, хеширования и вычисления имитовставки, в том числе и по российским алгоритмам (RFC 4490 [3]), а также множественную инкапсуляцию. Последнее означает, что сообщение формата CMS может лежать внутри другого CMS сообщения.
Всего CMS поддерживает шесть типов данных:
В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).
Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.
Синтаксис криптографических сообщений (CMS) впервые был определен в PKCS #7 [1], который позже был опубликован в качестве рекомендаций RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1.5» [4]. Спустя еще несколько версий RFC в сентябре 2009 года был принят RFC 5652 «Cryptographic Message Syntax (CMS)» [5], который является действующим стандартом на данный момент.
Под спойлером иллюстрируется тяжелая судьба стандарта.
Подпись, описанная стандартом CMS, характеризуется следующими особенностями:
Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.
Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):
Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:
CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.
Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:
СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.
Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.
Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.
Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования.
Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.
В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.
Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:
Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.
Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:
Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.
Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин [13]. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.
Автор: xelya
Источник [14]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/42060
Ссылки в тексте:
[1] PKCS #7 «Cryptographic Message Syntax Standard»: http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs-7-cryptographic-message-syntax-standar.htm
[2] PKCS #10 «Certificate Request Syntax Standard»: http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/pkcs10-certification-request-syntax-standard.htm
[3] RFC 4490: http://tools.ietf.org/html/rfc4490
[4] RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1.5»: http://tools.ietf.org/html/rfc2315
[5] RFC 5652 «Cryptographic Message Syntax (CMS)»: http://tools.ietf.org/html/rfc5652
[6] RFC 3851: http://tools.ietf.org/html/rfc3851
[7] RFC 2634: http://tools.ietf.org/html/rfc2634
[8] RFC 5940: http://www.rfc-editor.org/rfc/rfc5940.txt
[9] КриптоПро CSP: http://www.cryptopro.ru/products/csp
[10] VipNet CSP: http://www.infotecs.ru/products/catalog.php?SECTION_ID=&ELEMENT_ID=2096
[11] СигналКом CSP: http://signal-com.ru/ru/prod/crypt/signal_com/
[12] Message-PRO: http://signal-com.ru/ru/prod/crypt/message_pro/
[13] Рутокен Плагин: http://www.rutoken.ru/products/all/rutoken-plugin/
[14] Источник: http://habrahabr.ru/post/191866/
Нажмите здесь для печати.