- национальный стандарт рф гост р 34.10-2021 "информационная технология. криптографическая защита информации. процессы формирования и проверки электронной цифровой подписи" (утв. приказом федерального агентства по техническому регулированию и метрологии от 07.08.2021 n 215-ст) | гарант
- Переход на гост-2021: главное о новом стандарте электронной подписи
- Формат электронной подписи, обязательный для реализации всеми средствами электронной подписи / консультантплюс
национальный стандарт рф гост р 34.10-2021 "информационная технология. криптографическая защита информации. процессы формирования и проверки электронной цифровой подписи" (утв. приказом федерального агентства по техническому регулированию и метрологии от 07.08.2021 n 215-ст) | гарант
Information technology. Cryptographic data security. Generation and verification processes of electronic digital signature
Дата введения – 1 января 2021 г.
3 Термины, определения и обозначения
3.1 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1.10 свидетельство (witness): Элемент данных, представляющий соответствующее доказа-тепьство достоверности (недостоверности) подписи проверяющей стороне.
4 Общие положения
Общепризнанная схема (модель) цифровой подписи (см. ИСО/МЭК 14888-1 [4]) охватывает следующие процессы:
– генерация ключей (подписи и проверки подписи);
– формирование подписи;
– проверка подписи.
В настоящем стандарте процесс генерации ключей (подписи и проверки подписи) не рассмотрен. Характеристики и способы реализации данного процесса определяются вовлеченными в него субъектами, которые устанавливают соответствующие параметры по взаимному согласованию.
Механизм цифровой подписи определяется посредством реализации двух основных процессов (см. раздел 6):
– формирование подписи (см. 6.1);
– проверка подписи (см. 6.2).
Цифровая подпись предназначена для аутентификации лица, подписавшего электронное сообщение. Кроме того, использование ЭЦП предоставляет возможность обеспечить следующие свойства при передаче в системе подписанного сообщения:
– осуществление контроля целостности передаваемого подписанного сообщения;
– доказательное подтверждение авторства лица, подписавшего сообщение;
– защита сообщения от возможной подделки.
Схематическое представление подписанного сообщения показано на рисунке 1.
Рисунок 1 – Схема подписанного сообщения
Поле “Текст”, показанное на данном рисунке и дополняющее поле “Цифровая подпись”, может, например, содержать идентификаторы субъекта, подписавшего сообщение, и/или метку времени.
Установленная в настоящем стандарте схема цифровой подписи должна быть реализована с использованием операций группы точек эллиптической кривой, определенной над конечным простым полем, а также хэш-функции.
Криптографическая стойкость данной схемы цифровой подписи основывается на сложности решения задачи дискретного логарифмирования в группе точек эллиптической кривой, а также на стойкости используемой хэш-функции. Алгоритмы вычисления хэш-функции установлены в ГОСТ Р 34.11-2021.
Параметры схемы цифровой подписи, необходимые для ее формирования и проверки, определены в 5.2. В настоящем стандарте предусмотрена возможность выбора одного из двух вариантов требований к параметрам.
Настоящий стандарт не определяет процесс генерации параметров схемы цифровой подписи. Конкретный алгоритм (способ) реализации данного процесса определяется субъектами схемы цифровой подписи исходя из требований к аппаратно-программным средствам, реализующим электронный документооборот.
Цифровая подпись, представленная в виде двоичного вектора длиной 512 или 1024 бита, должна вычисляться с помощью определенного набора правил, изложенных в 6.1.
Набор правил, позволяющих принять либо отвергнуть цифровую подпись под полученным сообщением, установлен в 6.2.
5 Математические объекты
Для определения схемы цифровой подписи необходимо описать базовые математические объекты, используемые в процессах ее формирования и проверки. В данном разделе установлены основные математические определения и требования, предъявляемые к параметрам схемы цифровой подписи.
5.1 Математические определения
Эллиптической кривой Е, определенной над конечным простым полем (гдер > 3 – простое число), называется множество пар (х, у), х, , удовлетворяющих уравнению
, (1)
где a, и не сравнимо с нулем по модулю р.
Инвариантом эллиптической кривой называется величина J(E), удовлетворяющая уравнению
. (2)
Пары (х, у), где х, y – элементы поля , удовлетворяющие уравнению (1), называются “точками эллиптической кривой E”; х и у – соответственно х- и у-координатами точки.
Точка эллиптической кривой обозначается Q(x, у) или просто Q. Две точки эллиптической кривой равны, если равны их соответствующие х- и у-координаты.
На множестве точек эллиптической кривой E определена операция сложения, обозначаемая знаком ” “. Для двух произвольных точек и эллиптической кривой E рассматривают несколько случаев.
Для точек и , координаты которых удовлетворяют условию , их суммой называется точка , координаты которой определяются сравнениями
, (3)
где .
Если выполнены равенства и , то координаты точки определяются следующим образом:
, (4)
где .
Если выполнены условия и , то сумма точек и называется нулевой точкой О без определения ее х- и у-координат. В этом случае точка называется отрицанием точки Для нулевой точки О выполнены равенства
, (5)
где Q – произвольная точка эллиптической кривой Е.
Относительно введенной операции сложения множество точек эллиптической кривой E вместе с нулевой точкой образуют конечную абелеву (коммутативную) группу порядка m, для которого выполнено неравенство
. (6)
Точка Q называется “точкой кратности k” или просто “кратной точкой эллиптической кривой E”, если для некоторой точки Р выполнено равенство
5.2 Параметры цифровой подписи
Параметрами схемы цифровой подписи являются:
– простое число р – модуль эллиптической кривой;
– эллиптическая кривая E, задаваемая коэффициентами a, ;
– целое число m – порядок группы точек эллиптической кривой E;
– простое число q – порядок циклической подгруппы группы точек эллиптической кривой E, для которого выполнены следующие условия:
; (8)
– точка эллиптической кривой Е, с координатами , удовлетворяющая равенству qP=O;
– хэш-функция , отображающая сообщения, представленные в виде двоичных векторов произвольной конечной длины, в двоичные векторы длины l бит. Хэш-функция определена в ГОСТ Р 34.11-2021. Если . Если .
Каждый пользователь схемы цифровой подписи должен обладать личными ключами:
– ключом подписи – целым числом d, удовлетворяющим неравенству ;
– ключом проверки подписи – точкой эллиптической кривой Q с координатами , удовлетворяющей равенству dP=Q.
К приведенным выше параметрам схемы цифровой подписи предъявляют следующие требования:
– должно быть выполнено условие , для всех целых t = 1, 2, … В, где В = 31, если , и B = 131, если ;
– должно быть выполнено неравенство ;
– инвариант кривой должен удовлетворять условиям: .
5.3 Двоичные векторы
Для определения процессов формирования и проверки цифровой подписи необходимо установить соответствие между целыми числами и двоичными векторами длины l бит.
Рассмотрим следующий двоичный вектор длиной l бит, в котором младшие биты расположены справа, а старшие – слева:
, (9)
где равно либо 1, либо 0.
Число соответствует двоичному вектору , если выполнено равенство
. (10)
Для двух двоичных векторов
,
. (11)
соответствующих целым числам и , операция конкатенации (объединения) определяется следующим образом:
. (12)
Объединение представляет собой двоичный вектор длиной 2l бит, составленный из компонент векторов , и .
Формулы (11) и (12) определяют способ разбиения двоичного вектора длиной 2l бит на два двоичных вектора длиной l бит, конкатенацией которых он является.
6 Основные процессы
В данном разделе определены процессы формирования и проверки цифровой подписи под сообщением пользователя.
Для реализации данных процессов необходимо, чтобы всем пользователям были известны параметры схемы цифровой подписи, соответствующие требованиям 5.2.
Кроме того, каждый пользователь должен иметь ключ подписи d и ключ проверки подписи , которые также должны соответствовать требованиям 5.2.
6.1 Формирование цифровой подписи
Для получения цифровой подписи под сообщением необходимо выполнить следующие действия (шаги) по алгоритму I:
Шаг 1 – вычислить хэш-код сообщения . (13)
Шаг 2 – вычислить целое число , двоичным представлением которого является вектор h, и определить
. (14)
Если е = 0, то определить е = 1.
Шаг 3 – сгенерировать случайное (псевдослучайное) целое число k, удовлетворяющее неравенству
. (15)
Шаг 4 – вычислить точку эллиптической кривой С = кР и определить
, (16)
где – х-координата точки С.
Если r = 0, то вернуться к шагу 3.
Шаг 5 – вычислить значение
. (17)
Если s = 0, то вернуться к шагу 3.
Шаг 6 – вычислить двоичные векторы и , соответствующие r и s, и определить цифровую подпись как конкатенацию двух двоичных векторов.
Исходными данными этого процесса являются ключ подписи d и подписываемое сообщение М, а выходным результатом – цифровая подпись .
Схема процесса формирования цифровой подписи приведена на рисунке 2.
Рисунок 2 – Схема процесса формирования цифровой подписи
6.2 Проверка цифровой подписи
Для проверки цифровой подписи под полученным сообщением М необходимо выполнить следующие действия (шаги) по алгоритму II:
Шаг 1 – по полученной подписи вычислить целые числа r и s. Если выполнены неравенства , то перейти к следующему шагу. В противном случае подпись неверна.
Шаг 2 – вычислить хэш-код полученного сообщения М:
. (18)
Шаг 3 – вычислить целое число , двоичным представлением которого является вектор , и определить
. (19)
Если е = 0, то определить е = 1.
Шаг 4 – вычислить значение . (20)
Шаг 5 – вычислить значения
. (21)
Шаг 6 – вычислить точку эллиптической кривой и определить
, (22)
где – х-координата точки С.
Шаг 7 – если выполнено равенство R = r, то подпись принимается, в противном случае – подпись неверна.
Исходными данными этого процесса являются подписанное сообщение М, цифровая подпись и ключ проверки подписи Q, а выходным результатом – свидетельство о достоверности или ошибочности данной подписи.
Схема процесса проверки цифровой подписи приведена на рисунке 3.
Рисунок 3 – Схема процесса проверки цифровой подписи
Переход на гост-2021: главное о новом стандарте электронной подписи
04 декабря 2021
До конца 2021 года все аккредитованные удостоверяющие центры России должны были перейти на формирование и проверку сертификатов квалифицированной электронной подписи в соответствии со стандартом ГОСТ Р 34.10-2021.
Эксперты «Инфотекс Интернет Траст» рассказывают о процессе перехода на новый криптографический стандарт.
ГОСТ Р 34.10-2021 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи» — российский криптографический стандарт, описывающий алгоритмы формирования и проверки электронной подписи, принятый и введённый в действие вместо ГОСТ Р 34.10-2001 Приказом Федерального агентства по техническому регулированию и метрологии от 7 августа 2021 года №215-ст.
Введение нового стандарта
В начале 2021 года ФСБ России известила разработчиков средств криптографической защиты информации о начале перехода на использование нового национального стандарта ГОСТ Р 34.10-2021 в средствах электронной подписи для информации, не содержащей сведений, составляющих государственную тайну.
Документ ФСБ России №149/7/1/3-58 от 31.01.2021 «О порядке перехода к использованию новых стандартов ЭЦП и функции хэширования», выписка из которого была опубликована на сайте ТК26, устанавливал следующие требования:
- после 31 декабря 2021 года прекратить сертификацию средств электронной подписи на соответствие требованиям к средствам электронной подписи, утверждённым приказом ФСБ России от 27.12.2021 г. №796, если в этих средствах не предусматривается реализация функций в соответствии с ГОСТ Р 34.10-2021;
- после 31 декабря 2021 года запретить использование ГОСТ Р 34.10-2001 для формирования электронной подписи.
В октябре 2021 года Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации опубликовало на портале Федерального ситуационного центра электронного правительства Разъяснение по переходу на ГОСТ Р 34.10-2021, в котором подтверждалось, что использование схемы ГОСТ Р 34.10-2001 для формирования электронной подписи после 31 декабря 2021 года не допускается, в том числе и для формирования списка отзыва сертификатов, а после 31 декабря 2021 года формирование электронной подписи должно производиться по алгоритму ГОСТ Р 34.10-2021.
Также в разъяснении Минкомсвязи сообщалось о том, что выпуск сертификатов для подчиненных аккредитованных удостоверяющих центров с использованием схемы подписи, установленной стандартом ГОСТ Р 34.10-2021, планируется начать не позднее середины июля 2021 года.
Кроме того, в документе говорилось о том, что квалифицированный сертификат пользователя и квалифицированный сертификат аккредитованного удостоверяющего центра, выдавшего его пользователю, должны соответствовать одному стандарту: либо ГОСТ-2021, либо ГОСТ-2001. Если сертификаты будут сформированы в соответствии с разными стандартами, то есть будут иметь различную схему подписи, они не смогут пройти проверку на Едином портале государственных и муниципальных услуг.
В соответствии с разъяснением Минкомсвязи сценарий перевода пользователей на работу с квалифицированными сертификатами, выпущенными по ГОСТ-2021, предполагал, что все пользователи должны будут получить сертификаты, сформированные в соответствии с новым стандартом, несмотря на то, что удостоверяющие центры могли приступить к выпуску этих сертификатов только с августа 2021 года — после получения в Головном удостоверяющем центре квалифицированного сертификата подчинённого удостоверяющего центра, сформированного по ГОСТ-2021.
16 июля 2021 года Минкомсвязь опубликовала Уведомление о начале выпуска сертификатов ключей проверки электронных подписей подчинённых удостоверяющих центров на Головном удостоверяющем центре в соответствии с ГОСТ Р 34.10-2021, после чего аккредитованные удостоверяющие центры, запросившие в Головном удостоверяющем центре сертификат подчинённого удостоверяющего центра, сформированный по ГОСТ-2021, получили возможность выпускать сертификаты пользователей в соответствии с новым стандартом.
Чем вызвана необходимость перехода на новый ГОСТ?
В 2021 году было выпущено два новых стандарта — ГОСТ Р 34.10-2021 по формированию и проверке электронной подписи и ГОСТ Р 34.11-2021 по функции хэширования. Новые стандарты заменили ГОСТ по электронной подписи 2001 года и ГОСТ по функции хэширования 1994 года. В алгоритме формирования и проверки электронной подписи нового стандарта изменений не произошло, а вот функция хеширования существенно изменилась. Новая российская функция хеширования Стрибог с криптографической точки зрения существенно превосходит ту, что использовалась ранее и была описана в стандарте 1994 года.
Информационные технологии и методы криптографического анализ непрерывно развиваются, а стойкость криптографических примитивов должна поддерживаться на неизменно высоком уровне относительно доступных в настоящий момент противнику средств и методов криптоанализа. Для этого была разработана новая функция хэширования.
Проблемы перехода на ГОСТ-2021
В октябре 2021 года, после того как Минкомсвязь объявила о том, что выпуск сертификатов для подчиненных удостоверяющих центров по схеме ГОСТ Р 34.10-2021 планируется начать не ранее июля 2021 года, стало ясно, что к установленному ФСБ России контрольному сроку, после которого запрещается использование ГОСТ-2001, — 31 декабря 2021 года, затруднительно обеспечить безболезненный перевод всех владельцев сертификатов ГОСТ-2001 на сертификаты ГОСТ-2021 без существенных дополнительных расходов со стороны удостоверяющих центров.
В связи с этим весной 2021 года Минкомсвязь инициировала ряд совещаний с представителями аккредитованных удостоверяющих центров по вопросу организации перехода на схему формирования электронной подписи по ГОСТ-2021. В ходе совещаний обсуждались проблемы удостоверяющих центров, связанные с жестким требованием обеспечить всех пользователей сертификатами ГОСТ-2021 до конца 2021 года, поскольку с начала 2021 года использование сертификатов ГОСТ-2001 запрещалось утвержденным ФСБ России порядком перехода на новый стандарт.
Обсуждения выявили главную проблему — неготовность перейти на использование нового стандарта электронной подписи ГОСТ-2021 многих государственных и муниципальных органов исполнительной власти, местного самоуправления муниципальных образований и других органов и организаций, включая ряд кредитных организаций и электронных торговых площадок, а также государственных и ведомственных порталов и информационных систем.
С какими сложностями сопряжён переход на новый ГОСТ?
Процесс перехода на новый ГОСТ достаточно длительный. Средства электронной подписи, в обязательном порядке поддерживающие новые ГОСТы, разрабатываются с конца 2021 года — с этого момента не принимаются технические задания на разработку средств электронной подписи без поддержки ГОСТ Р 34.10/11-2021. Соответственно, поскольку срок действия сертификата на средства электронной подписи и средства удостоверяющего центра обычно составляет 3 года, все такие сертифицированные средства уже давно поддерживают новые алгоритмы.
Сложность в настоящий момент заключается в том, что процесс замены алгоритмов дошёл до массового потребителя, которому аккредитованные Минкомсвязью удостоверяющие центры должны выпускать сертификаты нового образца. Для этого им необходимо оборудование, которое поддерживает новый ГОСТ, и сертификат Головного удостоверяющего центра, сформированный с использованием ГОСТ-2021. Удостоверяющие центры могут получить его с лета 2021 года.
Еще одно препятствие на пути к применению новых сертификатов — неготовность информационных систем к приёму и проверке электронной подписи, сформированной по новому ГОСТу.
Соответственно, для того чтобы переход на новый ГОСТ Р 34.10-2021 завершился, необходима совокупность факторов: удостоверяющие центры должны иметь возможность выпускать сертификаты по новому стандарту, а информационные системы — поддерживать работу с этими сертификатами.
На момент написания статьи (ноябрь 2021 года) проблема в большей степени заключается в готовности информационных систем, чем удостоверяющих центров. Не все информационные системы готовы принимать сертификаты по новому стандарту при том, что до конца года осталось менее двух месяцев. Будем надеяться, что к первому января процесс перехода полностью завершится.
Продление срока действия ГОСТ Р 34.10-2001
Учитывая вышеуказанные обстоятельства, ФСБ продлила срок действия стандарта ГОСТ Р 34.10-2001 до 31 декабря 2021 года письмом от 07.09.2021 №149/7/6-363 после консультаций с исполнительными органами власти, представителями удостоверяющих центров, разработчиками СКЗИ, операторами ИС и порталов.
В связи с этим 12 сентября 2021 года Минкомсвязь опубликовала новое Уведомление об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2021 с подробным планом мероприятий по реализации перехода на новый стандарт, сроками перехода и рекомендациями производителям средств электронной подписи и удостоверяющих центров, аккредитованным удостоверяющим центрам, владельцам квалифицированных сертификатов и операторам информационных систем, в которых используется электронная подпись.
Основные положения уведомления Минкомсвязи, непосредственно касающиеся аккредитованных удостоверяющих центров:
- срок действия стандарта ГОСТ Р 34.10-2001 продлевается до 31 декабря 2021 года;
- до конца 2021 года производители средств электронной подписи должны продлить сроки действия сертификатов соответствия ФСБ России на средства электронной подписи, поддерживающие ГОСТ-2001, иначе электронные подписи, формируемые в 2021 году по ГОСТ-2001 с помощью средства ЭП со сроком действия сертификата ФСБ России до 31 декабря 2021 года, не будут считаться квалифицированными;
- после 31 декабря 2021 года аккредитованные удостоверяющие центры должны прекратить выпуск квалифицированных сертификатов по схеме ГОСТ-2001;
- владельцы квалифицированных сертификатов должны быть оповещены о том, что создание квалифицированной ЭП по схеме ГОСТ-2001 после 31 декабря 2021 года будет невозможным в связи с тем, что сертификаты соответствия ФСБ России на средства ЭП, поддерживающие ГОСТ-2001, прекратят свое действие 1 января 2020 года;
- при выдаче квалифицированных сертификатов для ключей ГОСТ-2001 после 30 сентября 2021 года аккредитованные удостоверяющие центры должны ограничивать период их действия датой не позднее 31 декабря 2021 года (например, ограничением периода действия сертификата или включением в состав сертификата расширения Private Key Usage Period со значением, не превосходящим 31 декабря 2021 года);
- мероприятия по встраиванию ГОСТ-2021 в информационные системы, использующие электронную подпись, и ввод их в эксплуатацию должны быть завершены до 31 декабря 2021 года;
- информация о готовности ИС к работе с электронной подписью по ГОСТ-2021 будет публиковаться на портале Федерального ситуационного центра электронного правительства.
Переход к использованию сертификатов по ГОСТ-2021: что важно знать абонентам
На основании письма ФСБ РФ от 07.09.2021 №149/7/6-363 и Уведомления Минкомсвязи об организации перехода на использование схемы электронной подписи по ГОСТ Р 34.10-2021, использование стандарта ГОСТ Р 34.10-2001 для формирования электронной подписи продлевается до 31 декабря 2021 года. Начиная с 1 января 2020 года формировать электронную подпись можно будет только в соответствии с ГОСТ Р 34.10-2021.
Абоненты аккредитованных удостоверяющих центров могут использовать сертификаты электронной подписи, сформированные в соответствии с ГОСТ-2001, до конца периода их действия, но не позднее чем до 31 декабря 2021 года. При этом на протяжении всего 2021 года для подписания документов квалифицированной электронной подписью допускается использование как старых действующих сертификатов, сформированных по ГОСТ-2001, так и новых, созданных по стандарту ГОСТ-2021.
*на правах рекламы.
Формат электронной подписи, обязательный для реализации всеми средствами электронной подписи / консультантплюс
Утвержден
приказом Министерства
цифрового развития, связи
и массовых коммуникаций
Российской Федерации
от 14.09.2020 N 472
1. Настоящий формат электронной подписи, обязательный для реализации всеми средствами электронной подписи (далее – Формат), устанавливает требования к структуре и содержанию информации в электронной подписи (далее – ЭП).
2. В соответствии с настоящим Форматом средства ЭП должны обеспечивать возможность создания нескольких ЭП в одном документе с сохранением данных, описывающих контекст, содержание, структуру документов, а также обеспечивающих управление документами в используемых информационных системах, – метаданных и сертификатов, на которых основаны эти ЭП, в электронном сообщении.
4. Формат определяется в соответствии с основами аутентификации в открытых системах <1>, синтаксисом криптографических сообщений, описанием дополнительных атрибутов криптографических сообщений, спецификацией абстрактной синтаксической нотации версии один <2>.
——————————–
<1> Основы аутентификации в открытых системах определены в ГОСТ Р ИСО/МЭК 9594-8-98
“Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации” (принят и введен в действие постановлением Госстандарта России от 19 мая 1998 г. N 215, опубликован в августе 1998 г. ИПК “Издательство стандартов”, ИУС 9-98).
5. В случае если участник электронного взаимодействия является владельцем действующего сертификата ключа проверки электронной подписи, Формат имеет вид следующей структуры:
SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos }5.1. Поле version (типа CMSVersion) определяет версию синтаксиса ЭП, которая зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах:
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }5.2. Поле digestAlgorithms (тип DigestAlgorithmIdentifiers) включает в себя идентификаторы используемых алгоритмов хэширования и связанные с ними параметры и определяется следующим образом:
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifierВ качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2021
“Информационная технология. Криптографическая защита информации. Функция хэширования” <3> (далее – ГОСТ Р 34.11-2021). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
——————————–
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3411-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643)rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-256(2) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3411-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643) rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-512(3) }5.3. Поле encapContentInfo (тип EncapsulatedContentInfo) содержит подписываемые данные (eContent) вместе с их типом (eContentType) и определяется следующим образом:
EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIERВ случае если поле eContent присутствует, то в нем содержится подписываемый электронный документ. Если поле eContent отсутствует, электронный документ хранится в отдельном файле.
5.4. В поле certificates (тип CertificateSet) может включаться дополнительная информация о сертификатах. В данное поле может быть включена информация о сертификатах подписывающих сторон.
CertificateSet ::= SET OF CertificateChoices CertificateChoices ::= CHOICE { certificate Certificate, extendedCertificate [0] IMPLICIT ExtendedCertificate, v1AttrCert [1] IMPLICIT AttributeCertificateV1, v2AttrCert [2] IMPLICIT AttributeCertificateV2, other [3] IMPLICIT OtherCertificateFormat }5.4.1. Основной синтаксис типа Certificate представлен следующим образом:
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }Поле signatureAlgorithm (тип SignatureAlgorithmIdentifier) определяет идентификатор использованного алгоритма ЭП и связанные с ним параметры:
SignatureAlgorithmIdentifier ::= AlgorithmIdentifierВ настоящем Формате в качестве идентификатора алгоритма ЭП указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.10-2021
“Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи” <1> (далее – ГОСТ Р 34.10-2021). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
——————————–
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643)rosstandart(7) tc26(1) algorithms(1) sign(1) gost3410-2021-256(1) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) sign(1)gost3410-2021-512(2) }5.4.2. Поле extendedCertificate (типа ExtendedCertificate) определяет расширенный сертификат PKCS #6. Расширенные сертификаты PKCS #6 поддерживаются для совместимости с предыдущими версиями и не применяются.
AttributeCertificateV2 ::= AttributeCertificate
5.4.5. Поле other (типа OtherCeitificateFormat) предназначено для обеспечения возможности поддержки иных форматов сертификатов без внесения изменений в синтаксис криптографических сообщений:
OtherCertificateFormat ::= SEQUENCE { otherCertFormat OBJECT IDENTIFIER, otherCert ANY DEFINED BY otherCertFormat }5.5. В поле crls (тип RevocationInfoChoices) может быть включена дополнительная информация об отзыве сертификатов:
RevocationInfoChoices ::= SET OF RevocationInfoChoice RevocationInfoChoice ::= CHOICE { crl CertificateList, other [1] IMPLICIT OtherRevocationInfoFormat } OtherRevocationInfoFormat ::= SEQUENCE { otherRevInfoFormat OBJECT IDENTIFIER, otherRevInfo ANY DEFINED BY otherRevInfoFormat }5.5.1. Поле crl (типа CertificateList) определяет список аннулированных сертификатов (CRL). Для вычисления подписи данные, которые должны быть подписаны, представляются в ASN.1-коде по DER-правилам:
CertificateList ::= SEQUENCE { tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- если представлено, то должно быть 2-й версии signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL -- если представлено, то должно быть 2-й версии } OPTIONAL, crlExtensions [0] EXPLICIT Extensions OPTIONAL -- если представлено, то должно быть 2-й версии }5.5.2. Поле other (типа OtherRevocationInfoFormat) определяет форматы информации об отзыве без дополнительного изменения синтаксиса криптографических сообщений.
5.6. В поле signerInfos (тип SignerInfos) содержится информация о каждой подписывающей стороне электронного документа.
SignerInfos ::= SET OF SignerInfo SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }5.6.1. Поле sid (тип SignerIdentifier) определяет сертификат подписывающей стороны, необходимый для проверки подлинности ЭП.
SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyldentifier [0] SubjectKeyIdentifier }В структуре ЭП должен использоваться вариант определения сертификата путем задания значения issuerAndSerialNumber.
5.6.2. Поле digestAlgorithm (тип DigestAlgorithmIdentifier) определяет идентификаторы использованного в данной ЭП алгоритма хэширования и связанные с ним параметры.
В качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2021
. Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один определяется следующим образом:
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3411-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643)rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-256(2) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3411-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643) rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-512(3) }5.6.3. Поле signedAttrs (тип SignedAttributes) должно определять дополнительную подписываемую информацию (далее – подписываемые атрибуты). Обязательные к включению подписываемые атрибуты определяются следующим образом:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY5.6.4. Поле signature (тип SignatureValue) содержит строку бит, полученную в результате процесса формирования ЭП:
SignatureValue ::= OCTET STRING5.6.5. Поле unsignedAttrs (тип UnsignedAttributes) определяет дополнительную неподписываемую информацию (далее – неподписываемые атрибуты):
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute6. Обязательными подписываемыми атрибутами являются:
6.1. Тип содержимого (Content-type). Должен быть добавлен в атрибут id-contentType с объектным идентификатором вида “1.2.840.113549.1.3”;
6.2. Строка бит, являющаяся выходным результатом функции, отображающей строки бит в строки бит фиксированной длины и удовлетворяющей следующим условиям:
по данному значению функции невозможно на период действия сертификата вычислить исходные данные, отображаемые в этом значении;
для заданных исходных данных невозможно на период действия сертификата вычислить другие исходные данные, отображаемые в этом значении;
невозможно на период действия сертификата вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение хэш-функции (далее – хэш-код) электронного сообщения (Message-digest).
Результат функции, отображающей строки бит в строки бит фиксированной длины и удовлетворяющей указанным условиям должен быть добавлен в атрибут id-messageDigest с объектным идентификатором вида “1.2.840.113549.1.4”;
6.3. Хэш-код от набора полей сертификата, позволяющих однозначно его идентифицировать, должен быть добавлен в атрибут id-aa-signingCertificateV2 с объектным идентификатором вида “1.2.840.113549.1.9”.
7. В случае если участник электронного взаимодействия не является владельцем действующего сертификата ключа проверки электронной подписи, Формат должен иметь вид следующей структуры:
CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, SignatureAlgorithm AlgorithmIdentifier {{Signature Algorithms}}, Signature BITSTRING}, гдеcertificationRequestInfo – подписываемая информация;
signatureAlgorithm – информация об алгоритме ЭП, который использовался при формировании ЭП структуры certificationRequestInfo;
signature – ЭП структуры certificationRequestInfo, сформированная с использованием алгоритма, указанного в SignatureAlgorithm.
7.1. Структура CertificationRequestInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} }, гдеversion – номер версии стандарта (в данном формате данное поле должно принимать значение 0)
subjectPKInfo – набор элементов, содержащих информацию о ключе проверки ЭП и имеющих структуру SubjectPublicKeyInfo;
attributes – набор атрибутов.
Структура SubjectPublicKeyInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
SubjectPublicKeyInfo (ALGORITHM: IOSet} ::= SEQUENCE { algorithm AlgorithmIdentifier {{IOSet} } subjectPublicKey BIT STRING }, гдеalgorithm – алгоритм и набор параметров алгоритма ЭП;
subjectPublicKey – ключ проверки ЭП.
Поле algorithm структуры SubjectPublicKeyInfo задается структурой AlgorithmIdentifier, описанной в ГОСТ Р ИСО/МЭК 9594-8
и содержащей следующие поля:
algorithm – идентификатор алгоритма ЭП;
parameters – параметры открытого ключа алгоритма ЭП.
Поле algorithm структуры AlgorithmIdentifier должно содержать следующий идентификатор алгоритма:
для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms (1) sign(1) gost3410-2021-256(1) }для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart (7) tc26(1) algorithms(1) sign(1) gost3410-2021-512(2) }Поле parameters структуры AlgorithmIdentifier имеет структуру GostR3410-2021-PublicKeyParameters, которая в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
GostR3410-2021-PublicKeyParameters ::= SEQUENCE { publicKeyParamSet OBJECT IDENTIFIER, digestParamSet OBJECT IDENTIFIER OPTIONAL }, гдеpublicKeyParamSet – идентификатор параметров ключа проверки ЭП, соответствующего алгоритму ЭП ГОСТ Р 34.10-2021
;
digestParamSet – идентификатор хэш-функции ГОСТ Р 34.11-2021
.
данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 512 бит;
данное поле должно присутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:
id-GostR3410-2001-CryptoPro-A-ParamSet id-GostR3410-2001-CryptoPro-B-ParamSet id-GostR3410-2001-CryptoPro-C-ParamSet id-GostR3410-2001-CryptoPro-XchA-ParamSet id-GostR3410-2001-CryptoPro-XchB-ParamSetпри этом он должен быть равен идентификатору алгоритма хэширования ГОСТ Р 34.11-2021
с длиной выхода 256 бит:
id-tc26-gost3411-12-256данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующем значении поля publicKeyParamSet:
id-tc26-gost-3410-2021-256-paramSetAданное поле должно отсутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:
id-tc26-gost-3410-2021-256-paramSetB id-tc26-gost-3410-2021-256-paramSetC id-tc26-gost-3410-2021-256-paramSetDПоле subjectPublicKey структуры SubjectPublicKeyInfo содержит ключ проверки ЭП, который задается парой координат (x, y), определенной ГОСТ Р 34.10-2021
, представляется следующим образом:
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2021
с длиной ключа 256 бит, имеет представление GostR3410-2021-256-PublicKey, которое задается байтовой строкой длины 64 байта, где первые 32 байта содержат представление координаты x в формате little-endian (младший бит записывается первым), а последние 32 байта содержат представление координаты y в формате little-endian;
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2021
с длиной ключа 512 бит, имеет представление GostR3410-2021-512-PublicKey, которое задается байтовой строкой длины 128 байт, где первые 64 байта содержат представление координаты x в формате little-endian, а последние 64 байта содержат представление координаты y в формате little-endian.
Ключи проверки ЭП GostR3410-2021-256-PublicKey и GostR3410-2021-512-PublicKey должны быть представлены в ASN.1-коде по DER-правилам в виде строки байт (OCTET STRING) в соответствии с ГОСТ Р ИСО/МЭК 8825-1
:
GostR3410-2021-256-PublicKey ::= OCTET STRING (64) GostR3410-2021-512-PublicKey ::= OCTET STRING (128)7.2. Поле algorithm структуры signatureAlgorithm содержит идентификатор алгоритма ЭП и связанных с ним параметров, который используется при формировании ЭП структуры CertificationRequestInfo с использованием ключа ЭП:
для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-2021-256(2) }для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-signwithdigest-gost3410-12-512 OBJECT IDENTIFIER ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-2021-512(3)}Поле parameters структуры signatureAlgorithm должно отсутствовать.
7.3. Поле signature структуры CertificationRequest содержит ЭП подписываемой информации.
Результатом работы алгоритма ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит является два числа r и s, определенные ГОСТ Р 34.10-2021
и имеющие длину 256 бит каждое.
При использовании алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит поле signature задается битовой строкой (BITSTRING) длины 512 бит; при этом первые 256 бит содержат число s в представлении big-endian (старший бит записывается первым), а вторые 256 бит содержат число r в представлении big-endian.
Результатом работы алгоритма ЭП ГОСТ Р 34.10-2021
с длиной ключа 512 бит является два числа r и s, определенные ГОСТ Р 34.10-2021
и имеющие длину 512 бит каждое.
При использовании алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит поле signature задается битовой строкой (BITSTRING) длины 1024 бит; при этом первые 512 бит содержат число s в представлении big-endian, а вторые 512 бит содержат число r в представлении big-endian.
§
Утвержден
приказом Министерства
цифрового развития, связи
и массовых коммуникаций
Российской Федерации
от 14.09.2020 N 472
1. Настоящий формат электронной подписи, обязательный для реализации всеми средствами электронной подписи (далее – Формат), устанавливает требования к структуре и содержанию информации в электронной подписи (далее – ЭП).
2. В соответствии с настоящим Форматом средства ЭП должны обеспечивать возможность создания нескольких ЭП в одном документе с сохранением данных, описывающих контекст, содержание, структуру документов, а также обеспечивающих управление документами в используемых информационных системах, – метаданных и сертификатов, на которых основаны эти ЭП, в электронном сообщении.
4. Формат определяется в соответствии с основами аутентификации в открытых системах <1>, синтаксисом криптографических сообщений, описанием дополнительных атрибутов криптографических сообщений, спецификацией абстрактной синтаксической нотации версии один <2>.
——————————–
<1> Основы аутентификации в открытых системах определены в ГОСТ Р ИСО/МЭК 9594-8-98
“Информационная технология. Взаимосвязь открытых систем. Справочник. Часть 8. Основы аутентификации” (принят и введен в действие постановлением Госстандарта России от 19 мая 1998 г. N 215, опубликован в августе 1998 г. ИПК “Издательство стандартов”, ИУС 9-98).
5. В случае если участник электронного взаимодействия является владельцем действующего сертификата ключа проверки электронной подписи, Формат имеет вид следующей структуры:
SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos }5.1. Поле version (типа CMSVersion) определяет версию синтаксиса ЭП, которая зависит от сертификатов, типа подписываемых данных и информации о подписывающих сторонах:
CMSVersion ::= INTEGER { v0(0), v1(1), v2(2), v3(3), v4(4), v5(5) }5.2. Поле digestAlgorithms (тип DigestAlgorithmIdentifiers) включает в себя идентификаторы используемых алгоритмов хэширования и связанные с ними параметры и определяется следующим образом:
DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier DigestAlgorithmIdentifier ::= AlgorithmIdentifierВ качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2021
“Информационная технология. Криптографическая защита информации. Функция хэширования” <3> (далее – ГОСТ Р 34.11-2021). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
——————————–
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3411-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643)rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-256(2) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3411-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643) rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-512(3) }5.3. Поле encapContentInfo (тип EncapsulatedContentInfo) содержит подписываемые данные (eContent) вместе с их типом (eContentType) и определяется следующим образом:
EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIERВ случае если поле eContent присутствует, то в нем содержится подписываемый электронный документ. Если поле eContent отсутствует, электронный документ хранится в отдельном файле.
5.4. В поле certificates (тип CertificateSet) может включаться дополнительная информация о сертификатах. В данное поле может быть включена информация о сертификатах подписывающих сторон.
CertificateSet ::= SET OF CertificateChoices CertificateChoices ::= CHOICE { certificate Certificate, extendedCertificate [0] IMPLICIT ExtendedCertificate, v1AttrCert [1] IMPLICIT AttributeCertificateV1, v2AttrCert [2] IMPLICIT AttributeCertificateV2, other [3] IMPLICIT OtherCertificateFormat }5.4.1. Основной синтаксис типа Certificate представлен следующим образом:
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }Поле signatureAlgorithm (тип SignatureAlgorithmIdentifier) определяет идентификатор использованного алгоритма ЭП и связанные с ним параметры:
SignatureAlgorithmIdentifier ::= AlgorithmIdentifierВ настоящем Формате в качестве идентификатора алгоритма ЭП указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.10-2021
“Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи” <1> (далее – ГОСТ Р 34.10-2021). Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
——————————–
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643)rosstandart(7) tc26(1) algorithms(1) sign(1) gost3410-2021-256(1) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) sign(1)gost3410-2021-512(2) }5.4.2. Поле extendedCertificate (типа ExtendedCertificate) определяет расширенный сертификат PKCS #6. Расширенные сертификаты PKCS #6 поддерживаются для совместимости с предыдущими версиями и не применяются.
AttributeCertificateV2 ::= AttributeCertificate
5.4.5. Поле other (типа OtherCeitificateFormat) предназначено для обеспечения возможности поддержки иных форматов сертификатов без внесения изменений в синтаксис криптографических сообщений:
OtherCertificateFormat ::= SEQUENCE { otherCertFormat OBJECT IDENTIFIER, otherCert ANY DEFINED BY otherCertFormat }5.5. В поле crls (тип RevocationInfoChoices) может быть включена дополнительная информация об отзыве сертификатов:
RevocationInfoChoices ::= SET OF RevocationInfoChoice RevocationInfoChoice ::= CHOICE { crl CertificateList, other [1] IMPLICIT OtherRevocationInfoFormat } OtherRevocationInfoFormat ::= SEQUENCE { otherRevInfoFormat OBJECT IDENTIFIER, otherRevInfo ANY DEFINED BY otherRevInfoFormat }5.5.1. Поле crl (типа CertificateList) определяет список аннулированных сертификатов (CRL). Для вычисления подписи данные, которые должны быть подписаны, представляются в ASN.1-коде по DER-правилам:
CertificateList ::= SEQUENCE { tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- если представлено, то должно быть 2-й версии signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL -- если представлено, то должно быть 2-й версии } OPTIONAL, crlExtensions [0] EXPLICIT Extensions OPTIONAL -- если представлено, то должно быть 2-й версии }5.5.2. Поле other (типа OtherRevocationInfoFormat) определяет форматы информации об отзыве без дополнительного изменения синтаксиса криптографических сообщений.
5.6. В поле signerInfos (тип SignerInfos) содержится информация о каждой подписывающей стороне электронного документа.
SignerInfos ::= SET OF SignerInfo SignerInfo ::= SEQUENCE { version CMSVersion, sid SignerIdentifier, digestAlgorithm DigestAlgorithmIdentifier, signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, signatureAlgorithm SignatureAlgorithmIdentifier, signature SignatureValue, unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }5.6.1. Поле sid (тип SignerIdentifier) определяет сертификат подписывающей стороны, необходимый для проверки подлинности ЭП.
SignerIdentifier ::= CHOICE { issuerAndSerialNumber IssuerAndSerialNumber, subjectKeyldentifier [0] SubjectKeyIdentifier }В структуре ЭП должен использоваться вариант определения сертификата путем задания значения issuerAndSerialNumber.
5.6.2. Поле digestAlgorithm (тип DigestAlgorithmIdentifier) определяет идентификаторы использованного в данной ЭП алгоритма хэширования и связанные с ним параметры.
В качестве идентификатора алгоритма хэширования указывается объектный идентификатор алгоритма, определенного ГОСТ Р 34.11-2021
. Указанный объектный идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один определяется следующим образом:
для алгоритма с длиной выхода 256 бит:
id-tc26-gost3411-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643)rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-256(2) }для алгоритма с длиной выхода 512 бит:
id-tc26-gost3411-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2)ru(643) rosstandart(7) tc26(1) algorithms(1) digest(2) gost3411-12-512(3) }5.6.3. Поле signedAttrs (тип SignedAttributes) должно определять дополнительную подписываемую информацию (далее – подписываемые атрибуты). Обязательные к включению подписываемые атрибуты определяются следующим образом:
SignedAttributes ::= SET SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue } AttributeValue ::= ANY5.6.4. Поле signature (тип SignatureValue) содержит строку бит, полученную в результате процесса формирования ЭП:
SignatureValue ::= OCTET STRING5.6.5. Поле unsignedAttrs (тип UnsignedAttributes) определяет дополнительную неподписываемую информацию (далее – неподписываемые атрибуты):
UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute6. Обязательными подписываемыми атрибутами являются:
6.1. Тип содержимого (Content-type). Должен быть добавлен в атрибут id-contentType с объектным идентификатором вида “1.2.840.113549.1.3”;
6.2. Строка бит, являющаяся выходным результатом функции, отображающей строки бит в строки бит фиксированной длины и удовлетворяющей следующим условиям:
по данному значению функции невозможно на период действия сертификата вычислить исходные данные, отображаемые в этом значении;
для заданных исходных данных невозможно на период действия сертификата вычислить другие исходные данные, отображаемые в этом значении;
невозможно на период действия сертификата вычислить какую-либо пару исходных данных, отображаемых в одно и то же значение хэш-функции (далее – хэш-код) электронного сообщения (Message-digest).
Результат функции, отображающей строки бит в строки бит фиксированной длины и удовлетворяющей указанным условиям должен быть добавлен в атрибут id-messageDigest с объектным идентификатором вида “1.2.840.113549.1.4”;
6.3. Хэш-код от набора полей сертификата, позволяющих однозначно его идентифицировать, должен быть добавлен в атрибут id-aa-signingCertificateV2 с объектным идентификатором вида “1.2.840.113549.1.9”.
7. В случае если участник электронного взаимодействия не является владельцем действующего сертификата ключа проверки электронной подписи, Формат должен иметь вид следующей структуры:
CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, SignatureAlgorithm AlgorithmIdentifier {{Signature Algorithms}}, Signature BITSTRING}, гдеcertificationRequestInfo – подписываемая информация;
signatureAlgorithm – информация об алгоритме ЭП, который использовался при формировании ЭП структуры certificationRequestInfo;
signature – ЭП структуры certificationRequestInfo, сформированная с использованием алгоритма, указанного в SignatureAlgorithm.
7.1. Структура CertificationRequestInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
CertificationRequestInfo ::= SEQUENCE { version INTEGER { v1(0) } (v1,...), subject Name, subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }}, attributes [0] Attributes{{ CRIAttributes }} }, гдеversion – номер версии стандарта (в данном формате данное поле должно принимать значение 0)
subjectPKInfo – набор элементов, содержащих информацию о ключе проверки ЭП и имеющих структуру SubjectPublicKeyInfo;
attributes – набор атрибутов.
Структура SubjectPublicKeyInfo в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
SubjectPublicKeyInfo (ALGORITHM: IOSet} ::= SEQUENCE { algorithm AlgorithmIdentifier {{IOSet} } subjectPublicKey BIT STRING }, гдеalgorithm – алгоритм и набор параметров алгоритма ЭП;
subjectPublicKey – ключ проверки ЭП.
Поле algorithm структуры SubjectPublicKeyInfo задается структурой AlgorithmIdentifier, описанной в ГОСТ Р ИСО/МЭК 9594-8
и содержащей следующие поля:
algorithm – идентификатор алгоритма ЭП;
parameters – параметры открытого ключа алгоритма ЭП.
Поле algorithm структуры AlgorithmIdentifier должно содержать следующий идентификатор алгоритма:
для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-gost3410-12-256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms (1) sign(1) gost3410-2021-256(1) }для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-gost3410-12-512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) ru(643) rosstandart (7) tc26(1) algorithms(1) sign(1) gost3410-2021-512(2) }Поле parameters структуры AlgorithmIdentifier имеет структуру GostR3410-2021-PublicKeyParameters, которая в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
GostR3410-2021-PublicKeyParameters ::= SEQUENCE { publicKeyParamSet OBJECT IDENTIFIER, digestParamSet OBJECT IDENTIFIER OPTIONAL }, гдеpublicKeyParamSet – идентификатор параметров ключа проверки ЭП, соответствующего алгоритму ЭП ГОСТ Р 34.10-2021
;
digestParamSet – идентификатор хэш-функции ГОСТ Р 34.11-2021
.
данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 512 бит;
данное поле должно присутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:
id-GostR3410-2001-CryptoPro-A-ParamSet id-GostR3410-2001-CryptoPro-B-ParamSet id-GostR3410-2001-CryptoPro-C-ParamSet id-GostR3410-2001-CryptoPro-XchA-ParamSet id-GostR3410-2001-CryptoPro-XchB-ParamSetпри этом он должен быть равен идентификатору алгоритма хэширования ГОСТ Р 34.11-2021
с длиной выхода 256 бит:
id-tc26-gost3411-12-256данное поле не следует использовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующем значении поля publicKeyParamSet:
id-tc26-gost-3410-2021-256-paramSetAданное поле должно отсутствовать, если используется алгоритм ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит при следующих значениях поля publicKeyParamSet:
id-tc26-gost-3410-2021-256-paramSetB id-tc26-gost-3410-2021-256-paramSetC id-tc26-gost-3410-2021-256-paramSetDПоле subjectPublicKey структуры SubjectPublicKeyInfo содержит ключ проверки ЭП, который задается парой координат (x, y), определенной ГОСТ Р 34.10-2021
, представляется следующим образом:
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2021
с длиной ключа 256 бит, имеет представление GostR3410-2021-256-PublicKey, которое задается байтовой строкой длины 64 байта, где первые 32 байта содержат представление координаты x в формате little-endian (младший бит записывается первым), а последние 32 байта содержат представление координаты y в формате little-endian;
ключ проверки ЭП, соответствующий алгоритму ГОСТ Р 34.10-2021
с длиной ключа 512 бит, имеет представление GostR3410-2021-512-PublicKey, которое задается байтовой строкой длины 128 байт, где первые 64 байта содержат представление координаты x в формате little-endian, а последние 64 байта содержат представление координаты y в формате little-endian.
Ключи проверки ЭП GostR3410-2021-256-PublicKey и GostR3410-2021-512-PublicKey должны быть представлены в ASN.1-коде по DER-правилам в виде строки байт (OCTET STRING) в соответствии с ГОСТ Р ИСО/МЭК 8825-1
:
GostR3410-2021-256-PublicKey ::= OCTET STRING (64) GostR3410-2021-512-PublicKey ::= OCTET STRING (128)7.2. Поле algorithm структуры signatureAlgorithm содержит идентификатор алгоритма ЭП и связанных с ним параметров, который используется при формировании ЭП структуры CertificationRequestInfo с использованием ключа ЭП:
для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-signwithdigest-gost3410-12-256 OBJECT IDENTIFIER ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-2021-256(2) }для алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит идентификатор в соответствии со спецификацией абстрактной синтаксической нотации версии один представляется следующим образом:
id-tc26-signwithdigest-gost3410-12-512 OBJECT IDENTIFIER ::= {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) algorithms(1) signwithdigest(3) gost3410-2021-512(3)}Поле parameters структуры signatureAlgorithm должно отсутствовать.
7.3. Поле signature структуры CertificationRequest содержит ЭП подписываемой информации.
Результатом работы алгоритма ЭП ГОСТ Р 34.10-2021
с длиной ключа 256 бит является два числа r и s, определенные ГОСТ Р 34.10-2021
и имеющие длину 256 бит каждое.
При использовании алгоритма ГОСТ Р 34.10-2021
с длиной ключа 256 бит поле signature задается битовой строкой (BITSTRING) длины 512 бит; при этом первые 256 бит содержат число s в представлении big-endian (старший бит записывается первым), а вторые 256 бит содержат число r в представлении big-endian.
Результатом работы алгоритма ЭП ГОСТ Р 34.10-2021
с длиной ключа 512 бит является два числа r и s, определенные ГОСТ Р 34.10-2021
и имеющие длину 512 бит каждое.
При использовании алгоритма ГОСТ Р 34.10-2021
с длиной ключа 512 бит поле signature задается битовой строкой (BITSTRING) длины 1024 бит; при этом первые 512 бит содержат число s в представлении big-endian, а вторые 512 бит содержат число r в представлении big-endian.
