ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

Информационная технология КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

Форматы сообщений, защищенных криптографическими методами

Издание официальное

Москва

Стандартинформ

2019

Предисловие

1    РАЗРАБОТАНЫ Открытым акционерным обществом «Информационные технологии и коммуникационные системы» (ОАО «ИнфоТеКС»)

2    ВНЕСЕНЫ Техническим комитетом по стандартизации ТК 26 «Криптографическая защита информации»

3    УТВЕРЖДЕНЫ И ВВЕДЕНЫ В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 29 августа 2019 г. № 593-ст

4    ВВЕДЕНЫ ВПЕРВЫЕ

Правила применения настоящих рекомендаций установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящим рекомендациям публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены наспюящих рекомендаций соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru).

© Стандартинформ. оформление. 2019

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

II

issuerAndSerialNumber идентифицирует отправителя no выделенному имени издателя (см. ГОСТ Р ИСО/МЭК 9594-2) и порядковому номеру. Второй вариант subjectKeyldent ifier идентифицирует ключ проверки ЭП отправителя. При ссылке на Х.509 сертификат идентификатор ключа должен совпадать с расширением subject Key Identifier сертификата. При использовании других ссылок на сертификат документы, которые определяют формат сертификата и его использование с CMS, должны включать сведения о соответствии идентификатора ключа и поля сертификата. Реализации должны поддерживать оба варианта: subjectKeyldentifier и issuerAndSerialNumber. При создании sid реализации могут поддерживать одну из форм (либо subjectKeyldentifier, либо issuerAndSerialNumber) и всегда использовать ее. или реализации могут смешивать две формы. Тем не менее subjectKeyldentifier должен быть использован для идентификации ключа проверки ЭП, который не соответствует формату сертификатов Х.509;

-    digestAlgorithm — определение алгоритма вычисления хэш-функции. Значение хэш-функции вычисляется либо от содержимого, либо от содержимого вместе с подписанными атрибутами; этот процесс описан в 7.4. Идентификатор алгоритма хэширования должен присутствовать в числе тех. которые перечислены в поле digestAlgorithms структуры SignedData;

-    signedAttrs — набор подписанных атрибутов для подписи. Поле не является обязательным, но оно должно присутствовать, если тип содержимого структуры EncapsulatedContentlnfo представляет собой не «простые данные».

Поле signedAttrs должно быть представлено в DER-кодировке. даже если остальная часть структуры кодируется в BER-кодировке. Если поле присутствует, то оно должно содержать как минимум два атрибута:

-content-type — атрибут, определяющийся значением типа содержимого EncapsulatedContentlnfo (см. 13.1). Атрибут content-type не должен быть использован в не подписываемых атрибутах удостоверяющих подписей (см. 13.3),

-message-digest — атрибут, содержащий значение хэш-функции от содержимого

(см. 13.2);

-    signatureAlgorithm — определение алгоритма подписи и его параметров, используемых отправителем при подписи;

-    signature — результат вычисления подписи с использованием значения хэш-функции и ключа ЭП отправителя. Подробности алгоритма вычисления подписи зависят от алгоритма (см. 7.7);

-    unsignedAttrs — набор неподписанных атрибутов. Поле не является обязательным.

Поля типа signedAttributes и UnsignedAttributes имеют следующий смысл:

-    attrType — тип атрибута;

-    attrValues — значения атрибутов. Тип каждого значения определен полем attrType. Поле attrType может наложить ограничение на количество элементов в наборе.

7.4 Процесс вычисления значения хэш-функции

Процесс вычисления значения хэш-функции состоит из вычисления хэш-функции либо от содержимого, либо от содержимого и от подписываемых атрибутов. В любом случае вначале хэшируется содержимое для подписи, а именно — значение поля SignedData.encapContentInfo.eContent, представляющее собой строку байтов, к которому применяется процесс вычисления подписи. Хэшируется только содержимое строки байтов без хэширования байтов тэга и длины.

Результат вычисления значения хэш-функции зависит от наличия поля signedAttrs:

-    если поле отсутствует, то результатом будет являться значение хэш-функции, как описано выше. В этом случае только те байты, которые составляют значение SignedData.encapContentlnfо. eContent (например, содержимое файла) являются входом для вычисления значения хэш-функции. Преимущество этого варианта заключается в том, что длина подписываемого содержимого может быть не известна до начала процесса формирования подписи;

-    если поле присутствует, то результатом будет являться значение хэш-функции от значения поля signedAtrtrs, представленного в DER-кодировке. Так как поле signedAttrs должно содержать атрибуты content-type и message-digest, то эти значения также должны быть включены в хэшируемое значение. Атрибут content-type не должен включаться в неподписываемый атрибут countersignature, как это определено в 13.3. Кодирование поля signedAttrs выполняется отдельно для вычисления значения хэш-функции. Для DER-кодирования в signedAttrs вместо тэга IMPLICIT (0) использован тэг EXPLICIT SET OF. который должен быть включен в процесс вычисления значения хэш-функции вместе с длиной и строкой байтов поля SignedAttributes.

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

7.5    Процесс формирования подписи

Для формирования подписи на вход алгоритма подписи необходимы значение хэш-функции и ключ ЭП отправителя.

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

Детали процесса формирования подписи зависят от используемого алгоритма подписи (см. 7.7). Идентификатор объекта наряду со всеми параметрами, которые задают алгоритм подписи, находится в поле signatureAlgorithm.

7.6    Процесс проверки подписи

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

Значение хэш-функции для последующей проверки необходимо вычислять согласно 7.4 Если в сообщении присутствуют подписываемые атрибуты, то вычисленное значение хэш-функции необходимо сравнивать с представленным в сообщении значением атрибута messageDigest, включенного в подписанные атрибуты SignedData. signer Info. В случае несовпадения следует считать проверку сообщения недействительной.

Если SignedData. signerlnf о включает signedAttributes, значение атрибута content-type должно соответствовать значению SignedData. encapContent Info. eContentType.

Получатель может получить корректный ключ проверки ЭП отправителя любыми средствами, но предпочтительно получение ключа из сертификата из соответствующего поля структуры SignedData. Выбор и проверка ключа проверки ЭП отправителя могут быть основаны на построении и проверке цепочки сертификатов, а также могут зависеть от других внешних условий. Детали проверки подписи связаны с используемым алгоритмом (см. 7.7).

7.7    Специфика данных типа «подписанные данные»

В данном подразделе описано использование алгоритмов подписи по ГОСТ Р 34.10 в CMS.

