Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
executable file 552 lines (427 sloc) 38.3 KB

СТБ 34.101.17-2012

Информационные технологии и безопасность

СИНТАКСИС ЗАПРОСА НА ПОЛУЧЕНИЕ СЕРТИФИКАТА

Інфармацыйныя тэхналогіі і бяспека

СІНТАКСІС ЗАПЫТУ НА АТРЫМАННЕ СЕРТЫФІКАТА

Information technology and security

Certification request syntax


Содержание

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

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

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

4 Общие положения

5 Синтаксис запроса на получение сертификата

Приложение А (обязательное) Модуль АСН.1

Приложение Б (обязательное) Отличительные правила кодирования

Приложение В (рекомендуемое) Запрос на получение сертификата открытого ключа электронной цифровой подписи согласно СТБ 1176.2

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

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

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

Настоящий стандарт применяется при разработке, испытаниях и эксплуатации систем управления открытыми ключами.

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

В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):

СТБ 1176.1 99 Информационная технология. Защита информации. Функция хэширования

СТБ 1176.2-99 Информационная технология. Защита информации. Процедуры выработки и проверки электронной цифровой подписи

СТБ 34.101.19-2012 Информационная технологии и безопасность. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей

СТБ 34.101.23-2012 Информационная технологии и безопасность. Синтаксис криптографических сообщений

СТБ 34.101.31-2011 Информационные технологии. Защита информации. Криптографические алгоритмы шифрования и контроля целостности

СТБ 34.101.47-2012 Информационные технологии и безопасность. Криптографические алгоритмы генерации псевдослучайных чисел

ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)

Примечание – При пользовании настоящим стандартом целесообразно проверить действие ТНПА по каталогу, составленному по состоянию на 1 января текущего года, и по соответствующим информационным указателям, опубликованным в текущем году. Если ссылочные ТНПА заменены (изменены), то при пользовании настоящим стандартом следует руководствоваться замененными (измененными) ТНПА. Если ссылочные ТНПА отменены без замены, то положение, в котором дана ссылка на них, применяется в части, не затрагивающей эту ссылку.

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

В настоящем стандарте применяются термины, установленные в СТБ 34.101.19, ГОСТ 34.973 и ГОСТ 34.974.

Для определения типов абстрактно-синтаксической нотации версии 1 (АСН.1) применяются обозначения, установленные в ГОСТ 34.973.

4 Общие положения

В соответствии с СТБ 34.101.19 открытые ключи пользователей распространяются в виде сертификатов. Для получения сертификата пользователь (владелец личного ключа) обращается в удостоверяющий центр (УЦ) с запросом. Настоящий стандарт определяет синтаксис (формат) такого запроса, правила формирования и обработки запроса. Синтаксис и правила соответствуют [1].

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

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

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

  1. Формируется значение типа CertificationRequestInfo, состоящее из уникального имени пользователя, открытого ключа пользователя и необязательного набора атрибутов (см. 5.1).

  2. Значение типа CertificationRequestInfo подписывается на личном ключе пользователя (см. 5.2).

  3. Формируется значение типа CertificationRequest, состоящее из значения типа CertificationRequestInfo, идентификатора алгоритма ЭЦП и ЭЦП, выработанной на личном ключе пользователя (см. 5.2).

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

После получения запроса УЦ идентифицирует пользователя, запрашивающего сертификат, проверяет его ЭЦП и, если запрос действителен, создает сертификат, соответствующий СТБ 34.101.19. Сертификат создается на основании уникального имени и открытого ключа пользователя, имени УЦ и выбранных УЦ серийного номера, срока действия и алгоритма ЭЦП. Если запрос на получение сертификата включает какие-либо атрибуты, то для создания расширений сертификата, соответствующих СТБ 34.101.19, УЦ может использовать значения данных атрибутов, как, впрочем, и другую известную ему информацию.

