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

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

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

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

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

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

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

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

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

ГОСТ Р 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.1.1 электронная подпись; ЭП: Строка бит, полученная в результате процесса формирования подписи.

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

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

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

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

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

3.1.6

3.1.7

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

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

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

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

- B_s - множество байтовых строк длины s, s >= 0. Строка b = (b₁,..., b_s) принадлежит множеству B_s, если . При n = 0 множество B_s состоит из единственной пустой строки длины 0;

- b[i..j] - строка , где ;

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

- A||B - конкатенация строк , т.е. строка из V_|A|+|B|, в которой подстрока с большими номерами компонент из V_|A| совпадает со строкой A, а подстрока с меньшими номерами компонент из V_|B| совпадает со строкой B;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы CMSVersion, AlgorithmIdentifier, CertificateSet, RevocationInfoChoices определены в разделе 14; тип EncapsulatedContentInfo - в 7.2, тип SignerInfo - в 7.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы CMSVersion, AlgorithmIdentifier, CertificateSet, RevocationInfoChoices, IssuerAndSerialNumber, Attribute определены в разделе 14.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типы CMSVersion, OriginatorInfo, AlgorithmIdentifier, Attribute определены в разделе 14, тип RecipientInfo - в 8.2.

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

- version - номер версии синтаксиса. Версия синтаксиса должна быть определена согласно [1], 6.1;

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

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

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

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

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

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

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

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

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

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

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

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

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

- ГОСТ Р 34.12 "Магма" - n = 12;

- ГОСТ Р 34.12 "Кузнечик" - n = 16.

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

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

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

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

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

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

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

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

Типы KeyTransRecipientInfo, KeyAgreeRecipientInfo, KEKRecipientInfo определены в 8.2.1 - 8.2.3, соответственно. Типы PasswordRecipientinfo и OtherRecipientInfo не рассматривают в данной спецификации.

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

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

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

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

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

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

- сообщения с использованием структур типа KeyAgreeRecipientInfo и KEKRecipientInfo;

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

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

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

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

- version - номер версии синтаксиса; в зависимости от значения поля rid типа RecipientIdentifier номер версии равен или 0, или 2:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- EnvelopedData.EncryptedContentInfo.contentEncryptionAlgorithm;

- EncryptedData.EncryptedContentInfo.contentEncryptionAlgorithm (определение структуры EncryptedData см. в разделе 10).

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

При использовании идентификатора 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 вычисление имитовставки осуществлено с помощью шифра "Магма" по ГОСТ Р 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 шифрование произведено с помощью блочного шифра "Кузнечик" по ГОСТ Р 34.12 в режиме CTR-ACPKM согласно Р 1323565.1.017. При этом длина блока гаммы s, приведенная в Р 1323565.1.017, равна 128 бит; размер секции (см. Р 1323565.1.017) - 256 Кбайт.

При использовании идентификатора 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.EncryptedContentInfo.encryptedContent;

- EncryptedData.EncryptedContentInfo.encryptedContent.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- с использованием ключа шифрования K(1), выработанного из K_me, осуществлено расшифрование с начальным значением IV, равным соответствующим полям:

- последние n байт расшифрованного текста, где n зависит от выбранного алгоритма выработки имитовставки, обозначены как mac-text;

- с использованием ключа имитозащиты K(2), выработанного из K_me, осуществлено вычисление имитовставки для расшифрованного текста за исключением имитовставки. Результирующее значение обозначено как mac-count;

- полученный mac-text сравнивается с вычисленным mac-count. При несовпадении размеров или значений сообщение считается искаженным.

Исходными данными для процесса зашифрования ключа служит значение ключа шифрования содержимого K_me. Шифрование ключа содержимого осуществлено на ключе шифрования ключей, вырабатываемом или генерируемом исходя из выбранного механизма управления ключами. Любой из указанных выше механизмов управления ключами может быть использован для каждого получателя содержимого. Операция зашифрования отображает произвольную строку байтов (данные) в другую строку байтов (зашифрованный текст) с использованием ключа шифрования. Зашифрованный ключ включается в поле структуры EnvelopedData.RecipientInfo. EncryptedKey в зависимости от выбранного механизма управления ключами.

В данном пункте изложены рекомендации, используемые при реализации CMS с поддержкой шифрования ключей согласно алгоритмам KExp15 (см. Р 1323565.1.017).

Алгоритм зашифрования ключа описан в поле keyEncryptionAlgorithm.algorithm и должен принимать одно из следующих значений:

Для механизмов управления ключами ktri и kari дополнительными параметрами для алгоритма зашифрования ключа служит структура GostR3410-12-KEG-Parameters, расположенная в поле keyEncryptionAlgorithm.parameters. Поле algorithm данной структуры принимает одно из следующих значений:

В зависимости от заданного идентификатора алгоритма согласования (OID) выбирают KEG-256 или KEG-512.

Процедура зашифрования ключа для механизмов управления ключами ktri и kari следующая:

- в зависимости от механизма управления ключами вырабатываются ключи KEK_t и KIM_t;

- в зависимости от алгоритма зашифрования ключа происходит зашифрование ключа на ключе KEK_t и с выработкой имитовставки на ключе KIM_t по алгоритму KExp15 (см. Р 1323565.1.017).

Процедуру расшифрования выполняют аналогично.

8.4.2.1 Процесс формирования и разбора ключей на основе статического протокола Диффи - Хеллмана

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

- проверяют соответствие параметров ключа проверки ЭП отправителя и ключа проверки ЭП получателя. При несовпадении параметров алгоритм завершается с ошибкой;

- в качестве ключа K_s принимают ключ ЭП отправителя;

- заполняют поле EnvelopedData.recipientInfos.kari.originator в зависимости от желаемого способа задания ключа проверки ЭП отправителя (см. 8.2.2). Параметры и битовое представление ключа проверки ЭП в точности совпадают с их представлением в сертификате (см. [2]);

- вырабатывается уникальный (случайный) ненулевой UKM длиной 32 байта, который кодируется по правилам типа OCTET STRING и записывается в поле EnvelopedData.recipientInfos.kari.ukm;

- для каждого получателя вырабатываются два ключа KEK_t и KIM_t с использованием ключа K_s, ключа проверки ЭП получателя P_r, UKM и алгоритма KEG (см. Р 1323565.1.020-2018, 6.4.5):

- вырабатывается случайный симметричный ключ K_m, соответствующий алгоритму, указанному в поле EnvelopedData.encryptedContentInfo.contentEncryptionAlgorithm;