Идентификаторы алгоритма подписи указаны в поле signatureAlgorithm структуры Signerlnfo (см. 7.3). вложенной в структуру SignedData. а также в поле signatureAlgorithm структуры Signerlnfo атрибутов удостоверяющей подписи.

Значения подписи указаны в поле signature структуры Signerlnfo, вложенной в структуру SignedData. а также в поле подписи Signerlnfo атрибутов удостоверяющей подписи.

Идентификаторы объектов АСН.1. параметры, битовое представление в точности совпадает с представлением подписи в сертификате, описанном в (2).

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

7.7.1    Специфика использования ГОСТ Р 34.10 с ключом 256 бит

Алгоритм подписи по ГОСТ Р 34.10 с ключом 256 бит используют для формирования ЭП в форме двух 256-битных чисел г и s по алгоритму ГОСТ Р 34.11 с длиной хэш-кода 256 бит. Ее представление в виде строки байтов состоит из 64 байтов: при этом первые 32 байта содержат число s в представлении big-endian (старший байт записывается первым), а вторые 32 байта содержат число г в представлении big-endian.

GostR3410-2012-256-Signature ::= OCTET STRING (SIZE (64))

7.7.2    Специфика использования ГОСТ Р 34.10 с ключом 512 бит

Алгоритм подписи по ГОСТ Р 34.10 с ключом 512 бит используют для формирования ЭП в форме двух 512-битных чисел г и s по алгоритму ГОСТ Р 34.11 с длиной хэш-кода 512 бит. Ее представление в виде строки байтов состоит из 128 байтов: при этом первые 64 байта содержат число s в представ-

пении big-endian (старший байт записывается первым), а вторые 64 байта содержат чиспо г в пред-ставпении big-endian.

GostR3410-2012-512-Signature OCTET STRING (SIZE (128))

8 Содержимое типа «конверт данных»

Содержимое типа «конверт данных» представпяет собой зашифрованное содержимое и зашифрованные кпючи шифрования содержимого дпя одного попучатепя ипи бопее. Комбинация зашифрованного содержимого и одного зашифрованного кпюча дпя одного попучатепя называется цифровым конвертом попучатепя. Любое содержимое может быть упаковано в «конверт данных» дпя произвопь-ного чиспа попучатепей при испопьзовании тобого поддерживаемого попучатепем механизма управ-пения ключами (см. 8.2).

Построение содержимого типа «конверт данных» состоит из следующих шагов:

-    генерируется случайный ключ шифрования содержимого (см. раздел 12);

-    ключ шифрования содержимого зашифровывают для каждого получателя. Детали шифрования зависят от используемого механизма управления ключами (см. 8.4). 8 сообщениях формата CMS с использованием российских криптографических алгоритмов применяют два способа управления ключами:

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

(см. 8.2.1,8.2.2).

-    применение ранее выработанного симметричного ключа для шифрования ключа шифрования содержимого (см. 8.2.3);

-    для каждого получателя зашифрованный ключ шифрования содержимого и другая информация, специфичная для получателя, записывают в структуру Recipient Info (8.2);

-    содержимое зашифровывают с помощью ключа шифрования содержимого. При шифровании может возникнуть необходимость дополнения данных содержимого до полного блока (см. 8.3);

-    значение Recipientlnfo вместе с зашифрованным содержимым для всех получателей записывают в структуру EnvelopedData (см. 8.1).

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

8.1 Тип EnvelopedData

Следующий идентификатор определяет тип содержимого EnvelopedData:

id-envelopedData OBJECT IDENTIFIER