Способ, с помощью которого УЦ возвращает сертификат пользователю, не рассматривается в настоящем стандарте. Одним из возможных способов является возвращение сертификата в виде подписанного криптографического сообщения, соответствующего СТБ 34.101.23. Возвращаемое сообщение может включать маршрут сертификации от выпущенного сертификата к УЦ. Сообщение может включать другие сертификаты, например кросс-сертификаты, которые УЦ счел необходимым включить в возвращаемое сообщение, а также списки отозванных сертификатов. Другим возможным способом является включение УЦ сертификата пользователя в общедоступную базу данных сертификатов.

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

Открытый ключ пользователя, который включается в запрос, определяет (прямо или косвенно) долговременные параметры алгоритма, которому он соответствует. Если долговременные параметры отличаются от стандартных или от установленных УЦ, то проверка ЭЦП запроса должна включать проверку корректности параметров. Например, если параметры должны быть сгенерированы с помощью определенных алгоритмов, то УЦ должен проверить, что это действительно так.

Синтаксис запроса на получение сертификата задается типами АСН.1. Модуль АСН.1 запроса – в соответствии с приложением А.

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

В ГОСТ 34.974 определены базовые правила кодирования. В приложении Б установлены отличительные правила кодирования, которые уточняют базовые правила и обеспечивают однозначность кодового представления. Отличительные правила должны использоваться при кодировании значений типа CertificationRequestInfo при формировании ЭЦП запроса (см. 5.2).

5 Синтаксис запроса на получение сертификата

5.1 Тип CertificationRequestInfo

Информационная часть запроса на получение сертификата должна иметь тип CertificationRequestInfo АСН.1:

CertificationRequestInfo ::= SEQUENCE {
  version INTEGER,
  subject Name,
  subjectPKInfo SubjectPublicKeyInfo,
  attributes [0] Attributes
}
SubjectPublicKeyInfo ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  subjectPublicKey BIT STRING
}
Attributes ::= SET OF Attribute

Attribute ::= SEQUENCE {
  type OBJECT IDENTIFIER,
  values ANY DEFINED BY type
}

Компоненты типа CertificationRequestInfo имеют следующее значение:

  • version – номер версии для совместимости с будущими версиями настоящего стандарта. Для данной версии стандарта он должен быть равен 0;
  • subject – уникальное имя пользователя, который запрашивает сертификат. Тип Name данного компонента определен в СТБ 34.101.19;
  • subjectPKInfo – информация об открытом ключе, для которого запрашивается сертификат. Данная информация определяет алгоритм, для которого предназначен открытый ключ пользователя, параметры алгоритма и представление открытого ключа пользователя;
  • attributes – набор атрибутов, содержащих дополнительную информацию о сертификате или его владельце. Например, в запрос может быть включен атрибут «пароль отзыва», определяющий пароль, при помощи которого владелец сертификата может отозвать сертификат. Другим примером атрибутов может служить информация для включения в расширения сертификата, определенные в СТБ 34.101.19.

Компоненты типа SubjectPublicKeyInfo имеют следующее значение:

  • algorithm – идентификатор алгоритма и связанные с данным алгоритмом параметры. Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19;
  • subjectPublicKey – открытый ключ пользователя.

Компоненты типа Attribute имеют следующее значение:

  • type – тип атрибута;
  • values – значение атрибута, тип которого определяется компонентом type.

5.2 Тип CertificationRequest

Запрос на получение сертификата должен иметь тип CertificationRequest АСН.1:

CertificationRequest ::= SEQUENCE {
  certificationRequestInfo CertificationRequestInfo,
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING
}

Компоненты типа CertificationRequest имеют следующее значение:

  • certificateRequestInfo – информационная часть запроса на получение сертификата, которая подписывается;
  • signatureAlgorithm – информация об алгоритме ЭЦП (включая его параметры, при необходимости), в соответствии с которым подписывается информационная часть запроса на получение сертификата. Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19;
  • signature – ЭЦП информационной части запроса, выработанная на личном ключе пользователя, запрашивающего сертификат.

Процесс подписи информационной части запроса состоит из двух шагов:

  1. Значение компонента CertificationRequestInfo кодируется при помощи отличительных правил кодирования (см. приложение Б).

  2. Кодовое представление, полученное на первом шаге, подписывается в соответствии с заданным алгоритмом на личном ключе пользователя, запрашивающего сертификат. Результатом является ЭЦП, представленная значением типа BIT STRING.

Примечание – Способы формирования компонента signature для запроса на получение сертификата открытого ключа СТБ 1176.2 – в соответствии с приложением В.

Приложение А (обязательное)

Модуль АСН.1

В настоящем приложении приведен модуль АСН.1 запроса на получение сертификата.

PKCS-10 {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-10(10)   modules(1) pkcs-10(1)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
AlgorithmIdentifier, Name
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)internet(1)   security(5) mechanisms(5) pkix(7) id-mod(0)id-pkix1-explicit(18)};

CertificationRequestInfo ::= SEQUENCE {
  version INTEGER,
  subject Name,
  subjectPKInfo SubjectPublicKeyInfo,
  attributes [0]Attributes
}

SubjectPublicKeyInfo ::= SEQUENCE {
  algorithm AlgorithmIdentifier,
  subjectPublicKey BIT STRING
}

Attributes ::= SET OF Attribute

Attribute ::= SEQUENCE {
  type OBJECT IDENTIFIER,
  values   ANY DEFINED BY type
}

CertificationRequest ::= SEQUENCE {
  certificationRequestInfo CertificationRequestInfo,
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING
}
END

Приложение Б (обязательное)

Отличительные правила кодирования

Кодирование значений типов АСН.1 по отличительным правилам является базовым, определенным в ГОСТ 34.974, с ограничениями, установленными в настоящем приложении.

Формат длины. При кодировании длины должен использоваться явный формат, представленный минимальным числом октетов [ср. с ГОСТ 34.974, пункт 6.3.2, перечисление б)].

Формат кодирования строк. Для типов «строка битов» (BIT STRING), «строка октетов» (OCTET STRING) и «строка знаков» (NumericString, PrintableString и др.) не должны использоваться составные формы [ср. с ГОСТ 34.974, пункт 21.5.4].

Компоненты типа «множество». При кодировании значения типа «множество» (SET) значения его компонентов должны располагаться в каноническом порядке. Канонический порядок определяется самым внешним тегом типа компонента и задается следующими правилами:

  • сначала идут теги универсального класса, затем – теги прикладного класса, затем – теги контекстнозависимого класса и, наконец, теги пользовательского класса (см. ГОСТ 34.973, подраздел 5.8);
  • внутри класса элементы упорядочиваются по возрастанию номеров их тегов.

Примечание – Когда компонент типа «множество» является нетегированным выборочным типом, порядок расположения компонента зависит от тега кодируемого выборочного компонента.

Приложение В (рекомендуемое)

Запрос на получение сертификата открытого ключа электронной цифровой подписи согласно СТБ 1176.2

В.1 Способы формирования компонента signature

В соответствии с СТБ 34.101.19 (приложение Г) сертификат открытого ключа СТБ 1176.2 может содержать либо исключительно открытый ключ СТБ 1176.2, либо совместно открытый ключ СТБ 1176.2 и открытый ключ протоколов формирования общего ключа (ПФОК), определенных в [2]. Соответственно, запрос на получение сертификата открытого ключа СТБ 1176.2 должен обязательно содержать открытый ключ СТБ 1176.2 и может дополнительно содержать открытый ключ ПФОК.

При получении запроса УЦ должен проверить, что пользователь владеет личным ключом, соответствующим открытому ключу из запроса (в [2] личный ключ называется секретным ключом идентификации). Способ доказательства владения личным ключом зависит от открытого ключа, для которого запрашивается сертификат, и определяет правила формирования компонента signature запроса.

Компонент signature запроса на получение сертификата открытого ключа СТБ 1176.2 должен определяться как кодовое представление значения типа BDSBDHSignature АСН.1:

BDSBDHSignature ::= SEQUENCE {
  bdsSignature BIT STRING,
  bdhSignature BDHSignature OPTIONAL
}

При кодировании должны использоваться отличительные правила (см. приложение Б).

Компонент bdsSignature типа BDSBDHSignature представляет подпись информационной части запроса, выработанную с помощью алгоритма выработки ЭЦП согласно СТБ 1176.2. При выработке ЭЦП должен использоваться личный ключ, соответствующий открытому ключу ЭЦП, для которого запрашивается сертификат. Проверка владения личным ключом состоит в проверке полученной ЭЦП.

Для формирования значения bdsSignature подпись СТБ 1176.2 (неотрицательное целое число) представляется двоичной последовательностью, первым элементом которой является старший (ненулевой) бит подписи, последним элементом – младший бит. В начало последовательности дописываются нулевые биты (не более 7) до тех пор, пока длина последовательности не станет кратной 8.

Компонент dsSignature типа BDSBDHSignature должен присутствовать только в запросах на получение сертификатов, содержащих совместно открытый ключ СТБ 1176.2 и открытый ключ ПФОК. Данный компонент имеет тип BDHSignature АСН.1:

BDHSignature ::= CHOICE {
  macSignature MACSignature,
  egSignature ElGamalSignature
}
MACSignature ::= SEQUENCE {
  macAlgorithm AlgorithmIdentifier,
  mac BIT STRING
}
ElGamalSignature ::= SEQUENCE {
  w INTEGER,
  s INTEGER
}

Компонент macSignature типа BDHSignature используется при доказательстве владения личным ключом ПФОК с помощью имитовставки, вычисленной на основании общего ключа, вырабатываемого между пользователем и УЦ согласно протоколу формирования общего секретного ключа без аутентификации сторон [2] (пункт 4.1.4). При выработке общего ключа пользователь должен использовать личный ключ, соответствующий открытому ключу, для которого запрашивается сертификат. Проверка владения личным ключом состоит в проверке полученной имитовставки.

Примечание 1 – При формировании общего ключа в качестве чисел uA и uB должны использоваться личные ключи пользователя и УЦ соответственно, а в качестве чисел vA и vB – открытые ключи пользователя и УЦ соответственно.

Примечание 2 – Для выработки общего ключа пользователь и УЦ должны использовать общие параметры ПФОК.

Компоненты типа MACSignature имеют следующее значение:

  • macAlgorithm – информация об алгоритме выработки имитовставки (включая его долговременные параметры, при необходимости), в соответствии с которым вырабатывается имитовставка от информационной части запроса на получение сертификата. Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19;
  • mac – имитовставка, выработанная от информационной части запроса на общем для пользователя и УЦ ключе.

Примечание – Для выработки имитовставки рекомендуется использовать алгоритм, определенный в СТБ 34.101.31, либо алгоритм HMAC, определенный в СТБ 34.101.47.

Компонент egSignature типа BDHSignature используется при доказательстве владения личным ключом ПФОК с помощью алгоритмов, определенных в В.2. При создании доказательства пользователь должен применять алгоритм согласно В.2.2 и использовать личный ключ ПФОК, соответствующий открытому ключу. Для проверки владения личным ключом УЦ должен применять алгоритм согласно В.2.3 и использовать открытый ключ ПФОК пользователя из запроса.

Компоненты типа ElGamalSignature имеют следующее значение:

  • w – число w, вычисленное по алгоритму согласно В.2.2;
  • s – число s, вычисленное по алгоритму согласно В.2.2.

В.2 Алгоритмы доказательства владения личным ключом протоколов формирования общего ключа

В.2.1 Назначение

В настоящем разделе определяются алгоритм создания доказательства владения личным ключом ПФОК (см. В.2.2) и алгоритм проверки доказательства владения личным ключом ПФОК (см. В.2.3).

В алгоритмах используются параметры p ∈ {2l – 1 + 1, …, 2l − 1} и g ∈ {1, 2, …, p − 1}, определенные в [2], где l и r – параметры безопасности, которые определяют криптографическую стойкость протоколов формирования общего ключа. Параметр p является простым числом и имеет вид p = 2_q_ + 1, где q – также простое число.

При описании алгоритмов используются обозначения согласно [2]. Дополнительно вводится символ R = 2l + 2.

В.2.2 Алгоритм создания доказательства владения

личным ключом протоколов формирования общего ключа

В.2.2.1 Входные и выходные данные

Входными данными алгоритма являются:

  • информационная часть запроса на получение сертификата, в том числе параметры p и g;
  • личный ключ x ∈ {1, 2, …, 2r − 1}.

Выходными данными являются числа w ∈ {1, 2, …, p − 1} и s ∈ {1, 2, …, p − 2}.

В.2.2.2 Переменные

Используются переменные k, h со значениями из множества {1, 2, …, p − 1}. Переменная k должна быть уничтожена сразу после использования.

В.2.2.3 Алгоритм создания доказательства

Для создания доказательства выполняются следующие шаги:

  1. Выработать с помощью генератора случайных чисел или c помощью криптографического генератора псевдослучайных чисел число k ∈ {1, 2, …, q − 1}.
  2. Установить k = (q + 2_k_) mod (p − 1).
  3. Вычислить w = g(k).
  4. Если w = q, то возвратиться к шагу 1.
  5. Выполнить хэширование кодового представления информационной части запроса с помощью алгоритма СТБ 1176.1 и сохранить хэш-значение в переменной h.
  6. Установить h = q + 2(h + 1).
  7. Вычислить s = kq − 2(hxw) mod (p − 1).
  8. Возвратить (w, s).

В.2.3 Алгоритм проверки доказательства владения личным ключом протоколов формирования общего ключа

В.2.3.1 Входные и выходные данные

Входными данными алгоритма являются:

  • информационная часть запроса на получение сертификата, в том числе параметры p, g и открытый ключ y ∈ {1, 2, …, p − 1};
  • целые числа w и s.

Выходными данными является ответ «ДА» или «НЕТ». Ответ «ДА» означает успешное завершение проверки доказательства владения личным ключом ПФОК, ответ «НЕТ» – неуспешное.

В.2.3.2 Переменные

Используется переменная h со значениями из множества {1, 2, …, p − 1}.

В.2.3.3 Алгоритм проверки доказательства

Для проверки доказательства выполняются следующие шаги:

  1. Если параметры p и g заданы в достоверном источнике (например, в некотором действительном сертификате), перейти к шагу 4.

  2. Проверить, что параметр p сгенерирован в соответствии с алгоритмом из [2] (пункт 5.2.4). Если это не так, возвратить «НЕТ».

  3. Проверить, что 1 ≤ gp − 1, (g + R) mod p ≠ 0 и (g(q) + R) mod p = 0. Если это не так, возвратить «НЕТ».

  4. Если wp или w ≤ 0 или w = q, возвратить «НЕТ».

  5. Если sp − 1 или s < 0, возвратить «НЕТ».

  6. Выполнить хэширование кодового представления информационной части запроса с помощью алгоритма СТБ 1176.1 и сохранить хэш-значение в переменной h.

  7. Установить h = q + 2(h + 1).

  8. Установить h = hq – 2 mod (p − 1).

  9. Если gy(wh mod (p − 1))w(sh mod (p − 1)), возвратить «НЕТ».

  10. Возвратить «ДА».

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

[1] PKCS #10: Certification request syntax standard. Version 1.7. RSA Laboratories, 2000 (Стандарт синтаксиса запроса на получение сертификата)

[2] Проект руководящего документа Республики Беларусь «Банковские технологии. Протоколы формирования общего ключа» Мн.: Национальный банк Республики Беларусь, 1997

You can’t perform that action at this time.