- для каждого получателя осуществлен экспорт ключа K_m на ключах KEK_t и KIM_t с использованием алгоритма экспорта KExp15 (см. Р 1323565.1.017), при этом в качестве ключа принимается ключ KIM_t; в качестве ключа - ключ KEK_t. В качестве IV используется UKM[25..24 + n/2], где n - длина блока, выраженная в байтах;

- результатом работы алгоритма KExp15 является строка KEXP, содержащая в себе зашифрованный ключ и имитовставку в соответствии с Р 1323565.1.017;

- результирующая строка KEXP записана в поле EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.encryptedKey.

Для получения сессионного ключа K_m из сообщения M с использованием ключа ЭП K_r применяют следующий алгоритм:

- извлекают строку KEXP из поля EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.encryptedKey, содержащую в себе зашифрованный ключ и имитовставку согласно Р 1323565.1.017;

- выбирают алгоритм и параметры ключа проверки ЭП отправителя P_s из структуры EnvelopedData.recipientInfos.kari.originator с помощью либо сертификата, либо ключа проверки ЭП. Проверяют соответствие алгоритма и параметров собственного ключа ЭП параметрам ключа проверки ЭП отправителя P_s. При несоответствии параметров алгоритм завершается с ошибкой;

- вырабатываются два ключа KEK_t и KIM_t с использованием ключа ЭП получателя K_r, ключа проверки ЭП отправителя P_s, UKM и алгоритма KEG (см. Р 1323565.1.020-2018, 6.4.5.1):

- осуществлены импорт и проверка имитозащиты ключа K_m^EXP на ключах KEK_t и KIM_t с использованием алгоритма KImp15 (см. Р 1323565.1.017). При этом в качестве ключа принимается ключ KIM_t, в качестве ключа - ключ KEK_t. Результатом импорта является ключ K_m.

8.4.2.2 Процесс формирования и разбора ключей на основе эфемерного протокола Диффи - Хеллмана

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

- проверяют, содержат или не содержат все сертификаты получателей расширения KeyUsage и присутствие флага keyAgreement. В последнем случае должен отсутствовать флаг encipherOnly;

- генерируется случайный эфемерный ключ K_E с использованием алгоритма и параметров ключа получателя (см. 12). Обозначают точку P_E на эллиптической кривой E, вычисляемую по следующему равенству:

где P - фиксированная точка эллиптической кривой E, определяемая значением идентификатора, содержащегося в сертификате ключа проверки ЭП P_r;

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

- заполняются поля EnvelopedData.recipientInfos.ktri.rid или EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.rid в зависимости от выбранного алгоритма согласования ключей. Алгоритм и параметры эфемерного ключа проверки ЭП отправителя помещаются в поле EnvelopedData.recipientInfos.ktri.encryptedKey.ephemeralPublicKey или в поле EnvelopedData.recipientInfos.kari.originator.originatorKey.algorithm. Ключ проверки ЭП P_E помещается в поле ephemeralPublicKey.publicKey или в поле EnvelopedData.recipientInfos.kari.originator.originatorKey.publicKey. Идентификаторы объектов АСН.1, параметры, битовое представление в точности совпадает с представлением подписи в сертификате, описанным в [2];

- вырабатывается уникальный (случайный) ненулевой UKM длиной 32 байта, который кодируется по правилам типа OCTET STRING и записывается в поле EnvelopedData.recipientInfos.ktri.encryptedKey.ukm или в поле EnvelopedData.recipientInfos.kari.ukm;

- вырабатываются два ключа KEK_t и KIM_t с использованием ключа K_E, ключа проверки ЭП получателя P_r, UKM и алгоритма KEG (см. Р 1323565.1.020-2018, 6.4.5.1):

- вырабатывается случайный симметричный ключ K_m, соответствующий алгоритму в поле EnvelopedData.encryptedContentInfo.contentEncryptionAlgorithm;

- осуществляется экспорт ключа K_m на ключах KEK_t и KIM_t с использованием алгоритма экспорта KExp15 (см. Р 1323565.1.017), при этом в качестве ключа принимается ключ KIM_t; в качестве ключа - ключ KEK_t. В качестве IV использован UKM [25..24 + n/2], где n - длина блока, выраженная в байтах;

- результатом работы алгоритма KExp15 является строка KEXP, содержащая в себе зашифрованный ключ и имитовставку в соответствии с Р 1323565.1.017;

- результирующая строка KEXP записана в поле EnvelopedData.recipientInfos.ktri.encryptedKey.encryptedKey или в поле EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.encryptedKey.

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

Для получения сессионного ключа K_m из сообщения M с использованием ключа ЭП K_r применен следующий алгоритм:

- извлекают строку KEXP из поля EnvelopedData.recipientInfos.ktri.encryptedKey.encryptedKey или из поля EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.encryptedKey, содержащую зашифрованный ключ и имитовставку согласно Р 1323565.1.017;

- выбирают алгоритм, параметры и ключ проверки ЭП отправителя P_E из структуры EnvelopedData.recipientInfos.ktri.rid или EnvelopedData.recipientInfos.kari.recipientEncryptedKeys.rid с помощью либо сертификата, либо ключа проверки ЭП. Проверяют соответствие алгоритма и параметров собственного ключа ЭП параметрам ключа проверки ЭП отправителя P_E. При несоответствии параметров алгоритм завершается с ошибкой;

- вырабатываются два ключа KEK_t и KIM_t с использованием ключа ЭП получателя K_r, ключа проверки ЭП отправителя P_E, UKM и алгоритма KEG (см. Р 1323565.1.020-2018, 6.4.5.1):

- осуществляются импорт и проверка имитозащиты ключа на ключах KEK_t и KIM_t с использованием алгоритма KImp15 (см. Р 1323565.1.017). При этом в качестве ключа принимается ключ KIM_t; в качестве ключа - ключ KEK_t. Результатом импорта является ключ K_m.

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

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

Для построения содержимого типа "хэшированные данные" выполняют следующие шаги:

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

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

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

Следующий идентификатор определяет тип "хэшированные данные":

Содержимое типа "хэшированные данные" представлено в виде структуры DigestedData. Структура DigestedData в формате АСН.1 приведена следующим образом:

Типы CMSVersion и AlgorithmIdentifier определены в разделе 14; тип EncapsulatedContentInfo - в 7.2.

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

- version - номер версии синтаксиса. Версия синтаксиса должна быть определена согласно [1], раздел 7;

- digestAlgorithm - определение алгоритма хэширования и его параметров. Процесс вычисления хэш-функции аналогичен процессу, описанному в 7.4, за исключением того, что отсутствуют подписанные атрибуты. Если поле parameters не использовано, его значение должно отсутствовать полностью;

- encapContentInfo - хэшируемое содержимое в соответствии с определением согласно 7.2;

- digest - результат хэширования.