{

iso(l) member-body(2) us(840) rsadsi(113549) pkcs(l) pkcs7(7)

Тип EnvelopedData в формате ACH.1 представляется следующим образом:

EnvelopedData ::= SEQUENCE

{

}

Recipientlnfos ::= SET SIZE (1..MAX) OF Recipientlnfo EncryptedContentlnfo ::= SEQUENCE {

contentType    ContentType,

contentEncryptionAlgorithm ContentEncryptionAlgorithmldentifier,

encryptedContent[0) IMPLICIT EncryptedContent OPTIONAL

ContentType    OBJECT    IDENTIFIER

ContentEncryptionAlgorithmldentifier    SEQUENCE

{

encryptionAlgorithmOID    OBJECT IDENTIFIER,

parameters    Gost3412-15-Encryption-Parameters

}

Gost3412-15-Encryption-Parameters ::= SEQUENCE

{

ukm    OCTET STRING

}

EncryptedContent :OCTET STRING

UnprotectedAttributes SET SIZE (1..MAX) OF Attribute

Типы CMSVersion, Originatorlnfo, Algorithmldentifier, Attribute определены в разделе 14. тип Recipientlnfo — в 8.2.

Поля структуры EnvelopedData имеют следующий смысл:

-version — номер версии синтаксиса. Версия синтаксиса должна быть определена согласно

Ш.в.1;

-    originatorlnfo — поле, содержащее информацию об отправителе: данное поле присутствует в структуре, если этого требует алгоритм согласования ключей: в случае использования алгоритма согласования ключей на основе статического протокола Диффи—Хеллмана данное поле обязательно должно присутствовать в структуре В этом случае поле содержит информацию о сертификате, ключ которого использован для согласования ключей. Поле может содержать информацию о нескольких сертификатах и САС. Наличие в зашифрованном сообщении (в том числе и защищенном имитовставкой) поля originatorlnfo не является подтверждением авторства данного сообщения;

-    recipient Infos — поле, содержащее список информации о каждом из получателей; данный список не может быть пустым;

-    encryptedContentlnfo — зашифрованное содержимое;

-    unprotectedAttrs — необязательный набор незашифрованных атрибутов.

Поля структуры EncryptedContentlnfo имеют следующий смысл:

-    contentType — тип содержимого:

-    contentEncryptionAlgorithm — определение алгоритма зашифрования содержимого и его параметры; процесс зашифрования содержимого описывается в 8.3; для всех получателей использован один и тот же алгоритм зашифрования содержимого;

-    encryptedContent — необязательное поле, результат зашифрования содержимого; если поле отсутствует, то предполагается, что значение будет получено другим способом.

Поля структуры ContentEncryptionAlgorithmldentifier имеют следующий смысл:

-    encryptionAlgorithmOID — идентификатор алгоритма шифрования (см. 8.3.1);

-    parameters —дополнительные параметры алгоритма шифрования.

Поля структуры Gost3412-15-Encryption-Parameters имеют следующий смысл:

-    ukm — ключевой материал пользователя икм; параметр является обязательным и должен содержать п байт. В зависимости от алгоритма п принимает следующие значения (см. 8.3.1) для алгоритмов на основе блочного шифра:

-    ГОСТ Р 34.12 «Магма» — п =12;

-    ГОСТ Р 34.12 «Кузнечик» — п =16.

Так как поле recipientlnfos расположено до поля encryptedContentlnfo. то значение EnvelopedData может быть обработано за один проход.

8.2 Тип Recipientlnfo

Информация о каждом из получателей хранится в структуре Recipientlnfo. Структура Recipientlnfo имеет разные форматы в зависимости от используемого механизма управления ключами (подробнее см. (1)). Любые механизмы управления ключами могут быть использованы для одного зашифрованного содержимого. Зашифрованный ключ шифрования содержимого передается одному получателю или более.

Все реализации должны корректно обрабатывать неподдерживаемые алгоритмы.

Для российских криптографических алгоритмов должны поддерживаться алгоритмы согласования ключей и симметричное шифрование ключей, как это указано в полях ktri, kari и kekri, соответственно (сокращения от KeyTransRecipientlnfo, KeyAgreeRecipientlnfo, KEKRecipientlnfo). Так как различные получатели могут поддерживать различные механизмы управления ключами и будущие спецификации могут определить дополнительные механизмы управления ключами, то все реализации должны корректно обрабатывать:

-    все возможные варианты значения поля Recipient Info;

-    все возможные версии реализаций для значений поля Recipientlnfo;

-    все нереализованные и неизвестные варианты значения поля Recipientlnfo для OtherRecipientInfо.

Тип Recipientlnfo в формате АСН.1 представлен следующим образом:

Recipientlnfo ::■ CHOICE

{

}

Типы KeyTransRecipientlnfo, KeyAgreeRecipientlnfo, KEKRecipientlnfo определены в 8.2.1—8.2.3, соответственно. Типы PasswordRecipientinfo и OtherRecipientlnfo не рассматривают в данной спецификации.

Совместимые реализации, оперирующие сообщениями с типом данных «конверт данных», должны поддерживать следующий функционал при зашифровании и расшифровании;

-    обработка шифрованных сообщений с использованием эфемерного протокола Диффи— Хеллмана;

-    закодирование и раскодирование информации о получателях шифрованного сообщения в виде структур типа KeyTransRecipientlnfo;

-    обработка шифрованных сообщений без имитовставки.

Поддержка следующих типов шифрованных сообщений является опциональной и остается на усмотрение разработчика:

-    сообщения с использованием статического протокола Диффи—Хеллмана;

-    coo6ineHHncHcnonb30BaHHeMCTpyKTypTHnaKeyAgreeRecipientInfonKEKRecipientInfo;

-    сообщения с имитозащитой.

8.2.1 Тип KeyTransRecipientlnfo

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

Тип KeyTransRecipientlnfo в формате АСН.1 представлен следующим образом: KeyTransRecipientlnfo ::= SEQUENCE {

version    CMSVersion,

rid    Recipientldentifier,

keyEncryptionAlgorithm KeyEncryptionAlgorithmldentifier,

encryptedKey    OCTET STRING

}

Recipientldentifier ::= CHOICE

{

issuerAndSerialNumber    IssuerAndSerialNumber,

subjectKeyldentifier (0]    SubjectKeyldentifier

}

SubjectKeyldentifier :    OCTET    STRING

KeyEncryptionAlgorithmldentifier ::= SEQUENCE

{

algorithm    OBJECT IDENTIFIER,

parameters    GostR3410-12-KEG-Parameters

}

GostR3410-12-KEG-Parameters ::= SEQUENCE

{

algorithm    OBJECT IDENTIFIER

}

GostR3410-KeyTransport :SEQUENCE

{

encryptedKey    OCTET STRING,

ephemeralPublicKey SubjectPublicKeylnfo, ukm    OCTET STRING

}

SubjectPublicKeylnfo : : =

{

algorithm subjectPublicKey

}

Поля структуры KeyTransRecipientlnfo имеют следующий смысл:

-version — номер версии синтаксиса; в зависимости от значения поля rid типа Recipient Identifier номер версии равен или 0. или 2:

-    если параметр rici равен issuerAndSerialNumber, то версия равна 0,

-    если параметр rid равен subjectKeyldentifier [0], то версия равна 2;

-    rid — определение сертификата получателя или непосредственно самого ключа проверки ЭП, который использован отправителем для защиты ключа шифрования содержимого. Сертификат ключа получателя должен содержать в расширении KeyUsage установленный флаг keyAgreement. Ключ шифрования содержимого зашифрован с использованием ключа проверки ЭП получателя. Тип Recipient Identifier предоставляет два варианта указания сертификата получателя и тем самым ключа проверки ЭП получателя. Значение issuerAndSerialNumber идентифицирует получателя по выделенному имени издателя и порядковому номеру сертификата. Для ссылки на сертификат стандарта Х.509 может использоваться идентификатор ключа, соответствующий расширению Subject-Keyldentifier в сертификате. При использовании ссылки на другие форматы сертификатов документ, определяющий формат сертификата и его использование в CMS, должен включать сведения о соответствии идентификатора ключа соответствующему полю сертификата. Для обработки на стороне получателей реализация должна поддерживать оба способа ссылок на сертификат. Для обработки на стороне отправителя реализация должна поддерживать хотя бы одну альтернативу;

-    keyEncryptionAlgorithm — определение алгоритма зашифрования ключа шифрования содержимого и его параметров; процесс зашифрования описан и значения параметров определены в 8.4;

-    encryptedKey — поле представляет собой структуру GostR3410-KeyTransport, закодированную 8 OCTET STRING.

Поля структуры GostR3410-KeyTransport имеют следующий смысл:

-    encryptedKey —зашифрованные по алгоритму КЕхр15 (см. Р 1323565.1.017) ключ шифрования и имитовставка (см. 8 4 2): первые 32 байта представляют ключ, оставшиеся п байт — имитовстав-ку. В зависимости от алгоритма п принимает следующие значения (см. 8.4.1) для алгоритма:

-id-gostr3412-2015-magma-wrap-kexpl5    п = 8.

-id-gostr3412-2015-kuznyechik-wrap-kexpl5    п    =16;

-    ephemeral PublicKey — эфемерный ключ проверки ЭП отправителя, данный параметр является обязательным;

-    ukm — ключевой материал пользователя UKM. параметр является обязательным и должен содержать 32 байта.

Поля структуры SubjectPublicKeylnfo имеют следующий смысл:

-    algorithm - определение алгоритма ключа проверки ЭП;

-    subjectPublicKey — значение ключа проверки ЭП.

Типы CMSVersion, IssuerAndSerialNumber и Algorithmldentifier определены в разделе 14.

8.2.2 Тип KeyAgreeRecipientlnfo

Информация о каждом пользователе, использующем механизм управления ключами на основе статического и эфемерного протоколов Диффи—Хеллмана. хранится в структуре

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

KeyAgreeRecipientlnfo ::= SEQUENCE

{

version    CMSVersion,

originator[0]    EXPLICIT

OriginatorldentifierOrKey,

ukm[l]    EXPLICIT UserKeyingMaterial,

keyEncryptionAlgorithm KeyEncryptionAlgorithmldentifier,

recipientEncryptedKeys RecipientEncryptedKeys

}

OriginatorldentifierOrKey ::= CHOICE

<

issuerAndSerialNumber    IssuerAndSerialNumber,

subjectKeyldentifier [0]    SubjectKeyldentifier,

originatorKey[1]    OriginatorPublicKey

}

SubjectKeyldentifier : := OCTET STRING OriginatorPublicKey    SEQUENCE

{

algorithm    Algorithmldentifier,

publicKey    OCTET STRING

}

UserKeyingMaterial    OCTET STRING

KeyEncryptionAlgorithmldentifier :    SEQUENCE

{

algorithm    OBJECT IDENTIFIER,

parameters    GostR3410-12-KEG-Parameters

}

GostR3410-12-KEG-Parameters ::= SEQUENCE

{

algorithm OBJECT IDENTIFIER

}

RecipientEncryptedKeys    SEQUENCE OF RecipientEncryptedKey

RecipientEncryptedKey ::= SEQUENCE

{

rid    KeyAgreeRecipientldentifier,

encryptedKey    OCTET STRING

}

KeyAgreeRecipientldentifier ::= CHOICE

<

issuerAndSerialNumber IssuerAndSerialNumber, rKeyld[0]    IMPLICIT RecipientKeyldentifier

}

RecipientKeyldentifier ::= SEQUENCE

{

subjectKeyldentifier    SubjectKeyldentifier,

date    GeneralizedTime OPTIONAL,

other    OtherKeyAttribute OPTIONAL

}

SubjectKeyldentifier    OCTET STRING

Типы CMSVersion, IssuerAndSerialNumber. Algorithmldentifier, OtherKeyAt-tribute определены в разделе 14

Поля структуры KeyAgreeRecipientlnfo имеют следующий смысл:

-    version — номер версии синтаксиса, который должен быть всегда равен 3;

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

Реализации должны поддерживать все три варианта для определения ключа проверки ЭП отправителя:

-    вариант issuerAndSerialNumber идентифицирует сертификат отправителя и тем самым ключ проверки ЭП отправителя по выделенному имени издателя и серийному номеру сертификата;

-    вариант subjectKeyldentifier идентифицирует сертификат отправителя и тем самым ключ проверки ЭП отправителя по идентификатору ключа; при использовании ссылок на сертификат стандарта Х.509 использован идентификатор ключа, соответствующий Х.509 расширению subjectKeyldentifier; при использовании ссылок на другие форматы сертификата документы, которые определяют формат сертификата и его использование в CMS, должны включать сведения о соответствующем поле сертификата;

-    вариант originatorKey включает идентификатор алгоритма и ключ проверки ЭП отправителя; этот вариант допускает анонимность отправителя, так как ключ проверки ЭП не подтвержден;

-    ukm— ключевой материал пользователя UKM. данный параметр является обязательным и должен содержать 32 байта;

-    keyEncryptionAlgorithm — определение алгоритма зашифрования ключа шифрования содержимого и его параметров; процесс зашифрования описан, и значения параметров определены в 8.4;

-    recipientEncryptedKeys — список структур типа RecipientEncryptedKey. Каждый экземпляр структуры RecipientEncryptedKey включает в себя идентификатор получателя типа KeyAgreeRecipientldentifier и параметр encryptedKey для одного или нескольких получателей.

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

-    вариант issuerAndSerialNumber идентифицирует сертификат по выделенному имени и серийному номеру;

-    вариант RecipientKeyldentifier описан ниже;

-    encryptedKey— зашифрованные по алгоритму КЕхр15(см. Р 1323565.1.017) ключ шифрования и имитовставка (см. 8 4 2); первые 32 байта представляют ключ, оставшиеся п байт — имитовстав-ку. В зависимости от алгоритма п принимает следующие значения (см. 8.4.1) для алгоритма:

-    id-gostr3412-2015-magma-wrap-kexpl5    п    =8.

-    id-gostr3412-2015-kuznyechik-wrap-kexpl5 п = 16.

Сертификат ключа получателя должен содержать в расширении KeyUsage установленный флаг keyAgreement. Ключ шифрования содержимого шифруется ключом парной связи.

Поля типа RecipientKeyldentifier имеют следующий смысл:

-    subjectKeyldentifier — определение сертификата получателя при помощи идентификатора ключа; при использовании ссылок на сертификат стандарта Х.509 применен идентификатор ключа, соответствующий Х.509 расширению subjectKeyldentifier; при использовании ссылок на другие форматы сертификата документы, которые определяют формат сертификата и его использование в CMS. должны включать сведения о соответствующем поле сертификата;

-    date — дата, необязательное поле; если поле присутствует, то дата определяет, какой из ранее распределенных получателем UKM использован отправителем;

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

8.2.3 Тип KEKRecipientlnfo

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

KEKRecipientlnfo ::= SEQUENCE

{

version    CMSVersion,

kekid    KEKIdentifier,

keyEncryptionAlgorithm KeyEncryptionAlgorithmldentifier/ encryptedKey    OCTET STRING

}

KEKIdentifier    SEQUENCE

{

keyldentifier    OCTET STRING,

date    GeneralizedTime OPTIONAL,

other    OtherKeyAttribute OPTIONAL

}

KeyEncryptionAlgorithmldentifier ::= Algorithmldentifier

Типы CMSVersion. Algorithmldentifier, OtherKeyAttribute определены в разделе 14.

Поля типа KEKRecipientlnfo имеют следующий смысл:

-    version — номер версии синтаксиса: должен быть всегда 4:

-    kekid — идентификатор симметричного ключа, который ранее передан отправителю и одному или нескольким получателям;

-    keyEncryptionAlgorithm — определение алгоритма зашифрования ключа шифрования содержимого и его параметров: процесс зашифрования описан и значения параметров определены в 8.4;

-    encryptedKey — зашифрованные по алгоритму KExpl 5 (см. Р1323565.1.017) ключ шифрования и имитовставка (см. 8.4.2): первые 32 байта представляют ключ, оставшиеся п байт — имитовстав-ку. В зависимости от алгоритма г. принимает следующие значения (с»л. 8.4.1) для алгоритма:

