32,43
рейтинг
29 августа 2013 в 14:58

Разработка → Форматы электронной подписи из песочницы

Статья посвящена обзору стандартов СMS (Cryptographic Message Syntax) для подписанных сообщений.

Для чего нужен CMS


Стандарт CMS описывает структуру криптографических сообщений, включающих в себя защищенные данные вместе со сведениями, необходимыми для их корректного открытия или использования. Например, в сообщении размещаются защищенные данные, информация об алгоритме хеширования и подписи, времени подписи, сертификате открытого ключа, цепочке сертификации и т.д. Некоторые из указанных атрибутов носят опциональный характер, но приложение может само определить необходимость их наличия. У каждого алгоритма есть набор параметров, который должен быть согласован на обеих сторонах: для ГОСТ 34.10-2001, помимо открытого ключа, это модуль p, коэффициенты эллиптической кривой a и b и порядок циклической подгруппы точек эллиптической кривой q. И все это нужно каким-то образом передать адресату сообщения.

RSA Laboratories в серии своих стандартов криптографии с открытом ключом (PKCS) предложила решение этой проблемы путем определения синтаксиса для защищенных сообщений в следующих стандартах:

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

Всего CMS поддерживает шесть типов данных:
  • просто данные (data),
  • данные с электронной подписью (signed data),
  • упакованные данные (enveloped data),
  • хешированные данные (digested data),
  • зашифрованные данные (encrypted data),
  • данные с проверкой подлинности (authenticated data).

В рамках статьи мы подробно рассмотрим только данные с электронной подписью (signed data).

Чтобы не путаться в терминологии, далее исходные данные, которые мы хотим передать защищенным способом, будут называться данными, а получившееся защищенное сообщение CMS – просто сообщением.