Порядок следования полей в digestAlgorithm, encapContentInfo, digest позволяет обработать значение DigestedData за один проход.

В данном подразделе изложены правила использования алгоритмов хэширования по ГОСТ Р 34.11, применяемые в CMS.

Формат и идентификаторы алгоритмов полностью соответствуют [3].

Использование хэш-кодов в разных типах содержимого в форматах:

- хэш-код указан в поле digest структуры DigestedData для типа содержимого "хэшированные данные";

- хэш-код указан в подписанном атрибуте MessageDigest для типов содержимого, имеющих возможность использования подписанного атрибута;

- хэш-код указан входным параметром для алгоритмов подписей.

Алгоритм хэширования по ГОСТ Р 34.11 с длиной хэш-кода 256 бит имеет следующий идентификатор:

Для задания поля digest структуры DigestedData или при наличии подписанного атрибута MessageDigest значение хэш-функции сообщения содержит 32 байта:

GostR3411-2012-256-Digest ::= OCTET STRING (SIZE (32))

Представление значения хэш-кода соответствует значению h алгоритма ГОСТ Р 34.11 в виде строки байтов и записывается в формате little-endian (старший байт справа).

Алгоритм хэширования по ГОСТ Р 34.11 с длиной хэш-кода 512 бит имеет следующий идентификатор:

Для задания поля digest структуры DigestedData или при наличии подписанного атрибута MessageDigest значение хэш-функции сообщения содержит 64 байта:

GostR3411-2012-512-Digest ::= OCTET STRING (SIZE (64))

Представление значения хэш-кода соответствует значению h алгоритма ГОСТ Р 34.11 в виде строки байтов и записывается в формате little-endian (старший байт справа).

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

Как правило, тип "зашифрованные данные" применяют для хранения шифрованных локальных данных.

Следующий идентификатор определяет тип "зашифрованные данные":

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

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

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

- version - номер версии синтаксиса. Версия синтаксиса должна быть определена согласно [1], раздел 8;

- encryptedContentInfo - зашифрованное содержимое (подробнее см. 8.1);

- unprotectedAttrs - набор незашифрованных атрибутов, являющийся необязательным полем.

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

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

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

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

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

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

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

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

Следующий идентификатор определяет данные типа "аутентифицированные данные":

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

Типы CMSVersion, OriginatorInfo, AlgorithmIdentifier, Attribute определены в разделе 14, тип RecipientInfo - в 8.2, тип EncapsulatedContentInfo - в 7.2.

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

- version - номер версии синтаксиса. Версия синтаксиса должна быть определена согласно [1], 9.1;

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

- recipientInfos - список информации о каждом из получателей, данный список не может быть пустым (подробнее см. 8.1);

- macAlgorithm - определение алгоритма вычисления имитовставки и его параметров, которые использует отправитель. Расположение поля macAlgorithm позволяет выполнять обработку сообщения за один проход;

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

- encapContentInfo - хэшируемое содержимое в соответствии с определением согласно 7.2;

- authAttrs - набор аутентифицируемых атрибутов. Поле не является обязательным, но оно должно присутствовать, если тип содержимого структуры EncapsulatedContentInfo не представляет собой "простые данные". Если поле authAttrs присутствует, то и поле digestAlgorithm также должно присутствовать. Поле authAttrs должно быть представлено в DER-кодировке, даже если остальная часть структуры кодируется в BER-кодировку. Если поле присутствует, то оно должно содержать, как минимум два атрибута:

- content-type - атрибут, определяющийся значением типа содержимого EncapsulatedContentInfo (см. 13.1),

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

- mac - значение имитовставки;

- unauthAttrs - набор неаутентифицируемых атрибутов. Поле не является обязательным.

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

- при отсутствии атрибутов в поле authAttrs имитовставка вычисляется для содержимого поля encapContentInfo.eContent;

- при наличии атрибутов в поле authAttrs для содержимого encapContentInfo.eContent вычисляется хэш-код и помещается в поле message-digest, а имитовставка вычисляется для всего содержимого authAttrs.

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

Если поле authAttrs присутствует, то атрибут content-type (см. 13.1) и атрибут message-digest (см. 13.2) должны быть включены в результат вычисления имитовставки, и входным параметром для алгоритма вычисления имитовставки является закодированный атрибут authAttrs в DER-кодировке. Тэг IMPLICIT[2] в поле authAttrs не используется для DER-кодирования, для этого применяется тэг EXPLICIT SET OF. То есть в вычисление имитовставки должен быть включен DER закодированный тэг SET OF, а не тэг IMPLICIT[2], вместе с длиной и содержимым значения authAttrs.

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

Входными параметрами для алгоритма вычисления имитовставки являются данные, определенные выше, и ключ аутентификации, передаваемый в структуре recipientInfo. Подробности вычисления имитовставки зависят от используемого алгоритма. Идентификатор алгоритма вместе со своими параметрами, которые задает отправитель для алгоритма вычисления имитовставки, передается в поле macAlgorithm. Имитовставка, вычисленная отправителем, кодируется в строку байтов и записывается в поле mac.

Входными параметрами для алгоритма выработки имитовставки для последующего сравнения полученного результата с передаваемым в сообщении служат данные (определяется наличием или отсутствием поля authAttrs, см. 11.2) и ключ аутентификации, передаваемый в структуре recipientInfo. Подробности вычисления имитовставки зависят от используемого алгоритма (см. 11.4).

Получатель не должен полагаться на вычисленные отправителем значения имитовставки и хэш-функции. Содержимое аутентифицируется в соответствии с описанием, приведенным в 11.2. Если отправитель включил аутентифицируемые атрибуты, то содержимое поля authAttrs определяется в соответствии с 11.2. Получатель должен вычислить значение хэш-функции от сообщения и убедиться в его совпадении со значением message-digest в составе authAttrs. Для успешной аутентификации значение имитовставки, вычисленной получателем, должно совпадать со значением имитовставки в поле mac, также должны совпадать соответствующие значения хэш-функций.

В данном подразделе изложены соглашения, используемые при реализации CMS с поддержкой кода аутентификации сообщения, согласно Р 50.1.113.

Идентификаторы алгоритма указаны в поле AuthenticatedData.macAlgorithm.

Значения кода аутентификации указываются в поле AuthenticatedData.mac.

Ключ аутентификации генерируется случайным образом (см. 12) и должен быть защищен на основе алгоритма согласования ключей, изложенного в 8.2.

В основе функции HMAC_GOSTR3411_2012_256 лежит функция хэширования по ГОСТ Р 34.11 с длиной хэш-кода 256 бит (см. Р 1323565.1.017).

В настоящих рекомендациях для данного алгоритма указан следующий идентификатор объекта (OID):

В основе функции HMAC_GOSTR3411_2012_512 лежит функция хэширования по ГОСТ Р 34.11 с длиной хэш-кода 512 бит (см. Р 1323565.1.017).

В настоящих рекомендациях для данного алгоритма указан следующий идентификатор объекта (OID):

Следует учитывать, что аутентификация содержимого обеспечена использованием статического протокола Диффи - Хеллмана для содержимого типов "конверт данных" и "аутентифицированные данные". Для обеспечения аутентификации содержимого типа "конверт данных" с использованием эфемерного протокола Диффи - Хеллмана и для содержимого типа "зашифрованные данные" необходимо предварительно оборачивать содержимое указанных типов в содержимое типа "подписанные данные" или в содержимое типа "аутентифицированные данные" с использованием статического протокола Диффи - Хеллмана.

При использовании статического протокола Диффи - Хеллмана не рекомендуется использовать представление ключа проверки ЭП отправителя в виде чистого ключа (originatorKey[1] OriginatorPublicKey в структуре, приведенной в 8.2.2), так как данный вариант не защищен от подмены отправителя.

Для генерации случайных данных (в том числе и случайных ключей) необходимо использовать датчики случайных чисел согласно Р 1323565.1.012.

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

- "подписанные данные";

- "конверт данных";

- "хэшированные данные";

- "зашифрованные данные";

- "аутентифицированные данные".

Атрибут content-type определяет тип содержимого ContentInfo в содержимом типов "подписанные данные" или "аутентифицированные данные". Атрибут content-type должен присутствовать тогда, когда подписанные атрибуты присутствуют в данных типа "подписанные данные" или аутентифицированные атрибуты присутствуют в данных типа "аутентифицированные данные". Значение атрибута content-type должно соответствовать значению поля encapContentInfo.eContentType в данных обоих типов.

Тип атрибута content-type должен быть подписанным или аутентифицированным атрибутом и не должен быть неподписанным атрибутом, неаутентифицированным атрибутом или незащищенным атрибутом.

Следующий идентификатор определяет атрибут content-type:

Атрибут content-type в формате АСН.1 представлен типом ContentType:

ContentType ::= OBJECT IDENTIFIER

Так как синтаксис определяет SET OF AttributeValue, то атрибут content-type должен содержать единственное значение; ноль или несколько экземпляров AttributeValue не допускаются.

Синтаксис SignedAttributes и AuthAttributes определяются как SET OF Attributes. Структура SignedAttributes в SignerInfo не должна включать несколько экземпляров атрибута content-type. Аналогично, структура AuthAttributes в AuthenticatedData не должна включать несколько экземпляров атрибута content-type.

Атрибут message-digest содержит хэш-код от подписываемого содержимого из поля encapContentInfo.eContent в данных типа "подписанные данные" (см. раздел 7) или в данных типа "аутентифицированные данные" (см. раздел 11). Для данных типа "подписанные данные" значение хэш-функции вычисляется с использованием алгоритма хэширования подписывающего; для данного типа "аутентифицированные данные" значение хэш-функции - с использованием алгоритма хэширования отправителя.

В данных типа "подписанные данные" подписанный атрибут message-digest должен присутствовать, если присутствуют любые подписанные атрибуты. В данных типа "аутентифицированные данные" аутентифицированный атрибут message-digest должен присутствовать, если присутствует любой аутентифицированный атрибут.

Атрибут message-digest должен быть подписанным атрибутом или аутентифицированным атрибутом и не должен быть неподписанным атрибутом, неаутентифицированным атрибутом или незащищенным атрибутом.

Следующий идентификатор определяет атрибут message-digest:

Атрибут message-digest в формате АСН.1 представлен типом MessageDigest:

MessageDigest ::= OCTET STRING

Атрибут message-digest должен содержать единственное значение, несмотря на то что синтаксис определяет SET OF AttributeValue. Он не должен быть пустым или содержать несколько экземпляров AttributeValue.

Синтаксис SignedAttributes и синтаксис AuthAttributes определяют SET OF Attribute. Поле SignedAttributes в структуре SignerInfo должно включать только один экземпляр атрибута message-digest. Аналогично, поле AuthAttributes в структуре AuthenticatedData должно включать только один экземпляр атрибута message-digest.

Атрибут countersignature указывает одну или несколько подписей на значение поля SignerInfo.SignatureValue, содержащих байты подписи для данных типа "подписанные данные". Значение хэш-функции для вычисления удостоверяющей подписи формируется из непосредственно байтов самой подписи, не включая в себя байты тэга и длины. Таким образом, атрибут countersignature удостоверяет другую подпись.

Атрибут countersignature должен быть неподписанным атрибутом и не должен быть подписанным атрибутом, аутентифицированным атрибутом, неаутентифицированным атрибутом или незащищенным атрибутом.

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

Атрибут countersignature в формате АСН.1 представлен типом Countersignature:

Countersignature ::= SignerInfo

Значение countersignature имеет такое же значение, как SignerInfo для обычных подписей, за исключением того, что:

- поле signedAttributes не должно содержать атрибут content-type; для удостоверяющих подписей содержимое отсутствует;

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

- входными параметрами для алгоритма вычисления хэш-функции служат байты поля signatureValue структуры SignerInfo, представленного в DER-кодировке.

Атрибут countersignature может содержать несколько значений. Синтаксис определяет SET OF AtrtributeValue и должен содержать один или несколько экземпляров AttributeValue.

Синтаксис атрибута UnsignedAttributes определяется как SET OF Attributes. Атрибут UnsignedAttributes в signerInfo может содержать несколько экземпляров атрибута countersignature.

Атрибут countersignature, так как он имеет тип SignerInfo, сам по себе может содержать атрибут countersignature. Таким образом, можно построить вложенную структуру из атрибутов countersignature.

Атрибут content-mac содержит зашифрованное значение имитовставки, выработанное от незашифрованного значения содержимого сообщения. Формат атрибута представлен в следующей структуре:

Следующий идентификатор определяет атрибут content-mac:

Атрибут content-mac должен содержать единственное значение, хотя синтаксис определяет SET OF AttributeValue. Он не должен быть пустым или содержать несколько экземпляров AttributeValue.

CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }

Данный тип определяет номер версии синтаксиса для последующей совместимости с новыми версиями спецификации.

Тип IssuerAndSerialNumber определяет сертификат и тем самым ключ проверки ЭП. Данный тип представляет собой структуру со следующими значениями полей:

- issuer - имя издателя сертификата;

- serialNumber - серийный номер сертификата.

Тип RevocationInfoChoices определяет множество источников информации об аннулированных сертификатах. Предполагается, что информации достаточно для того, чтобы проверить корректность сертификата на отзыв, но эта проверка не носит обязательный характер. Тип RevocationInfoChoice предоставляет два варианта указания источников информации об аннулированных сертификатах. Первый - crl - списки аннулированных сертификатов, второй - other - любые другие источники информации.

Данный тип представляет собой структуру со следующими значениями полей:

- algorithm - идентификатор используемого алгоритма;

- parameters - параметры используемого алгоритма.

Тип CertificateChoices определяет различные варианты указания формата сертификата:

- certificate - информация о сертификате;

- extendedCertificate - сертификат формата PKCS #6, устарел;

- v1AttrCert - сертификат версии 1 X.509, устарел;

- v2AttrCert - сертификат версии 2 X.509;

- other - другой формат.

Информация о сертификате представляет собой следующую подписанную структуру:

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

- version - версия сертификата;

- serialNumber - серийный номер;

- signature - определение алгоритма подписи;

- issuer - имя издателя сертификата;

- validity - время жизни сертификата;

- subject - имя субъекта сертификата;

- subjectPublicKeyInfo - информация о ключе проверки ЭП издателя сертификата.

CertificateSet ::= SET OF CertificateChoices

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

Тип OriginatorInfo представляет собой структуру со следующими значениями полей:

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

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

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

- keyAttrId - идентификатор атрибутов ключа;

- keyAttr - атрибуты ключа.

Тип Attribute представляет собой структуру со следующими значениями полей:

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

- attrValues - значение атрибута.

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

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

А.1 Данные удостоверяющего центра:

- ключ ЭП УЦ:

092F8D059E97E22B90B1AE99F0087FC4D26620B91550CBB437C191005A290810₁₆

- идентификатор кривой УЦ:

1.2.643.7.1.2.1.1.1

- сертификат УЦ, представленный в кодировке BASE64:

MIIB8DCCAZ2gAwIBAgIEAYy6gTAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2

MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw

MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA4MQ0wCwYDVQQKEwRUSzI2MScwJQYD

VQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwaDAhBggqhQMHAQEB

ATAVBgkqhQMHAQIBAQEGCCqFAwcBAQICA0MABEAaSoKcjw54UACci6svELNF0IYM

RIW8urUsqamIpoG46XCqrVOuI6Q13N4dwcRsbZdqByf+GC2f5ZfO3baN5bTKo4GF

MIGCMGEGA1UdAQRaMFiAFIDZDPeZ+GZNk1OJjsCecS2npzESoTowODENMAsGA1UE

ChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYtYml0

ggQBjLqBMB0GA1UdDgQWBBSA2Qz3mfhmTZNTiY7AnnEtp6cxEjAKBggqhQMHAQED

AgNBAAgv248F4OeNCkhlzJWec0evHYnMBlSzk1lDm0F875B7CqMrKh2MtJHXenbj

Gc2uRn2IwgmSf/LZDrYsKKqZSxk=

А.2 Данные отправителя с ключом длины 256 бит:

- ключ ЭП отправителя с ключом длины 256 бит:

0B20810E449978C7C3B76C6FF77A16C532421139344A058EF56310B6B6F377E8₁₆

- идентификатор кривой отправителя с ключом длины 256 бит:

1.2.643.7.1.2.1.1.1

- сертификат отправителя с ключом длины 256 бит, представленный в кодировке BASE64:

MIIB8zCCAaCgAwIBAgIEAYy6gjAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2

MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw

MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD

VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwaDAhBggqhQMH

AQEBATAVBgkqhQMHAQIBAQEGCCqFAwcBAQICA0MABECWKQ0TYllqg4GmY3tBJiyz

pXUN+aOV9WbmTUinqrmEHP7KCNzoAzFg+04SSQpNNSHpQnm+jLAZhuJaJfqZ6VbT

o4GFMIGCMGEGA1UdAQRaMFiAFIDZDPeZ+GZNk1OJjsCecS2npzESoTowODENMAsG

A1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYt

Yml0ggQBjLqBMB0GA1UdDgQWBBTRnChHSWbQYwnJC62n2zu5Njd03zAKBggqhQMH

AQEDAgNBAB41oijaXSEn58178y2rhxY35/lKEq4XWZ70FtsNlVxWATyzgO5Wliwn

t1O4GoZsxx8r6T/i7VG65UNmQlwdOKQ=

А.3 Данные получателя с ключом длины 256 бит:

- ключ ЭП получателя с ключом длины 256 бит:

0DC8DC1FF2BC114BABC3F1CA8C51E4F58610427E197B1C2FBDBA4AE58CBFB7CE₁₆

- идентификатор кривой получателя с ключом длины 256 бит:

1.2.643.7.1.2.1.1.1

- сертификат получателя с ключом длины 256 бит, представленный в кодировке BASE64:

MIIB8jCCAZ+gAwIBAgIEAYy6gzAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2

MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw

MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA6MQ0wCwYDVQQKEwRUSzI2MSkwJwYD

VQQDEyBSRUNJUElFTlQ6IEdPU1QgMzQuMTAtMTIgMjU2LWJpdDBoMCEGCCqFAwcB

AQEBMBUGCSqFAwcBAgEBAQYIKoUDBwEBAgIDQwAEQL8nghlzLGMKWHuWhNMPMN5u

L6SkGqRiJ6qZxZb+4dPKbBT9LNVvNKtwUed+BeE5kfqOfolPgFusnL1rnO9yREOj

gYUwgYIwYQYDVR0BBFowWIAUgNkM95n4Zk2TU4mOwJ5xLaenMRKhOjA4MQ0wCwYD

VQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1i

aXSCBAGMuoEwHQYDVR0OBBYEFLue+PUb9Oe+pziBU+MvNejjgrzFMAoGCCqFAwcB

AQMCA0EAPP9Oad1/5jwokSjPpccsQ0xCdVYM+mGQ0IbpiZxQj8gnkt8sq4jR6Ya+

I/BDkbZNDNE27TU1p3t5rE9NMEeViA==

А.4 Данные отправителя с ключом длины 512 бит:

- ключ ЭП отправителя с ключом длины 512 бит:

F95A5D44C5245F63F2E7DF8E782C1924EADCB8D06C52D91023179786154CBDB156

1B4DF759D69F67EE1FBD5B68800E134BAA12818DA4F3AC75B0E5E6F9256911₁₆

- идентификатор кривой отправителя с ключом длины 512 бит:

1.2.643.7.1.2.1.2.1

- сертификат отправителя с ключом длины 512 бит, представленный в кодировке BASE64:

MIICNjCCAeOgAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2

MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw

MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRUSzI2MSowKAYD

VQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQwgaowIQYIKoUD

BwEBAQIwFQYJKoUDBwECAQIBBggqhQMHAQECAwOBhAAEgYC0i7davCkOGGVcYqFP

tS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDPs2Sqa13ZN+Ts

/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo6xGunecH1/G4

hMts9HYLnxbwJDMNVGuIHV6gzqOBhTCBgjBhBgNVHQEEWjBYgBSA2Qz3mfhmTZNT

iY7AnnEtp6cxEqE6MDgxDTALBgNVBAoTBFRLMjYxJzAlBgNVBAMTHkNBIFRLMjY6

IEdPU1QgMzQuMTAtMTIgMjU2LWJpdIIEAYy6gTAdBgNVHQ4EFgQUK+19HAscONGx

zCcRpxRAmFHvlXowCgYIKoUDBwEBAwIDQQAbjA0Q41/rIKOOvjHKsAsoEJM+WJf6

/PKXg2JaStthmw99bdtwwkU/qDbcje2tF6mt+XWyQBXwvfeES1GFY9fJ

А.5 Данные получателя с ключом длины 512 бит:

- ключ ЭП получателя с ключом длины 512 бит:

A50315981F0A7C7FC05B4EB9591A62B1F84BD6FD518ACFCEDF0A7C9CF388D1F18757

C056ADA5B38CBF24CDDB0F1519EF72DB1712CEF1920952E94AF1F9C575DC₁₆

- идентификатор кривой получателя с ключом длины 512 бит:

1.2.643.7.1.2.1.2.1

- сертификат получателя с ключом длины 512 бит, представленный в кодировке BASE64:

MIICNTCCAeKgAwIBAgIEAYy6hTAKBggqhQMHAQEDAjA4MQ0wCwYDVQQKEwRUSzI2

MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQwHhcNMDEw

MTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA6MQ0wCwYDVQQKEwRUSzI2MSkwJwYD

VQQDEyBSRUNJUElFTlQ6IEdPU1QgMzQuMTAtMTIgNTEyLWJpdDCBqjAhBggqhQMH

AQEBAjAVBgkqhQMHAQIBAgEGCCqFAwcBAQIDA4GEAASBgKauwGYvUkzz19g0LP/p

zeRdmwy1m+QSy9W5ZrL/AGuJofm2ARjz40ozNbW6bp9hkHu8x66LX7u5zz+QeS2+

X5om18UXriComgO0+qhZbc+Hzu0eQ8FjOd8LpLk3TzzfBltfLOX5IiPLjeum+pSP

0QjoXAVcrop//B4yvZIukvROo4GFMIGCMGEGA1UdAQRaMFiAFIDZDPeZ+GZNk1OJ

jsCecS2npzESoTowODENMAsGA1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjog

R09TVCAzNC4xMC0xMiAyNTYtYml0ggQBjLqBMB0GA1UdDgQWBBSrXT5VKhm/5uff

kwW0XpG19k6AajAKBggqhQMHAQEDAgNBAAJBpsHRrQKZGb22LOzaReEB8rl2MbIR

ja64NaM5h+cAFoHm6t/k+ziLh2A11rTakR+5of4NQ3EjEhuPtomP2tc=

В примере ниже использованы данные получателя и отправителя с ключами длины 512 бит.

А.6.1.1 Содержимое типа "подписанные данные" с атрибутами в кодировке BASE64

MIIENwYJKoZIhvcNAQcCoIIEKDCCBCQCAQExDDAKBggqhQMHAQECAzA7BgkqhkiG

9w0BBwGgLgQsyu7t8vDu6/zt++kg7/Do7OXwIOTr/yDx8vDz6vLz8PsgU2lnbmVk

RGF0YS6gggI6MIICNjCCAeOgAwIBAgIEAYy6hDAKBggqhQMHAQEDAjA4MQ0wCwYD

VQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1i

aXQwHhcNMDEwMTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRU

SzI2MSowKAYDVQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDUxMi1iaXQw

gaowIQYIKoUDBwEBAQIwFQYJKoUDBwECAQIBBggqhQMHAQECAwOBhAAEgYC0i7da

vCkOGGVcYqFPtS1fUIROzB0fYARIe0tclTRpare/qzRuVRapqzzO+K21LDpYVfDP

s2Sqa13ZN+Ts/JUlv59qCFB2cYpFyB/0kh4+K79yvz7r8+4WE0EmZf8T3ae/J1Jo

6xGunecH1/G4hMts9HYLnxbwJDMNVGuIHV6gzqOBhTCBgjBhBgNVHQEEWjBYgBSA

2Qz3mfhmTZNTiY7AnnEtp6cxEqE6MDgxDTALBgNVBAoTBFRLMjYxJzAlBgNVBAMT

HkNBIFRLMjY6IEdPU1QgMzQuMTAtMTIgMjU2LWJpdIIEAYy6gTAdBgNVHQ4EFgQU

K+l9HAscONGxzCcRpxRAmFHvlXowCgYIKoUDBwEBAwIDQQAbjA0Q41/rIKOOvjHK

sAsoEJM+WJf6/PKXg2JaStthmw99bdtwwkU/qDbcje2tF6mt+XWyQBXwvfeES1GF

Y9fJMYIBlDCCAZACAQEwQDA4MQ0wCwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBU

SzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQCBAGMuoQwCgYIKoUDBwEBAgOgga0w

GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwMzIw

MTk1NTIyWjAiBgkqhkiG9w0BCWIxFQQTU2lnbmVkIGF0dHIncyB2YWx1ZTBPBgkq

hkiG9w0BCQQxQgRAUdPHEukF5BIfo9DoQIMdnB0ZLkzq0RueEUZSNv07A7C+GKWi

G62fueArg8uPCHPTUN6d/42p33fgMkEwH7f7cDAKBggqhQMHAQEBAgSBgGUnVka8

FvTlClmOtj/FUUacBdE/nEBeMLOO/535VDYrXlftPE6zQf/4ghS7TQG2VRGQ3GWD

+L3+W09A7d5uyyTEbvgtdllUG0OyqFwKmJEaYsMin87SFVs0cn1PGV1fOKeLluZa

bLx5whxd+mzlpekL5i6ImRX+TpERxrA/xSe5

А.6.1.2 АСН.1 представление содержимого типа "подписанные данные" с атрибутами

В примере ниже использованы данные получателя и отправителя с ключами длины 256 бит.

А.6.2.1 Содержимое типа "подписанные данные" без атрибутов в кодировке BASE64

MIIDAQYJKoZIhvcNAQcCoIIC8jCCAu4CAQExDDAKBggqhQMHAQECAjA7BgkqhkiG

9w0BBwGgLgQsyu7t8vDu6/zt++kg7/Do7OXwIOTr/yDx8vDz6vLz8PsgU2lnbmVk

RGF0YS6gggH3MIIB8zCCAaCgAwIBAgIEAYy6gjAKBggqhQMHAQEDAjA4MQ0wCwYD

VQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1Ni1i

aXQwHhcNMDEwMTAxMDAwMDAwWhcNNDkxMjMxMDAwMDAwWjA7MQ0wCwYDVQQKEwRU

SzI2MSowKAYDVQQDEyFPUklHSU5BVE9SOiBHT1NUIDM0LjEwLTEyIDI1Ni1iaXQw

aDAhBggqhQMHAQEBATAVBgkqhQMHAQIBAQEGCCqFAwcBAQICA0MABECWKQ0TYllq

g4GmY3tBJiyzpXUN+aOV9WbmTUinqrmEHP7KCNzoAzFg+04SSQpNNSHpQnm+jLAZ

huJaJfqZ6VbTo4GFMIGCMGEGA1UdAQRaMFiAFIDZDPeZ+GZNk1OJjsCecS2npzES

oTowODENMAsGA1UEChMEVEsyNjEnMCUGA1UEAxMeQ0EgVEsyNjogR09TVCAzNC4x

MC0xMiAyNTYtYml0ggQBjLqBMB0GA1UdDgQWBBTRnChHSWbQYwnJC62n2zu5Njd0

3zAKBggqhQMHAQEDAgNBAB41oijaXSEn58l78y2rhxY35/lKEq4XWZ70FtsNlVxW

ATyzgO5Wliwnt1O4GoZsxx8r6T/i7VG65UNmQlwdOKQxgaIwgZ8CAQEwQDA4MQ0w

CwYDVQQKEwRUSzI2MScwJQYDVQQDEx5DQSBUSzI2OiBHT1NUIDM0LjEwLTEyIDI1

Ni1iaXQCBAGMuoIwCgYIKoUDBwEBAgIwCgYIKoUDBwEBAQEEQC6jZPA59szL9FiA

0wC71EBE42ap6gKxklT800cu2FvbLu972GJYNSI7+UeanVU37OVWyenEXi2E5HkU

94kBe8Q=

А.6.2.2 АСН.1 представление содержимого типа "подписанные данные" без атрибутов

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

- идентификатор алгоритма шифрования содержимого 1.2.643.7.1.1.5.2.2;

- идентификатор алгоритма шифрования ключа 1.2.643.7.1.1.7.2.1.

А.7.1.1 Содержимое типа "конверт данных" с использованием эфемерного алгоритма согласования ключей

KeyAgreeRecipientInfo в кодировке BASE64

MIIB/gYJKoZIhvcNAQcDoIIB7zCCAesCAQIxggFioYIBXgIBA6CBo6GBoDAXBggq

hQMHAQEBAjALBgkqhQMHAQIBAgEDgYQABIGAe+itJVNbHM35RHfzuwFJPYdPXqtW

8hNEF7Z/XFEE2T71SRkhFX7ozYKQNh/TkVY9D4vG0LnD9Znr/pJyOjpsNb+dPcKX

Kbk/0JQxoPGHxFzASVAFq0ov/yBe2XGFWMeKUqtaAr7SvoYS0oEhT5EuT8BXmecd

nRe7NqOzESpb15ahIgQgsqHxOcdOp03l11S7k3OH1k1HNa5F8m9ctrOzH2846FMw

FwYJKoUDBwEBBwIBMAoGCCqFAwcBAQYCMHYwdDBAMDgxDTALBgNVBAoTBFRLMjYx

JzAlBgNVBAMTHkNBIFRLMjY6IEdPU1QgMzQuMTAtMTIgMjU2LWJpdAIEAYy6hQQw

SxLc18zMwzLwXbcKqYhV/VzsdBgVArOHsSBIbaThJWE7zI37VGPMQJM5VXJ7GVcL

MF0GCSqGSIb3DQEHATAfBgkqhQMHAQEFAgIwEgQQ6EeVlADDCz2cdEWKy+tM94Av

yIFl/Ie4VeFFuczTsMsIaOUEe3Jn9GeVp8hZSj3O2q4hslQ/u/+Gj4QkSHm/M0ih

ITAfBgkqhQMHAQAGAQExEgQQs1t6D3J3WCEvxunnEE15NQ==

А.7.1.2 АСН.1 представление содержимого типа "конверт данных" с использованием эфемерного алгоритма согласования ключей KeyAgreeRecipientInfo

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

- идентификатор алгоритма шифрования содержимого 1.2.643.7.1.1.5.1.1;

- идентификатор алгоритма шифрования ключа 1.2.643.7.1.1.7.1.1.

А.7.2.1 Содержимое типа "конверт данных" с использованием статического алгоритма согласования ключей KeyAgreeRecipientInfo в кодировке BASE64

MIIBawYJKoZIhvcNAQcDoIIBXDCCAVgCAQIxgfehgfQCAQOgQjBAMDgxDTALBgNV

BAoTBFRLMjYxJzAlBgNVBAMTHkNBIFRLMjY6IEdPU1QgMzQuMTAtMTIgMjU2LWJp

dAIEAYy6gqEiBCBvcfyuSF57y8vVyaw8Z0ch3wjC4lPKTrpVRXty4Rhk5DAXBgkq

hQMHAQEHAQEwCgYIKoUDBwEBBgEwbjBsMEAwODENMAsGA1UEChMEVEsyNjEnMCUG

A1UEAxMeQ0EgVEsyNjogR09TVCAzNC4xMC0xMiAyNTYtYml0AgQBjLqDBChPbi6B

krXuLPexPAL2oUGCFWDGQHqINL5ExuMBG7/5XQRqriKARVa0MFkGCSqGSIb3DQEH

ATAbBgkqhQMHAQEFAQEwDgQMdNdCKnYAAAAwqTEDgC9O2bYyTGQJ8WUQGq0zHwzX

L0jFhWHTF1tcAxYmd9pX5i89UwIxhtYqyjX1QHju2g==

А.7.2.2 АСН.1 представление содержимого типа "конверт данных" с использованием статического алгоритма согласования ключей KeyAgreeRecipientInfo

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

- идентификатор алгоритма шифрования содержимого 1.2.643.7.1.1.5.2.1;

- идентификатор алгоритма шифрования ключа 1.2.643.7.1.1.7.2.1.

А.7.3.1 Содержимое типа "конверт данных" с использованием эфемерного алгоритма согласования ключей KeyTransRecipientInfo в кодировке BASE64

MIIBlQYJKoZIhvcNAQcDoIIBhjCCAYICAQAxggEcMIIBGAIBADBAMDgxDTALBgNV

BAoTBFRLMjYxJzAlBgNVBAMTHkNBIFRLMjY6IEdPU1QgMzQuMTAtMTIgMjU2LWJp

dAIEAYy6gzAXBgkqhQMHAQEHAgEwCgYIKoUDBwEBBgEEgbcwgbQEMFiMredFR3Mv

3g2wqyVXRnrhYEBMNFaqqgBpHwPQh3bF98tt9HZPxRDCww0OPfxeuTBeMBcGCCqF

AwcBAQEBMAsGCSqFAwcBAgEBAQNDAARAdFJ9ww+3ptvQiaQpizCldNYhl4DB1rl8

Fx/2FIgnwssCbYRQ+UuRsTk9dfLLTGJG3JIEXKFxXWBgOrK965A5pAQg9f2/EHxG

DfetwCe1a6uUDCWD+wp5dYOpfkry8YRDEJgwXQYJKoZIhvcNAQcBMB8GCSqFAwcB

AQUCATASBBDUHNxmVclO/v3OaY9P7jxOgC+sD9CHGlEMRUpfGn6yfFDMExmYeby8

LzdPJe1MkYV0qQgdC1zI3nQ7/4taf+4zRA==

А.7.3.2 АСН.1 представление содержимого типа "конверт данных" с использованием эфемерного алгоритма согласования ключей KeyTransRecipientInfo

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

- идентификатор алгоритма шифрования содержимого 1.2.643.7.1.1.5.1.2;

- идентификатор алгоритма шифрования ключа 1.2.643.7.1.1.7.1.1.

А.7.4.1 Содержимое типа "конверт данных" с использованием эфемерного алгоритма согласования ключей KeyTransRecipientInfo в кодировке BASE64

MIIB5wYJKoZIhvcNAQcDoIIB2DCCAdQCAQAxggFXMIIBUwIBADBAMDgxDTALBgNV

BAoTBFRLMjYxJzAlBgNVBAMTHkNBIFRLMjY6IEdPU1QgMzQuMTAtMTIgMjU2LWJp

dAIEAYy6hTAXBgkqhQMHAQEHAQEwCgYIKoUDBwEBBgIEgfIwge8EKLgwbJFP21Qe

yKTSzdBqEqvb59bsbZ+xF5+s2Zo0vKNZTYuoIkG7Ks4wgaAwFwYIKoUDBwEBAQIw

CwYJKoUDBwECAQIBA4GEAASBgNPm7e14dXH70hCJhp3PJjBgj45ptP8DB5Cvt2jD

PCnFCOQUugmkMXcDEGoaYiPMicjSJvhZhyOQuwiTveEzRFQE2qLbK51nUJOa0BC9

/4G1v5t79ihoLr1xB5fc4cduy29YE/tb0CU9o14ZyVJdmqzLaSwjDtqLBh+jqD54

KpVJBCBOzTnW69sZQBrqTqxzQI3j4QCpUA1my8IYxUtxlni3pjBZBgkqhkiG9w0B

BwEwGwYJKoUDBwEBBQECMA4EDNmoGe4ZUZlF98u8x4AvoyuvFwsqPRN5DQn+obUB

gfrwMYfqmeZ34MAkb3QYcFyck7+kptHr8wxlO/6/mNGhGTAXBgkqhQMHAQAGAQEx

CgQIyyOpgBfMHxM=

А.7.4.2 АСН.1 представление содержимого типа "конверт данных" с использованием эфемерного алгоритма согласования ключей KeyTransRecipientInfo

В примере ниже представлено содержимое типа "хэшированные данные" с длиной хэш-кода 256 бит.

А.8.1.1 Содержимое типа "хэшированные данные" в кодировке BASE64

MH0GCSqGSIb3DQEHBaBwMG4CAQAwCgYIKoUDBwEBAgIwOwYJKoZIhvcNAQcBoC4E

LMru7fLw7uv87fvpIO/w6Ozl8CDk6/8g8fLw8+ry8/D7IERpZ2VzdERhdGEuBCD/

esPQYsGkzxZV8uUMIAWt6SI8KtxBP8NyG8AGbJ8i/Q==

А.8.1.2 АСН.1 представление содержимого типа "хэшированные данные"

В примере ниже представлено содержимое типа "хэшированные данные" с длиной хэш-кода 512 бит.

А.8.2.1 Содержимое типа "хэшированные данные" в кодировке BASE64

MIGfBgkqhkiG9w0BBwWggZEwgY4CAQAwCgYIKoUDBwEBAgMwOwYJKoZIhvcNAQcB

oC4ELMru7fLw7uv87fvpIO/w60zl8CDk6/8g8fLw8+ry8/D7IERpZ2VzdERhdGEu

BEDe4VUvcKSRvU7RFVhFjajXY+nJSUkUsoi3oOeJBnru4PErt8RusPrCJs614ciH

CM+ehrC4a+M1Nbq77F/Wsa/v

А.8.2.2 АСН.1 представление содержимого типа "хэшированные данные"

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

8F5EEF8814D228FB2BBC5612323730CFA33DB7263CC2C0A01A6C6953F33D61D5₁₆

А.9.1 Содержимое типа "зашифрованные данные" для алгоритма "Магма"

Идентификатор алгоритма шифрования содержимого: 1.2.643.7.1.1.5.1.2.

А.9.1.1 Содержимое типа "зашифрованные данные" в кодировке BASE64

MIGIBgkqhkiG9w0BBwagezB5AgEAMFkGCSqGSIb3DQEHATAbBgkqhQMHAQEFAQIw

DgQMuncOu3uYPbI30vFCgC9Nsws4R09yLp6jUtadncWUPZGmCGpPKnXGgNHvEmUA

rgKJvu4FPHtLkHuLeQXZg6EZMBcGCSqFAwcBAAYBATEKBAjCbQoH632oGA==

А.9.1.2 АСН.1 представление содержимого типа "зашифрованные данные"

Идентификатор алгоритма шифрования содержимого: 1.2.643.7.1.1.5.2.1.

А.9.2.1 Содержимое типа "зашифрованные данные" в кодировке BASE64

MHEGCSqGSIb3DQEHBqBkMGICAQAwXQYJKoZIhvcNAQcBMB8GCSqFAwcBAQUCATAS

BBBSwX+zyOEPPuGyfpsRG4AigC/P8ftTdQMStfIThVkE/vpJlwaHgGv83m2bsPay

eyuqpoTeEMOaqGcO0MxHWsC9hQ==

А.9.2.2 АСН.1 представление содержимого типа "зашифрованные данные"