- id-gostr3412-2015-magma-wrap-kexpl5    п = 8,

-id-gostr3412-2015-kuznyechik-wrap-kexpl5    п =    16.

Поля типа KEKIdentifier имеют следующий смысл:

-    keyldentifier — идентификатор ключа зашифрования ключа, который ранее был передан отправителю и одному или нескольким получателям;

-    date — дата, необязательное поле: если поле присутствует, то дата определяет единственный ключ зашифрования ключа шифрования содержимого, который ранее был распределен;

-    other — дополнительная информация, используемая для определения ключа шифрования ключа отправителя: необязательное поле.

8.3 Процесс зашифрования содержимого

Для требуемого алгоритма ключ шифрования содержимого генерируется случайным образом (см. раздел 12). При использовании описанных ниже российских криптографических алгоритмов процедура дополнения содержимого не производится. Операция зашифрования отображает произвольную строку байтов (данные) в другую строку байтов (зашифрованный текст) с использованием ключа шифрования. Зашифрованные данные включают в поле структуры EnvelopedData: OCTET STRING Envel-opedData.encryptedContentlnfo.encryptedContent.

8.3.1 Параметры шифрования сообщений

В данном пункте изложены рекомендации, используемые при реализации CMS с поддержкой шифрования содержимого согласно ГОСТ Р 34.12. ГОСТ Р 34.13 и Р 1323565.1.017.

Идентификаторы алгоритма шифрования содержимого указываются в следующих полях:

-    EnvelopedDat a. Encrypt edContent Inf о. content EncryptionAlgorithm;

-    EncryptedDat a. Encrypt edContent Inf о. content Encrypt ionAlgorithm (определение структуры EncryptedData ш. в разделе 10).

Для шифрования содержимого введены следующие новые идентификаторы:

id-gostr3412-2015-magma-ctracpkm OBJECT IDENTIFIER ::=

{

iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) cipher(5) gostr3412-2015-magma(1) mode-ctracpkm(1)

}

При использовании идентификатора id-gostr3412-2015-magma-ctracpkm шифрование произведено с помощью блочного шифра по ГОСТ Р 34.12 «Магма» в режиме CTR-ACPKM согласно Р 1323565.1.017. При этом длина блока гаммы s. приведенная в Р 1323565.1.017. равна 64 бита: размер секции (см. Р 1323565.1.017) — 8 Кбайт.

id-gostr3412-2015-magma-ctracpkm-omac OBJECT IDENTIFIER ::=

{

iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) cipher(5) gostr3412-2015-magma(1) mode-ctracpkm-omac(2)

}

При использовании идентификатора id-gostr3412-2015-magma-ctracpkm-omac вычисление имитовставки осуществлено с помощью шифра «Магма» по ГОСТ Р 34.12 в режиме выработки имитовставки согласно ГОСТ Р 34.13 (размер имитовставки — 64 бита), а шифрование произведено с помощью шифра «Магма» по ГОСТ Р 34.12 в режиме CTR-ACPKM. определенном в Р 1323565.1.017. При этом длина блока гаммы s, приведенная в Р 1323565.1.017, равна 64 бита; размер секции (см. Р 1323565.1.017) — 8 Кбайт.

id-gostr3412-2015-kuznyechik-ctracpkm OBJECT IDENTIFIER ::=

{

iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) cipher(5) gostr3412-2015-kuznyechik(2) mode-ctracpkm(1)

}

При использовании идентификатора id-gostr3412-2015-kuznyechik-ctracpkm шифрование произведено с помощью блочного шифра «Кузнечик» по ГОСТ Р 34.12 в режиме CTR-ACPKM согласно Р 1323565.1.017. При этом длина блока гаммы s, приведенная в Р 1323565.1.017, равна 128 бит; размер секции (см. Р 1323565.1.017) — 256 Кбайт.

id-gostr3412-2015-kuznyechik-ctracpkm-omac OBJECT IDENTIFIER ::=

{

iso(l) member-body(2) ru(643) rosstandart(7) tc26(l) algorithms(1) cipher(5) gostr3412-2015-kuznyechik(2) mode-ctracpkm-omac(2)

}

При использовании идентификатора id-gostr3412-2015-kuznyechik-ctracpkm-omac вычисление имитовставки осуществляется с помощью шифра «Кузнечик» по ГОСТ Р 34.12 в режиме выработки имитовставки согласно ГОСТ Р 34.13 (размер имитовставки — 128 бит), а шифрование производится с помощью шифра «Кузнечик» по ГОСТ Р 34.12 в режиме CTR-ACPKM, определенном в Р 1323565.1.017. При этом длина блока гаммы s, приведенная в Р 1323565.1.017, равна 128 бит; размер секции (см. Р 1323565.1.017) — 256 Кбайт.

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

-    EnvelopedData.EncryptedContentlnfo.encryptedContent;

-    EncryptedData.EncryptedContentlnfo.encryptedContent.

В качестве дополнительных параметров используют параметры из полей EnvelopedData. EncryptedContentlnfo.contentEncryptionAlgorithm.parameters.ukm    и

EncryptedData.EncryptedContentlnfo.contentEncryptionAlgorithm.parameters.ukm соответственно (см. 8.1).

8.3.2 Процесс формирования и разбора содержимого

Зашифрование содержимого для алгоритмов id-gostr3412-2015-magma-ctracpkm и id-gostr3412-2015-kuznyechik-ctracpkm осуществлено следующим способом:

-    с использованием ключа шифрования содержимого К^ в зависимости от заданного алгоритма шифрования происходит зашифрование содержимого с начальным значением IV. равным соответствующим полям (п — размер поля ukm):

-EnvelopedData.EncryptedContentlnfo.contentEncryptionAlgorithm. parameters.ukm[l..n — 8],

Содержание

1    Область применения..................................................................1

2    Нормативные ссылки..................................................................1

3    Термины, определения и обозначения...................................................2

3.1    Термины и определения............................................................2

3.2    Обозначения.....................................................................2

4    Общее описание.....................................................................3

5    Общий синтаксис.....................................................................3

6    Содержимое типа «простые данные»....................................................4

7    Содержимое типа «подписанные данные»................................................4

7.1    Тип SignedData...................................................................5

7.2    Тип EncapsulatedContentlnfo........................................................6

7.3    Тип Signerlnfo....................................................................6

7.4    Процесс вычисления значения хэш-функции...........................................7

7.5    Процесс формирования подписи....................................................8

7.6    Процесс проверки подписи.........................................................8

7.7    Специфика данных типа «подписанные данные».......................................8

8    Содержимое типа «конверт данных».....................................................9

8.1    Тип EnvelopedData................................................................9

8.2    Тип Recipientlnfo.................................................................10

8.3    Процесс зашифрования содержимого...............................................15

8.4    Процесс зашифрования ключа.....................................................18

9    Содержимое типа «хэшированные данные»..............................................21

9.1    Тип DigestedData.................................................................21

9.2    Специфика данных типа «хэшированные данные».....................................21

10    Содержимое типа «зашифрованные данные»...........................................22

10.1    Тип EncryptedData..............................................................22

10.2    Специфика данных типа «зашифрованные данные»..................................23

11    Содержимое типа «аутентифицированные данные»......................................23

11.1    Тип Authenticated Data...........................................................24

11.2    Формирование имитовставки.....................................................25

11.3    Формирование имитовставки для последующей проверки.............................25

11.4    Специфика данных типа «аутентифицированные данные»............................26

12    Вопросы безопасности..............................................................26

13    Полезные атрибуты.................................................................26

13.1    Атрибут content-type.............................................................27

13.2    Атрибут message-digest..........................................................27

13.3    Атрибут countersignature.........................................................28

13.4    Атрибут content-mac............................................................28

14    Полезные типы.....................................................................29

14.1    Тип CMSVersion................................................................29

14.2    Тип IssuerAndSerialNumber.......................................................29

14.3    Тип RevocationInfoChoices........................................................29

14.4    Тип Algorithmldentifier............................................................29

14.5    Тип CertificateChoices...........................................................30

14.6    Тип CertificateSet...............................................................31

14.7    Тип Originatorlnfo...............................................................31

14.8    Тип OtherKeyAttribute............................................................31

14.9    Тип Attribute...................................................................31

Приложение А (справочное) Контрольные примеры.........................................32

Библиография........................................................................47

-    EncryptedData.EncryptedContentlnfo.contentEncryptionAlgorithm.

parameters.ukm[l..n — 8];

-    ключ шифрования содержимого К_тв зашифрован в соответствии с выбранным механизмом управления ключами и установлен в соответствующее поле.

Расшифрование содержимого для алгоритмов id-gostr3412-2015-magma-ctracpkm и id-gostr3412-2015-kuznyechik-ctracpkm осуществлено следующим способом:

-    извлечен и расшифрован ключ шифрования содержимого К_те (см. 8.4.2);

-    с использованием ключа К_те осуществлено расшифрование содержимого с начальным значением IV. равным соответствующим полям (п — размер поля ukm):

-    EnvelopedData.EncryptedContentlnfo.contentEncryptionAlgorithm.

parameters.ukm[l..n —8],

-    EncryptedData.EncryptedContentlnfo.contentEncryptionAlgorithm.

parameters.ukm[1..n — 8].

Зашифрование содержимого для алгоритмов id-gostr3412-2015-magma-ctracpkm-omac и id-gostr3412-2015-kuznyechik-ctracpkm-omac осуществлено следующим способом:

-    из ключа К_те с использованием алгоритма KDF_TREE_GOSTR3411_2012_256, описанного в Р 50.1.113, вырабатывается два ключа:

-    ключ шифрования сообщения К( 1).

-    ключ и митоза щиты К( 2).

Входные параметры для алгоритма KDF_TREE_GOSTR3411_2012_256 принимают следующие значения:

К,п = Кп»

label = «kdftree»

seed = ukm[n - 7..n)

R- 1;

-    с использованием ключа имитозащиты K(2), выработанного из К_me, осуществлено вычисление имитовставки для открытого текста содержимого;

-    результирующее значение имитовставки добавлено в конец содержимого. Полученная строка байт зашифрован с использованием ключа шифрования К( 1). выработанного из К_те. с начальным значением IV. равным соответствующим полям:

-    EnvelopedData.EncryptedContentlnfo.contentEncryptionAlgorithm.

parameters.ukm[l..n — 8],

-    EncryptedData.EncryptedContentlnfo.contentEncryptionAlgorithm.

parameters.ukm[l..n — 8];

-    последние n байт зашифрованного текста, где п зависит от выбранного алгоритма выработки имитовставки, являющиеся зашифрованной имитовставкой, в виде атрибута content-mac помещаются в поле незашифрованных атрибутов сообщения unprotectedAttrs (см. 13.4);

-    ключ шифрования содержимого К_те зашифрован в соответствии с выбранным механизмом управления ключами и установлен в соответствующее поле.

Расшифрование содержимого для алгоритмов id-gostr3412-2015-magma-ctracpkm-omac и id-gostr3412-2015-kuznyechik-ctracpkm-omac осуществлено следующим способом:

-    извлечен и расшифрован ключ шифрования содержимого К_те (см. 8.4.2);

-из ключа К_те с использованием алгоритма KDF_TREE_GOSTR3411_2012_256. описанного в Р 50.1.113, вырабатывается два ключа:

-    ключ шифрования сообщения К( 1),

-    ключ имитозащиты К(2).

Входные параметры для алгоритма KDF_TREE_GOSTR3411_2012_256 принимают следующие значения:

Kin = Km

label = «kdftree»

seed = ukm[n - 7..n)

R- 1.

Зашифрованная имитовставка из атрибута content-mac (см. 13.4) помещена в конец зашифрованного содержимого;

Введение

В настоящих рекомендациях приведено описание форматов кодирования, идентификаторов и форматов параметров при использовании ГОСТ Р 34.10. ГОСТ Р 34.11. ГОСТ Р 34.12. ГОСТ Р 34.13 для криптографической защиты сообщений [сообщений в формате CMS (Cryptographic Message Syntax)).

Разработка новой версии настоящих рекомендаций вызвана введением в действие ГОСТ Р 34.12 и ГОСТ Р 34.13. а также необходимостью добавления механизмов контроля целостности содержимого и времени формирования подписей в формат защищенных сообщений.

РЕКОМЕНДАЦИИ ПО СТАНДАРТИЗАЦИИ

Информационная технология КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ Форматы сообщений, защищенных криптографическими методами

Information technology Cryptographic information security Cryptographically secured message formats

Дата введения — 2019—12—01

1    Область применения

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

В настоящих рекомендациях дано описание правил использования алгоритмов формирования и проверки подписи в соответствии с ГОСТ Р 34.10, функции хэширования по ГОСТ Р 34.11, функций шифрования в соответствии с ГОСТ Р 34.12 и ГОСТ Р 34.13 для защиты сообщений в формате CMS.

2    Нормативные ссылки

В настоящих рекомендациях использованы нормативные ссылки на следующие стандарты и рекомендации:

ГОСТ Р 34.10 Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи

ГОСТ Р 34.11 Информационная технология. Криптографическая защита информации. Функция хэширования

ГОСТ Р 34.12 Информационная технология. Криптографическая защита информации. Блочные шифры

ГОСТ Р 34.13 Информационная технология. Криптографическая защита информации. Режимы работы блочных шифров

ГОСТ Р ИСО/МЭК 8824-1 Информационная технология. Абстрактная синтаксическая нотация версии один (АСН.1). Часть 1. Спецификация основной нотации

ГОСТ Р ИСО/МЭК 8825-1 Информационная технология. Правила кодирования АСН.1. Часть 1. Спецификация базовых (BER). канонических (CER) и отличительных (DER) правил кодирования

ГОСТ Р ИСО/МЭК 9594-2 Информационная технология. Взаимосвязь открытых систем. Справочник. Модели

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

Р 1323565.1.012 Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации.

Р 1323565.1.017 Информационная технология. Криптографическая защита информации. Криптографические алгоритмы, сопутствующие применению алгоритмов блочного шифрования

Р 1323565.1.020—2018 Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе безопасности транспортного уровня (TLS 1.2)

Издание официальное

Примечание — При пользовании настоящими рекомендациями целесообразно проверить действие ссылочных стандартов в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год Если заменен ссылочный стандарт, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого стандарта с учетом всех внесенных в данную версию изменений Если заменен ссылочный стандарт, на который дана датированная ссылка, то рекомендуется использовать версию этого стандарта с указанным выше годо*.» утверждения (принятия). Если после утверждения настоящих рекомендаций в ссылочный стандарт, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения Если ссылочный стандарт отменен без замены, то положение, в котором дана ссылка на него, применяется в части, не затрагивающей эту ссылку

3 Термины, определения и обозначения

3.1    Термины и определения

В настоящих рекомендациях применены следующие термины с соответствующими определениями:

3.1.1    электронная подпись; ЭП: Строка бит. полученная в результате процесса формирования подписи.

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

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

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

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

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

3.1.6

хэш-функция: Функция, отображающая строки бит в строки бит фиксированной длины и удовлетворяющая следующим свойствам:

-    по данному значению функции сложно вычислить исходные данные, отображаемые в это значение;

-    для заданных исходных данных сложно вычислить другие исходные данные, отображаемые в то же значение функции;

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

(ГОСТ Р 34.11-2012. пункт 3.1.6]

3.1.7 _

хэш-код: Строка бит. являющаяся выходным результатом хэш-функции.

(ГОСТ Р 34.11-2012. пункт 3.1.5]

3.1.8    тэг: Числовой идентификатор, определяющий тип данных АСН.1 структуры.

3.2 Обозначения

В настоящих рекомендациях использованы следующие обозначения:

-    \Л — множество всех двоичных строк конечной длины, включая пустую строку;

-    V_s — множество всех двоичных строк длины s, s > 0. При s = 0 множество V_s состоит из единственной пустой строки длины 0;

-    8_S — множество байтовых строк длины s. s s 0. Строка b = {b_y.....bj принадлежит множеству

8_S. если б,.....b_s e {0.....255}.    При    n    =    0    множество 8_S состоит из единственной пустой строки длины 0;

-    b[i..j] — строка b[i..j\ = (Ь_г Vi.....ьрее^,. где 1 S / S j < s и Ь = (Ь,.....Pj) 6 8_S;

-    |Д| — число компонент (длина) строки А е У* (если А — пустая строка, то |Д| = 0);

-    А\\В — конкатенация строк A. Be V*. т. е. строка из У_Л|₊|_в|, в которой подстрока с большими номерами компонент из V_[Al совпадает со строкой А, а подстрока с меньшими номерами компонент из Vj_fi| совпадает со строкой 8;

-    K_s — ключ электронной подписи отправителя сообщения;

-    К_г— ключ электронной подписи получателя сообщения;

-    P_s — ключ проверки электронной подписи отправителя сообщения, представляющий собой точку на эллиптической кривой;

-    Р_г— ключ проверки электронной подписи получателя сообщения, представляющий собой точку на эллиптической кривой;

-    UKM — ключевой материал;

-    IV — значение синхропосылки.

4    Общее описание

В настоящих рекомендациях определена структура защищенных данных Content Info. Структура Contentlnfo инкапсулирует один тип содержимого, данный тип также может быть подвергнут дальнейшей инкапсуляции. В настоящих рекомендациях рассмотрено шесть типов содержимого:

-    простые данные (id-data);

-    подписанные данные (signed-data);

-    конверт данных (enveloped-data);

-    хэшированные данные (digested-data);

-    зашифрованные данные (encrypted-data);

-    аутентифицированные данные (authenticated-data).

Для каждого из типов содержимого в настоящих рекомендациях рассматриваются варианты использования стандартов на алгоритмы и механизмы, способы формирования структур данных и параметров и кодирование полученных структур. Для удобства использования описываемых структур принято использовать BER-кодирование (см. ГОСТ Р ИСО/МЭК 8825-1), при котором проверку структуры можно осуществлять за один проход, но для атрибутов структур типа подписанные данные и аутентифицированные данные, в которых может находиться один или несколько нераспознанных получателем атрибутов, требуется использовать DER-кодирование (см. ГОСТ Р ИСО/МЭК 8825-1).

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

5    Общий синтаксис

Следующий идентификатор определяет тип содержимого:

id-ct-Contentlnfo OBJECT IDENTIFIER :

{

iso(l) member-body(2) us(840) rsadsi(113549)

pkcs(l) pkcs9(9) smime(16) ct(l) 6

}

Формат CMS связывает идентификатор типа содержимого с самим содержимым. Тип Contentlnfo в формате АСН.1 представлен следующим образом:

Contentlnfo ::= SEQUENCE

{

contentType    ContentType,

content(0)    EXPLICIT ANY DEFINED BY contentType

}

ContentType :OBJECT IDENTIFIER

Поля структуры Content Info имеют следующий смысл:

-    contentType — тип соответствующего содержимого:

-    content — соответствующее содержимое. Тип содержимого может быть однозначно определен по идентификатору в поле contentType. В настоящих рекомендациях рассмотрены следующие типы содержимого: «простые данные» (id-data), «подписанные данные» (signed-data), «конверт данных» (enveloped-data), «хэшированные данные» (digested-data), «зашифрованные данные» (encrypted-data), «аутентифицированные данные» (authenticated-data).

6    Содержимое типа «простые данные»

Содержимое типа «простые данные» определено следующим идентификатором:

id-data OBJECT IDENTIFIER

{

iso(l) member-body(2) us(840) rsadsi(113549) pkcs(l) pkcs7(7) 1

}

Тип содержимого «простые данные» предназначен для обозначения произвольной строки байтов, например текстовые файлы ASCII. Такие строки не должны иметь никакой значимой для CMS формата внутренней структуры (несмотря на то что они могут иметь собственные внутренние структуры).

7    Содержимое типа «подписанные данные»

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

Примером применения типа «подписанные данные» является использование электронной подписи содержимого в сертификатах и списках аннулированных сертификатов (далее — САС).

Процесс построения содержимого типа «подписанные данные» состоит из следующих шагов:

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

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

-для каждого отправителя полученное значение хэш-функции hash подписывают с использованием его ключа ЭП:

-    для каждого отправителя значение подписи и другую специфичную для данного отправителя информацию записывают в структуру Signer Inf о (см. 7.3). На этом шаге также записывают сертификаты и САС как для отправителя, осуществившего подпись, так и для остальных отправителей:

-    значения хэш-функций для всех отправителей и структуру Signerlnf о для всех отправителей записывают вместе с содержимым в структуру SignedData (см. 7.1).

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

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

-    посредством идентификатора ключа субьекта (Subject Key Identifier). который однозначно идентифицирует ключ проверки ЭП отправителя.

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

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

Поддержка различных групп получателей является основной причиной того, что издатели включают более одной подписи. Например, тип содержимого «подписанные данные» может включать в себя подписи, созданные с помощью алгоритма подписи ГОСТ Р 34.10. Это позволяет получателям проверять подписи, полученные с помощью разных алгоритмов.

7.1 Тип SignedData

Следующий идентификатор определяет тип содержимого SignedData: id-signedData OBJECT IDENTIFIER :

{

iso(l) member-body(2) us(840) rsadsi(113549) pkcs(l) pkcs7(7) 2

Содержимое типа «подписанные данные» представлена в виде структуры SignedData. Структура SignedData в формате АСН.1 приведена следующим образом:

Типы CMSVersion, Algorithmldentifier, CertificateSet. RevocationlnfoChoices определены в разделе 14; тип EncapsulatedContentlnfo — в 7.2, тип Signerlnfo —в 7.3.

Поля структуры SignedData имеют следующий смысл:

-version — версия синтаксиса. Точное значение зависит от полей CertificateSet. eContentType и Signerlnfo. Версия синтаксиса должна быть определена согласно (1). 5.1;

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

-    encapContentlnfo — подписываемое содержимое; которое состоит из идентификатора типа содержимого и самого содержимого. Подробнее структура EncapsulatedContentlnfo описана в 7.2;

-    certificates — набор сертификатов. Предполагается, что множество сертификатов достаточно. для того чтобы построить цепочки сертификатов от корня или от центра сертификации верхнего уровня до всех субъектов в Signerlnfo. Сертификатов может быть больше, чем это необходимо для построения цепочки сертификатов от двух или более центров сертификации верхнего уровня. Сертификатов может быть меньше, чем это необходимо, если получатели имеют альтернативные способы получения необходимых сертификатов (например, из предыдущего набора сертификатов). Сертификат отправителя, подписавшего сообщение, также может быть включен в сообщение.

-    crls — списки аннулированных сертификатов. Предполагается, что САС достаточно, для того чтобы проверить корректность сертификата на отзыв, но эта проверка не обязательна;

-    signerlnfos —данные о каждом субъекте подписи. Список может состоять из любого числа элементов, в том числе может быть пустым (подробнее о Signerlnfo см. 7.3). Так как каждый отправитель может использовать различные методы ЭП и будущие спецификации могут обновить синтаксис, все реализации должны корректно обрабатывать неподдерживаемые версии Signerlnfo. Все реализации должны корректно обрабатывать неподдерживаемые алгоритмы подписи в случае их использования.

7.2 Тип EncapsulatedContentlnfo

Тип EncapsulatedContentlnfo в формате АСН.1 представляется следующим образом:

EncapsulatedContentlnfo    SEQUENCE

{

eContentType    ContentType,

eContent[0]    EXPLICIT OCTET STRING OPTIONAL

}

ContentType ::= OBJECT IDENTIFIER

Поля структуры EncapsulatedContentlnfo имеют следующий смысл:

-    eContentType — идентификатор объекта, однозначно определяющий тип содержимого;

-    eContent — содержимое, представленное в виде строки байтов. Содержимое не обязано кодироваться в DER.

Опциональный пропуск параметра eContent позволяет создавать так называемые «отделяемые подписи». В случае внешней подписи подписываемое содержимое отсутствует в структуре EncapsulatedContentlnfo. Если подписываемое содержимое в составе структуры EncapsulatedContentlnfo не представлено, то тип содержимого, параметр eContentType, должен быть указан в соответствии с реальным содержимым.

В вырожденном случае, в котором отсутствуют субъект подписи, использование значения EncapsulatedContentlnfo нецелесообразно. В этом случае тип подписываемого содержимого в EncapsulatedContentlnfo должен представлять собой «простые данные» (см. раздел 6), а содержимое поля EncapsulatedContentlnfo должно быть опущено

7.3 Тип Signerlnfo

Информация для каждого подписавшего представлена в виде структуры Signerlnfo: Signerlnfo ::= SEQUENCE {

issuerAndSerialNumber    IssuerAndSerialNumber,

subjectKeyldentifier [0]    SubjectKeyldentifier

Subject Key Identifier ::= OCTET STRING DigestAlgorithmldentifier := Algorithmldentifier SignatureAlgorithmldentifier := Algorithmldentifier SignedAttributes ::= SET SIZE (1..MAX) OF Attribute UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute SignatureValue :OCTET STRING

Тилы CMSVersion. Algorithmldentifier, CertificateSet, RevocationlnfoChoic-es. IssuerAndSerialNumber. Attribute определены в разделе 14

Поля структуры Signerlnfo имеют следующий смысл:

-    version — версия синтаксиса; значение данного параметра зависит от варианта указания ключа проверки ЭП отправителя (более подробно см. поле sid, определенное ниже). Версия синтаксиса должна быть определена согласно [1J. 5.3;

-    sid — поле, определяющее сертификат отправителя (и соответственно его ключ проверки ЭП). Ключ проверки ЭП отправителя необходим получателю для проверки подписи. Signerldentifier предоставляет два варианта указания ключа проверки ЭП отправителя. Первый вариант