Стандарт CMS (PKCS #7 и RFC 5652): теория


Чуть истории


Синтаксис криптографических сообщений (CMS) впервые был определен в PKCS #7, который позже был опубликован в качестве рекомендаций RFC 2315 «PKCS #7: Cryptographic Message Syntax Version 1.5». Спустя еще несколько версий RFC в сентябре 2009 года был принят RFC 5652 «Cryptographic Message Syntax (CMS)», который является действующим стандартом на данный момент.
Под спойлером иллюстрируется тяжелая судьба стандарта.
Смотреть

Эволюция PKCS#7/CMS


Подпись в CMS-формате (signed data type)


Подпись, описанная стандартом CMS, характеризуется следующими особенностями:
  1. Данные могут быть подписаны несколькими сторонами (множественная подпись). В таком случае в сообщении будут присутствовать несколько структур SignerInfo с информацией о подписывающих сторонах: значением подписи и необходимой для проверки ее подлинности информацией.
  2. Тип данных никак не регламентируется, лишь уточняется, что в качестве данных может быть сообщение формата CMS, то есть подписанное Алисой сообщение может быть целиком подписано Бобом.
  3. Подписывать можно не только данные, но и некоторые атрибуты сообщения – хеш сообщения (digest message), время подписи (signing time), значение другой подписи (countersignature).
  4. Открытый ключ подписывающей стороны может быть несертифицированным.
  5. Подпись может отсутствовать и вовсе.

Данные с электронной подписью используются не только для подписи содержимого и часто используются для распространения сертификатов и списков отзыва сертификатов (Certification Revocation List, CRL). В таком случае подписываемые данные отсутствуют, а поля Certificates и CRLs, наоборот, присутствуют.

Подписанное Алисой сообщение в формате CMS будет иметь следующий вид (серым отмечены необязательные атрибуты):


  • Версия синтаксиса CMS Version зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах
  • Digest Algorithms включает в себя идентификаторы используемых алгоритмов хеширования и ассоциированные с ними параметры.
  • Encapsulated Content содержит подписываемые данные (Content) вместе с их типом (Content Type). Содержимое может отсутствовать, тип – нет.
  • Certificates предназначен для цепочки сертификатов, отражающих путь сертификации от центра сертификации, выдавшего сертификат, до каждой из подписывающих сторон. Также могут присутствовать сертификаты подписывающих сторон.
  • CRLs (Certificate Revocation List) предоставляет информацию о статусе отзыва сертификатов, достаточную для определения валидности сертификата подписывающей стороны.
  • Информация о каждой подписывающей стороне содержится в структурах типа Signer Info, которых может быть любое количество, в том числе и нулевое (в случае отсутствия подписи).
    • Версия синтаксиса CMS Version определяется значением Signer ID.
    • Signer ID определяет открытый ключ подписывающей стороны (subjectKeyIdentifier) или сертификат его открытого ключа, необходимый для проверки подлинности подписи (issuerAndSerialNumber).
    • Digest Algorithm определяет алгоритм хеширования и все ассоциированные с ним параметры, используемые подписывающей стороной.
    • В Signed Attributes помещаются атрибуты, требующие подписи. Поле может отсутствовать только при подписи простых данных (Content Type = id-data), при подписи других данных (например, Content Type = id-SignedData) должно присутствовать с как минимум двумя обязательными атрибутами – типом (Content Type) и хешем данных (Message Digest).
    • Signature Algorithm содержит идентификатор алгоритма подписи вместе с его параметрами.
    • В Signature Value помещается значение подписанного закрытым ключом хеша от данных (Content) и атрибутов для подписи (Signed Attributes).
    • В Unsigned Attributes помещаются оставшиеся атрибуты, не требующие подписи.

Если Боб решает целиком подписать полученное от Алисы сообщение, то используется механизм инкапсуляции, и сообщение будет выглядеть вот так:


CMS предлагает два интересных атрибута, расширяющих возможности обычной подписи: время подписи (Signing Time) и контрасигнатуру (Countersignature). Первый атрибут определяет предполагаемое время осуществления подписи, а второй предназначен для подписи другой подписи (подписывается хеш от значения подписи). Атрибут Countersignature представляет собой структуру Signer Info с отсутствующим в Signed Attributes атрибутом Content Type и обязательно присутствующим атрибутом Message Digest. Атрибут Countersignature может иметь свой собственный атрибут Countersignature.

Если Боб решит подписать только данные, переданные Алисой, и заодно подписать подпись Алисы, то сообщение будет иметь такой вид:


Галопом по Европам оставшимся типам


СMS предлагает еще несколько интересных типов сообщений, не охватываемых темой этой статьи. Поэтому буквально по паре слов об оставшихся типах для общей картины.
Упакованные данные (enveloped data) представляют собой зашифрованные данные вместе с зашифрованными для одного или более получателей ключами, которыми эти данные были зашифрованы. Комбинация зашифрованного сообщения с одним зашифрованным ключом шифрования для одного получателя называется цифровым конвертом. Данный тип используется в качестве конверта с (подписанными) данными для одного или нескольких получателей.
Хешированные данные (данные вместе со своим хешем) используются для проверки целостности сообщения и часто являются содержимым упакованных данных.
Зашифрованные данные часто используются для шифрования данных для локального хранилища, иногда с выработанным из пароля ключом шифрования.
Данные из аутентифицированного источника (данные с проверкой подлинности) включают в себя данные вместе с их MAC-кодом и зашифрованными ключами аутентификации для одного или нескольких получателей. Используются для защиты целостности сообщений для неограниченного количества получателей.

В следующей статье мы подробно остановимся на сообщениях типа enveloped data с использованием российских криптоалгоритмов.

CMS в реальной жизни


Стандарт CMS имеет немало воплощений в современном мире IT – на нем основаны:
  • стандарт защищенной электронной почты S/MIME (RFC 3851),
  • расширенные сервисы защиты для S/MIME (RFC 2634, кстати, тут описаны дополнительные атрибуты CMS и технология тройного «обертывания» на основе множественной инкапсуляции: данные подписываются, затем шифруются и снова подписываются),
  • расширенные форматы представления информации об аннулированных сертификатах (RFC 5940) и пр.

Закономерным развитием идей CMS для сообщений с электронной подписью cтал CAdES (CMS Advanced Electronic Signature), расширенный стандарт подписанных сообщений CMS, который также послужит темой для еще одной нашей статьи.

Как реализовать на практике?


Стандарт CMS/PKCS#7 с поддержкой российских криптоалгоритмов реализован в сертифицированных СКЗИ наших партнеров:

Кроме того, стандарт CMS с российской криптографией реализован в Open Source приложении OpenSSL.

Наша компания поддержала CMS c российской криптографией в продукте Рутокен Плагин. Рутокен Плагин предназначен для использования в браузерах, все криптографические операции производятся аппаратно, «на борту» USB-токена.
Автор: @xelya
Компания «Актив»
рейтинг 32,43

Комментарии (7)

  • 0
    Вы лучше скажите, когда уже наступит всеобщее киберсчастье? В смысле можно будет прийти с паспортом в любой <название организации>, купить брелок и получить свою личную стандартную ЭЦП, которую будут обязаны принимать все, хоть госорганы, хоть частные конторы?
    Когда можно будет сделать то же самое для юрлиц?
    Когда, наконец, можно будет настроить почтовый клиент на режим «не принимать емейлы без валидной ЭЦП отправителя»?
    • +1
      «Коммунизм в СССР будет построен к 1980 году» © :)
    • 0
      Обещанного три года ждут.
      Применяем это к стандартной формуле «вычисление сроков реализации ИТ-проектов»: взять следующую временной интервал и помножить на два то получаем:
      3 года => 30 лет; 30 лет * 2 = 60 лет.
      Когда там ГОСТ был реализован в OpenSSL? В 2012-м? Значит к году этак 2072-му возможно будет вам ваше киберсчастье.
      • 0
        Кажется, Казахстану грех жаловаться в плане развития на пути к киберсчастью)
      • 0
        Гораздо раньше.
  • 0
    О, может мне сразу тут спросить по поводу вашей продукции? Вот есть Rutoken ЭЦП, у которого заявлена аппаратная поддержка шифрования ГОСТ и защищённый микроконтроллер. На деле там самый обыкновенный зарубежный микроконтроллер общего назначения (NXP LPC1765FET100), у которого 99.9% что нет аппаратной поддержки ГОСТ, и, скорее всего, ещё и хорошей защиты. Как так получается? На бумаге одно, а на деле другое.
  • 0

    Картинки у вас хорошие, понятные, даже вроде что-то проясняют, если бы не информация из других источников… Вот, в частности, возникают такие вопросы:


    1. В данной статье говорится, что подпись вычисляется от части структуры данных, называемой TBS (to be signed — для подписи). Там же говорится, что это просто первый элемент SEQUENCE второго уровня вложенности. В вашей же статье получается, что подписываются блоки Content и Signed Attributes, которые расположены в разных частях сообщения и не являются одним целым куском данных. Как же так, где правда? И если она на вашей стороне, то все-таки от какого массива байт считается подпись?
    2. Второй вопрос: где-то описано, что вообще может содержать PKCS#7? Вот на ваших картинках видно, что внутри у него могут содержаться блоки CMS Version, Digest Algorithms и т.п. А где полный список того, какие блоки могут быть?
    3. Судя по описанию элемента SET нотации ASN.1 порядок данных в нем не определен. Из вашего же описания содержимого PKCS#7 можно понять, что блоки Digest Algorithms (блок типа SET) и SignedInfo (все они тоже лежат в блоке типа SET, на вашей картинке этот блок-контейнер не показан) содержат список алгоритмов вычисления хеша для подписей и прочую информацию о подписях. Однако каким образом эти значения сопоставляются, ведь порядок в элементе SET не определен? С какой стати я должен считать, что первый Digest Algorithm в блоке Digest Algorithms относится к первой структуре SignedInfo, а не ко второй или десятой? И сопутствующий вопрос — зачем вообще нужен блок Digest Algorithm, почему эту информацию нельзя поместить в блок SignedInfo (а она там и есть, похоже)?
    4. Почему в блоках Digest algorithm написано Alice/Bob signature algorithm?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка