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

РЕКОМЕНДАЦИИ Р 50.1.112-

ПО СТАНДАРТИЗАЦИИ 2016

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

Транспортный ключевой контейнер

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

Москва

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

2016

P 50.1.112—2016

Предисловие

1    РАЗРАБОТАНЫ подкомитетом 2 Технического комитета по стандартизации ТК 26 «Криптографическая защита информации»

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

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

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

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

©Стандартинформ. 2016

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

P 50.1.112—2016

SET {

SEQUENCE {

OBJECT IDENTIFIER '2543'

UTF8String ’CA certificate (PKCS#12 example)'

}

}

}

SEQUENCE {

UTCTime *150327072300Z'

UTCTime * 2003270723002'

}

SEQUENCE {

SET {

SEQUENCE {

OBJECT IDENTIFIER '2546'

PrintableString 'RU'

}

}

SET {

SEQUENCE {

OBJECT IDENTIFIER '2547'

UTF8String 'Москва'

)

}

SET {

SEQUENCE {

OBJECT IDENTIFIER '2 5 4 10'

UTF8Stri ng 'TK26'

}

)

SET {

SEQUENCE {

OBJECT IDENTIFIER '2543'

UTF8String ’CA certificate (PKCS#12 example)'

}

}

}

SEQUENCE {

SEQUENCE {

OBJECT IDENTIFIER '1 2 643 7 1 1 1 1'

SEQUENCE {

OBJECT IDENTIFIER '1 2 643 2 2 35 1'

OBJECT IDENTIFIER '1 2 643 7 1 1 2 2'

}

>

BIT STRING 0 unused bits, encapsulates {

OCTET STRING

1C

58

OB

BD

B3

EC

F4

OE

2D

90

B3

58

49

62

5F

2E

E4

34

F9

2C

E7

BD

2F

10

D3

36

89

4B

16

IB

00

B4

A6

4D

FB

9A

41

85

05

49

9F

92

5D

D5

90

96

A6

8E

50

B3

AF

FB

FF

01

BE

3D

73

FI

9C

OA

A2

5A

A7

67

}

)

[3] {

SEQUENCE {

SEQUENCE {

OBJECT IDENTIFIER '2 5 29 15' BOOLEAN TRUE

OCTET STRING, encapsulates { BIT STRING 1 unused bits *1100011'В

}

}

P 50.1.112—2016

421 30 15 SEQUENCE { 423 06 3 OBJECT IDENTIFIER *2 5 29 19* 428 01 1 BOOLEAN TRUE 431 04 5 OCTET STRING, encapsulates { 433 30 3 SEQUENCE { 435 01 1 BOOLEAN TRUE } } > SEQUENCE { 438 30 29 440 06 3 OBJECT IDENTIFIER ’2 5 29 14* 445 04 22 OCTET STRING, encapsulates { 447 04 20 OCTET STRING 26 9D CE D7 87 9C A4 6F 9B 7F 04 CC OE 93 10 38 76 B7 C4 9A } 469 30 153 > SEQUENCE { 472 06 3 OBJECT IDENTIFIER '2 5 29 35' 477 04 145 OCTET STRING, encapsulates { 480 30 142 SEQUENCE { 483 80 20 [0] 26 9D CE D7 87 9C A4 6F 9B 7F 04 76 B7 C4 9A CC OE 93 10 38 505 A1 100 [1] { 507 A4 98 [4] { 509 30 96 SEQUENCE { 511 31 11 SET { 513 30 9 SEQUENCE { 515 06 3 OBJECT IDENTIFIER *254 6' 520 13 2 PrintableString 'RU' > 524 31 21 > SET { 526 30 19 SEQUENCE { 528 06 3 OBJECT IDENTIFIER ’254 7' 533 ОС 12 UTF8String 'Москва' > 547 31 15 > SET { 549 30 13 SEQUENCE { 551 06 3 OBJECT IDENTIFIER '254 10' 556 ОС 6 UTF8Stri ng 'TK26’ } 564 31 41 > SET { 566 30 39 SEQUENCE { 568 06 3 OBJECT IDENTIFIER '254 3’ 573 ОС 32: UTF8String 'CA certificate > > } } > [2] (PKCS#12 example)' 607 82 16

01 DO 68 5E F2 FC 4D 20 00 00 00 OB 27 09 00 01

>

}

}

>

}

}

8

SEQUENCE {

OBJECT IDENTIFIER '1 2 643 7 1 1 3 2*

NULL } BIT STRING 0 unused bits

FB E3 9A CC CA 44 A4 AF A 7 4C BC AD 24 A3 98 9A BE 91 A1 El AD 7D 28 D7 7D 48 4B 7E CC 7C BB 52 6A CE BF 70 10 C2 B9 E6 93 OD 8C C6 BC BA 93 D1 89 29 95 F2 86 7E 6B OE 22 86 AD CB B6 5F 21 7D

>

A1.2 Тестовый сертификат

Тестовый сертификат присутствует во всех приведенных контрольных примерах в качестве сертификата, подлежащего упаковке в контейнер Значение тестового сертификата, закодированное с соответствии с алгоритмом BASE64

MIIDAjCCAq2gAwIBAgIQAdBoXzEflsAAAAALJwkAATAMBggqhQMHAQEDAgUAMGAx CzAJBgNVBAYTAlJVMRUwEwYDVQQHDAzQnNC+OYHQutCyOLAxDzANBgNVBAoMBtCi 0JoyNjEpMCcGAlUEAw\vgQ0EgY2VydGlmaWNhdGUgKFBLQlMjMTIgZXhhbXBsZSkw HhcNMTUv\MzI3MDcyNTAwWhcNMjAwMzI3MDcyMzAwWjBkMQs*CQYDVQQGEwJSVTEV MBMGAlUEBwwfK) J zQv tGBOL rQstCv4«4Q8wDQYDVQQKDAbQotCaM j YxLTArBgNVBAMM J FR1 c3QgY2VydGl maWNhdGUgMSAoUEtDUyMxMi B1 eGFtcGxl KTBmMB8GCCqFAwcB AQEBMBMGByqFAwICIw€GCCqFAwcBAQICA0MABEDXHPKaSm+vZlglPxZM5fcO33r/ 6Eaxc3KlRCmRYHkiYkzi2DOCwLhEhTBXkfjUyEbS4FEXB5PM3oC*fiOG+FMKVgQkA Mjo\OTAv\WDGjggEpMIIBJTArBgNVHRAEJDAigA8yMDElMDMyNzA3MjUv\MFqBDzIw MTYwWzI3MDcyNTAwWjAOBgNVHQ8BAf8EBAMCBPAwHQYDVROOBBYEFCFY6xFDrzJg 3ZS2D+jAehZyqxVtMBOGAlUdJQQhWBQGCCsGAQUFBwMCBggrBgEFBQcDBDAMBgNV HRMBAf8EAjAAMIGZBgNVHSMEgZE*gY6AFCadzteHnKRvm38EzA6TEDh2t8SaoWSk Y j BgMQswCQYDVQQGEwJ SVTEVMBMGA1UE BwmMO J zQv tGBOL rQs tCvsMQ8v\OQYDVQQK DAbQotCaMjYxKTAnBgNVBAMMIENBIGNlcnRpZmljYXRlIChQS0NTIzEyIGV4YWlw bGUpghAB0Ghe8vxNIAAAAAsnCQABMAv/JCCqFAwcBAQMCBQADQQD2i rRW+TySSAjC SnTHQnl4q2J rgwlOLAoCbuOCcJkjHc73wFOFpNfdlCESjZEv2lMI+vrAUyF54n5h 0YxF5e+y

}

}

SET {

SEQUENCE {

OBJECT IDENTIFIER '2543'

UTF8String ’CA certificate (PKCS#12 example)'

>

}

}

SEQUENCE {

UTCTime '150327072500Z’

UTCTime '200327072300Z'

>

SEQUENCE {

SET {

SEQUENCE {

OBJECT IDENTIFIER '2546'

PrintableString 'RU'

}

}

SET {

SEQUENCE {

OBJECT IDENTIFIER '2547'

UTF8String ’Москва’

}

}

SET {

SEQUENCE {

OBJECT IDENTIFIER ’2 5 4 10'

UTF8String ’TK26’

}

}

SET {

SEQUENCE {

OBJECT IDENTIFIER ’2543’

UTF8String 'Test certificate 1 (PKCS#12 example)'

}

>

>

SEQUENCE {

SEQUENCE {

OBJECT IDENTIFIER '1 2 643 7 1 1 1 1'

SEQUENCE {

OBJECT IDENTIFIER '1 2 643 2 2 35 1'

OBJECT IDENTIFIER '1 2 643 7 1 1 2 2'

>

}

BIT STRING 0 unused bits, encapsulates {

OCTET STRING

D7	1C	F2	9А	4А	6F	AF	67	58	25	3F	16	4С	Е5	F7	ОЕ
DF	7А	FF	Е8	46	В1	73	72	В5	44	29	91	60	79	22	62
4С	Е2	D8	3D	02	СО	В8	44	85	30	57	91	F8	D4	С8	46
D2	ЕО	51	17	07	93	СС	DE	80	ВО	07	41	BE	14	С2	95

}

}

[1] '.27090001'

[3] {

SEQUENCE {

SEQUENCE {

OBJECT IDENTIFIER '2 5 29 16' OCTET STRING, encapsulates { SEQUENCE {

Р 50.1.112—2016

[0]    '20150327072500Z’

[1]    ’20160327072500Z’

}

}

}

SEQUENCE {

OBJECT IDENTIFIER ’2 5 29 15’

BOOLEAN TRUE

OCTET STRING, encapsulates {

BIT STRING 4 unused bits ’llll’B

>

>

SEQUENCE {

OBJECT IDENTIFIER *2 5 29 14’

OCTET STRING, encapsulates {

OCTET STRING

21 58 EB 11 43 AF 32 60 DO 94 B6 OF E8 СО 7A 16 72 AB 15 6D

}

}

SEQUENCE {

OBJECT IDENTIFIER ’2 5 29 37'

OCTET STRING, encapsulates {

SEQUENCE {

OBJECT IDENTIFIER ’136155732'

OBJECT IDENTIFIER ’136155734'

>

}

}

SEQUENCE {

OBJECT IDENTIFIER ’2 5 29 19’

BOOLEAN TRUE

OCTET STRING, encapsulates {

SEQUENCE {}

}

}

SEQUENCE {

OBJECT IDENTIFIER ’2 5 29 35’

OCTET STRING, encapsulates {

SEQUENCE {

to]

26 9D CE D7 87 9C A4 6F 9B 7F 04 CC OE 93 10 38 76 B7 C4 9A [1] {

[4] {

SEQUENCE {

SET {

SEQUENCE {

OBJECT IDENTIFIER ’2 546' PrintableString 'RU'

>

}

SET {

SEQUENCE {

OBJECT IDENTIFIER ’2547'

UTF8String 'Москва'

>

}

SET {

SEQUENCE {

OBJECT IDENTIFIER ’2 5 4 10’

11

P 50.1.112—2016

Содержание

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

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

3    Обозначения........................................................................................................................................... 1

3.1    Обозначения ..................................................................................................................................... 1

4    Представление ключей ГОСТ Р 34.10 и ГОСТ 28147-89..................................................................... 2

4.1    Портфель ключевой информации КеуВад...................................................................................... 2

4.2    Данные, защищаемые в транспортном ключевом контейнере...................................................... 3

4.3    Обеспечение целостности и конфиденциальности ключей........................................................... 3

5    Парольная защита.................................................................................................................................. 3

6    Выработка ключа по протоколу Диффи-Хелмана................................................................................. 4

7    Формат PFX контейнера......................................................................................................................... 4

8    Модули ASN.1.......................................................................................................................................... 5

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

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

III

Введение

Настоящие рекомендации содержат расширения документов PKCS#8 «PrivateKey Information Syntax Standard» версии 1.2 (1) и PKCS#12 «Personal Information Exchange Syntax» версии 1.0 (2), описывающие формирование транспортных ключевых контейнеров для ключей, созданных в соответствии с ГОСТ Р 34.10.

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

Примечание — Основная часть настоящих рекомендаций дополнена приложением А

IV

РЕКОМЕНДАЦИИ

П О

Р 50.1.112—2016

СТАНДАРТИЗАЦИИ

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

Information technology Cryptographic data security Transport key container

Дата введения — 2017—06—01

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

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

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

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

ГОСТ 28147-89 Системы обработки информации. Защита криптографическая. Алгоритмы криптографического преобразования

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

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

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

Р 50.1.111—2016 Информационная технология. Криптографическая защита информации. Парольная защита ключевой информации

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

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

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

Р— пароль, представляющий собой символьную строку в кодировке Unicode UTF-8;

S — случайное значение синхропосылки;

|| — конкатенация двух байтовых строк; для двух байтовых строк о=(о,.....Оп.)е8о,,    /3=(/3,.....Рп_:)еВп_:

их конкатенацией а\\р называется байтовая строка у=(а,.....ап,. р,...../3i>..)€8n,+/»2.

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

4 Представление ключей ГОСТ Р 34.10 и ГОСТ 28147-89

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

Алгоритм наложения маски определен базовой операцией криптографического преобразования алгоритма. Для ключей по ГОСТ Р 34.10 это умножение в поле Fq, для ключей по ГОСТ 28147-89 — сложение по модулю 2³².

Задана последовательность из к масок М, ,М₂ М_к. Через М,{) обозначают операцию наложения

hй маски, а через ЛГ’Д ) — операцию снятия /-й маски, 1Sr<fc. Имеется ключ К. Маскированный ключ К_м получается в результате Л-кратного применения операции наложения маски, а именно Км=М_к{...(М₂{М^К))...). Демаскирование выполняется при помощи Л-кратного применения операции снятия маски, но в обратном порядке, а именно К=ЛГ¹1( ■ (М\.,(М'^]ЛК_м))...). Маскированный ключ представляется как последовательность 1=К_м\\М_} \\М₂\\. . \\М_к. где «Ц» — операция конкатенации. Предположим. ключКимеетлдвоичныхразрядов, тогда для представления в памяти последовательности

1    понадобится (к+1)п двоичных разрядов или к* 1 n-разрядных блоков.

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

Таким образом, пара ключей для алгоритма по ГОСТ Р 34.10 представлена в виде:

GostR3410-2012-Key Valuelnfo :: = SEQUENCE{

GostR3410-2012-Key ValueMask.

GostR3410-2012-PublicKey}. где

GostR3410-2012-KeyValueMask ::= OCTET STRING { K_M\\M, ||M₂||... ||M*}. и GostR3410-2012-PublicKey :: = OCTET STRING {PubKeyX|PubKeyY}.

Для алгоритма ГОСТ 28147-89 ключ представляется в виде:

Gost28147-89-Key-KeyValueMask ::= OCTET STRING { К_м||М, ||M₂|| . \\М_к)

Возможно использование немаскированного закрытого ключа (т. е. к = 0, К_м - К).

Для обеспечения унификации между представлениями ключей в PFX и сертификатах формата Х.509. как секретный, так и открытый ключи представляются в формате little-endian (старший байт справа). Операцией наложения маски является умножение ключа на число, обратное маске:

К_м = К * М^л mod Q,

где значение Q взято из параметров ключа. Соответственно операцией снятия маски является умножение маскированного ключа на маску:

К = К_ы • М mod Q.

4.1 Портфель ключевой информации КеуВад

В соответствии с (1] и (2] портфель ключевой информации КеуВад представлен в следующем

виде:

PrivateKeylnfo SEQUENCE { version Version.

privateKeyAlgorithm PrivateKeyAlgorithmldentifier. privateKey PrivateKey.

attributes (0) IMPLICIT Attributes OPTIONAL}

Version ::= INTEGER

Версия структуры на данный момент равна нулю.

PrivateKeyAlgorithmldentifier ::= Algorithmldentifier

Для закрытых ключей по ГОСТ Р 34.10 используют идентификаторы соответствующих открытых ключей, представленные в рекомендациях [3].

PrivateKey ::= OCTET STRING

Содержимым данного типа является значение закрытого ключа, закодированное в соответствии с типом GostR3410-2012-PrivateKey:

2

P 50.1.112—2016

GostR3410-2012-PrivateKey ::= CHOICE {

GostR3410-2012-KeyValueMask.

GostR3410-2012-KeyValuelnfo}

Attributes ::= SET OF Attribute

Атрибуты могут содержать дополнительную необходимую информацию о ключе.

Ключ в зашифрованном виде представлен в виде структуры:

EncryptedPrivateKeylnfo ::= SEQUENCE { encryptionAlgorithm EncryptionAlgorithmldentifier, encryptedData EncryptedData}

EncryptionAlgorithmldentifier ::= Algorithmldentifier

При шифровании должен быть использован алгоритм PBES2 по Р 50.1.111—2016. Алгоритм и параметры шифрования EncryptionAlgorithmldentifier указаны в соответствии с Р 50.1.111— 2016.

EncryptedData ::= OCTET STRING

Содержимым данного типа является результат зашифрования кодированной структуры Private-Key Info.

4.2    Данные, защищаемые в транспортном ключевом контейнере

В соответствии с 4.1 [2J каждый раздел транспортных ключевых контейнеров (далее — ТКК), содержащий конфиденциальные сведения, должен быть зашифрован в рамках Contentlnfo типа Authenti-catedSafe. Портфель сертификата (CertBag — см. 4.2.3 (2)). соответствующий присутствующему в ТКК портфелю закрытого ключа (КеуВад). несет в себе информацию, облетающую потенциальному злоумышленнику задачу первичного анализа перехваченного зашифрованного сообщения, в частности по данным, содержащимся в сертификате, можно получить информацию о владельце секретного ключа. В этой связи содержащийся в ТКК CertBag также может быть зашифрован.

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

4.3    Обеспечение целостности и конфиденциальности ключей

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

5 Парольная защита

У отправителя и принимающего имеется предварительно согласованный пароль Р. Отправитель с помощью алгоритма диверсификации вырабатывает парольный ключ по алгоритму PBKDF2 в соответствии с Р 50.1.111—2016 и использует его для шифрования передаваемого закрытого ключа. Принимающий независимо вырабатывает парольный ключ и использует его для извлечения закрытого ключа из ТКК.

Целостность ТКК обеспечивается с использованием алгоритма HMAC_GOSTR3411_2012_512 в соответствии с Р 50.1.113—2016.

Ввиду простоты реализации этот способ является наиболее приемлемым для большинства практических припожений.

Для шифрования различных разделов ТКК используется один и тот же пароль Р, но различные случайные значения параметра S длиной от 8 до 32 байт.

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

При проверке целостности ТКК с помощью алгоритма HMAC_GOSTR3411_2012_512 ключ для данного алгоритма также вырабатывается по алгоритму PBKDF2 с тем же самым значением параметра Р и случайным вектором 5длиной от 8 до 32 байт. Ключом алгоритма HMAC_GOSTR3411_2012_512 должны быть последние 32 байта 96-байтовой последовательности, вырабатываемой с помощью PBKDF2.

Использован идентификатор алгоритма:

id-tc26-hmac-gost-3411-12-512::= {iso(1) member-body(2) ru(643) rosstandart (7) tk26(1) algorithms(l) mac(4) hash512(1)}

Функция HMAC_GOSTR3411_2012_512 вычисляется от содержимого поля content структуры authSafe (см. 7).

3

6    Выработка ключа по протоколу Диффи-Хелмана

В случае наличия у отправителя предварительно распределенной ключевой пары, сформированной по алгоритму ГОСТ Р 34.10 и соответствующего сертификата электронной подписи, для согласования ключей защиты ТКК должен быть использован алгоритм VKO_GOSTR3410_2012_256 или VKO_GOSTR3410_2012_512 в зависимости от параметров ключей (см. раздел 6 (4J).

Целостность контейнера в этом случае обеспечивается электронной подписью на ключе отправителя.

7    Формат PFX контейнера

В соответствии с PKCS#12 контейнер имеет вид:

PFX ::= SEQUENCE {

version    INTEGER (v3(3)}(v3....).

authSafe    Contentlnfo.

macOata    MacData OPTIONAL

}

MacData ::= SEQUENCE { mac    Digestlnfo.

macSalt    OCTET STRING,

iterations    INTEGER DEFAULT 1

>.

где authSafe в зависимости от метода контроля целостности представляется либо как тип data при использовании парольной защиты, либо как signedData — в случае использования электронной подписи отправителя для защиты целостности контейнера, в соответствии с разделом 5 (5).

В случае использования парольной защиты для контроля целостности поле macData должно содержать информацию об алгоритме и параметрах выработки парольного ключа в соответствии с 7.1 Р 50.1.111—2016. Контроль целостности обеспечивается с использованием алгоритма НМАС_ GOSTR3411_2012_512.

В случае использования электронной подписи поле macData отсутствует. Информация о сертификате отправителя и электронная подпись размещены в структуре signedData в соответствии с разделом 5 (4).

Данные в authSafe представляют собой результат кодирования списка объектов: AuthenticatedSafe ::= SEQUENCE OF Contentlnfo

-    Data if unencrypted

-    EncryptedData if password-encrypted

-    Enveloped Data if public key-encrypted

При использовании алгоритма Диффи-Хелмана для выработки ключа обмена данные представляются в виде EnvelopedData в соответствии с разделом 6 (5). Шифрование содержимого и согласование ключей должны осуществлять в соответствии с рекомендациями разделов 6 и 7 (4).

AuthenticatedSafe может содержать объекты различного типа: ключи, сертификаты, списки отозванных сертификатов. В соответствии с [2]:

SafeBag ::= SEQUENCE {

bagld    BAG-TYPE.&id ({PKCS12BagSet})

bag Value    (0) EXPLICIT BAG-TYPE.&Type({PKCS12BagSet}{@bagld}),

bagAttributes    SET    OF    PKCS12Attribute OPTIONAL

}

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

keyBag BAG-TYPE

{KeyBag IDENTIFIED BY {bagtypes 1}} bagValue в этом случае содержит ключ и информацию о нем в виде PrivateKeylnfo.

При использовании парольной защиты для хранения ключа должен использоваться тип: pkcs8ShroudedKeyBag BAG-TYPE ::=

{PKCS8ShroudedKeyBag IDENTIFIED BY {bagtypes 2}}

4

P 50.1.112—2016

bagValue в этом случае содержит ключ и информацию о нем в зашифрованном виде EncryptedPri-vateKeylnfo.

При шифровании сертификата с использованием парольной защиты зашифрованная структура CertBag помещается в структуру EncryptedData в соответствии с разделом 8 (5):

EncryptedData ::= SEQUENCE { version Version.

encryptedContentlnfo EncryptedContentlnfo}

8 Модули ASN.1

PKCS-12RU {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) nK)dules(O) pkcs-12ruSyntax(5)}

DEFINITIONS EXPLICIT TAGS ::=

BEGIN

IMPORTS

GostR3410-2012-PublicKey FROM GostR3410-2012-PKISyntax {iso(1) member-body(2) ru(643) rosstandart(7) tc26(1) modules(O) gostR3410-2012-PKISyntax(2)};

GostR3410-2012-KeyValueMask ::= OCTET STRING

GostR3410-2012-KeyValuelnfo ::= SEQUENCE{

gostR3410-2012-Key ValueMask GoslR3410-2012-KeyValueMask, gostR3410-2012-PublicKey GostR3410-2012-PublicKey

}

GostR3410-2012-PrivateKey ::= CHOICE {

gostR3410-2012-KeyValueMask GostR3410-2012-KeyValueMask. gostR3410-2012-KeyValuelnfo GostR3410-2012-KeyVaiuelnfo

}

END

5

Приложение A (справочное)

Контрольные примеры

В данном приложении приведен пример контейнера, зашифрованного на пароле «Пароль для PFX» в соответствии с изложенной в данном документе схемой А1 Сертификаты

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

А1.1 Корневой сертификат

Значение корневого сертификата закодированное с соответствии с алгоритмом BASE64

Представление ASN 1 корневого сертификата

0 30 702 SEQUENCE { 4 30 617 SEQUENCE { 8 АО 3 [0] { 10 02 1 INTEGER 2 } INTEGER 13 02 16 01 00 68 5E F2 FC 40 20 00 00 00 OB 27 09 00 01 31 30 12 SEQUENCE { 33 06 8 OBЗЕСТ IDENTIFIER 1 2 643 7 113 2' 43 05 0 NULL > SEQUENCE { 45 30 96 47 31 11 SET { 49 30 9 SEQUENCE { 51 06 3 0B3ECT IDENTIFIER ’2 5 4 6* 56 13 2 PrintableString ' RU' > 60 31 21 } SET { 62 30 19 SEQUENCE { 64 06 3 OB3ECT IDENTIFIER '2 5 4 7* 69 ОС 12 UTF8String •Москва' > 83 31 15 } SET { 85 30 13 SEQUENCE { 87 06 3 OB3ECT IDENTIFIER *2 5 4 10* 92 ОС 6 UTF8String 'TK26'

MIICvjCCAmmgAwIBAgIQAdBoXvL8TSAAAAALJwkAATAMBggqhQMHAQEDAgUAMGAx CzA3BgNVBAYTAl3VMRlhvEwYDVQQHDAzQnNC+OYHQutCyOLAxDzANBgNVBAoMBtCi 03oyNjEpMCcGAlUEAv4wgQ0EgY2VydGlmaWNhdGUgKFBLQlMjMTIgZXhhbXBsZSkw HhcNMTUwMzI3MDcyMzA*VtocNMjAwMzI3MDcyMzAwWjBgMQsv4<QYDVQQGEwJSVTEV MBMGAlUEBw\\W03zQvtGB0LrQstCwMQ8w0QYDVQQKDAbQotCaMjYxKTAnBgNV8AMM IENBIGNlcnRpZmljYXRlIChQS0NTIzEyIGV4YWlwtoGUpMGYwHwYIKoUDBwEBAQEw EwYHKoUDAgIjAQYIKoUDBwEBAgIDQwAEQBxYC72z7PQ0LZCzWEliXy7kNPks570v ENM2iUsWGwCOpk37mkGFBUmfkl3Vk3amjlCzr/v/Ab49c/GcCq3ap2eBCQAyNzA5 MDAwMYI3ADI3MDkwMDAxo4HfMIHcMA4GAlUdD*EB/v4QEAwIBx jAPBgNVHRMBAf8E BTADAQH/MBOGAlUdDgQWBBQmnc7Xh5ykb5t/BMwOkxA4drfEmjCBmQYDVROjBIGR MIGOgBQfnnc7Xh5ykb5t/BMwOkxA4drfEmqFkpGIwYDELMAkGAlUEBhMCUlUxFTAT BgNVBAcMDNCc0L7RgdC60LLQsDEPMA0GAlUECgwG0KLQmjI2MSkw3wYDVQQDDCBD QSBjZX30aWZpY2F0ZSAoUEtDUyMxMiBleGFtcGxlKYIQAdBoXvL8TSAAAAAL3wkA ATAMBggqhQMHAQEDAgUAA0EA*+0azMpEpK*nTLyt3K0Ymr6RoeGtfSjXfUhLfsx8 u!3qzr9wEMK55pMNjMa8upPRi SmV8oZ+aw4ihq3Ltl8hfQ==

}

}

6