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

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

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

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

Москва

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

2018

Предисловие

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

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

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

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

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

© Стандартинформ, 2018

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

P 1323565.1.016—2018

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

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

Приводимое ниже значение счетчика АТС, а также значения ключей карты    мастер-ключ    МК_ЮЫ

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

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

В данном приложении двоичные строки из V*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации («||») опускается. То есть строка а Е будет представлена в виде CL_r_₁a_r_n ■■■ где Е {0,1,..., 9, a, b, с, d, e,f}, i — ОД,...,г — 1. Соответствие между двоичными строками длины 4 и шестнадцатеричными строками длины 1 задается естественным образом (таблица А.1).

Преобразование, ставящее в соответствие двоичной строке длины 4г шестнадцатеричную строку длины г, и соответствующее обратное преобразование для простоты записи опускаются.

Таблица А.1 —Соответствие между двоичными и шестнадцатеричными строками

0000	0
0001	1
0010	2
0011	3
0100	4
0101	5
0110	6
0111	7
1000	8
1001	9
1010	а
1011	ь
1100	С
1101	d
1110	е
1111	f

А.1 Исходные данные АТС = 0010₁₆

MK_IDN = 4ea368db926daSbl01c32d34fQb2AS03\\ 53dbl04eA4ddS7df907e00S94b299dcd_1€

Закрытый ключ карты:

5;_с, = cE92cE431cE2037SccE2a537ccE64Sel4i>60b\\ 4c21al5aS79361b7be419bl6ed861374₁₆

1

P 1323565.1.016—2018

Открытый ключ карты:

P_icc = 030б54ассЕ14аеЕ85еЕбЬ246ес4а195Ь334\\ ecfef93clf22b67cfGlff7d35e8ddeiQ\\ e533c3£>327e93£>136697eeE5cS6173ij44\\ 341cS/5b9792e9S362170a993dS4a472₁₆

Символ «\\» обозначает перенос числа на новую строку.

А.1.1 Формирование объекта ICC Dynamic Number (IDN)

С помощью исходных данных и мастер-ключа MK_1DN, получается следующее значение IDN: IDN = /3262238₁₆

А.1.2 Динамическая аутентификация платежного приложения

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

Data = 1511010504/326223801020304₁₆

Для формирования подписи отданных Data вычисляется их хэш-код:

HoshData = 4d2/6S46422cea0e25eE73a/8i?5ei50546\\ 68cc8d553cE45e9S/43cEcE20S47003b/ee_lg

С помощью случайного числа к, равного

к = al/3cEb706b09/11176c591c6073el9ba\\

3ai?9185944/71661057679400/4886еЕ8_1е

и закрытого ключа карты получается следующее значение подписи отданных Data'.

Sign = 83775ddcSS33ftc7ft67/4SdftftftS07572e\\

c34ccE013bc45cEl5b8146334b440aclcb\\

5b0356ccccE0a07cE93cE7S44cE6cEla6cal3\\

clcEll8ee5637cEcc53739cE6 l/9i?a645b/_ls

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6al511010504/S26223S\\

33775cEcEc8S33ac7a67/43cEaaa807572e\\

с34ссЕ013Ьс45сЕ151г3146834Ь440ас1сЬ\\

5Ь0356ссссЕ0а07сЕ93сЕ7344сЕбсЕ1а6са13\\

cld.ll3eeS637dccS3739d61f9ba64Sbf\\

A.1.3 Комбинированная аутентификация платежного приложения

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

Data = 1511012е04/3262238\\

0092122/2?е92122/Ье\\

с34ссЕ013Ьс45сЕ15Ь3146334Ь440ас1сЬ\\

5Ь035бссссЕ0а07сЕ93сЕ7344сЕбсЕ1а6са13\\

01020304₁₆

8

Для формирования подписи отданных Data вычисляется их хэш-код:

HashData = cl872c6de7596424d3c92ecce260f7fl\\ ff6636b01a33160372f635e0de4e6bdl₁₆

С помощью случайного числа к, равного

к = d5149e302f75abcccbbS9525d3cc3343\\ bf3bd942a3b33423171b36fl0132ca3S_li

И закрытого ключа карты S_icc получается следующее значение подписи отданных Data'.

Sign = f9a3b32ab6205562171c9d.3ab32b0b4e\\ 66a23923f01c2399b9d5213956203bfb\\ 0bdc3cbc360fc252cf3a36bbl05b7123\\ c0a2776e92bcf099f3a386blc638b37c₁₆

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6al511012e04/S262238\\

0092122fbe92122fbe\\

c84cd013bc45dl5b8146334b440aclcb\\

5b0356cccd0a07d93d7844d6dla6cal3\\

f9a8bS2ab6205S62171c9d8ab82b0b4e\\

66a23923f01c2399b9d5213956203bfb\\

0bdc3cbc360fc232cf3a36bbl05b7123\\

c0a2776e92bcf099f3a336blc633b37c\\

A.2 Исходные данные АТС = 0010₁₆

MK_IDN = 23df44a5dd9e2c755504dc4c736427b3\\ 6473341d3fea535fb09c34al410f3097₁₆

Закрытый ключ карты:

5_iCp = 0505050505050505050505050505050S\\ 0505050505050S0505050S050505050S_ls

Открытый ключ карты:

P_icc = 2221dfl366230f2cfd73d2dSf0f4719a\\ caal37bf4fabld3193ab53c9c300fbf2\\ 4db2aS7d9c26c61aS86cfal004lS66ad\\ 01030033ed2456eS3S5d7467cbec327d_1&

A.2.1 Формирование объекта ICC Dynamic Number (IDN)

С помощью исходных данных и мастер-ключа MK_1DN получается следующее значение IDN:

IDN = 00663246509/еЕ5₁₆

P 1323565.1.016—2018

A.2.2 Динамическая аутентификация платежного приложения

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

Data = 151101030700663246509/еЕ511211303₁₆

Для формирования подписи отданных Data вычисляется их хэш-код:

HashData = 7b//6d3dle3d9i?1916d2S9e5015S/47e\\

Ь927e75ccldle4bc4dded448889544b4_L6 С помощью случайного числа к, равного к — 91ccaa44f9e692abcf7deb01cfQf92c5\\ b900768bdb7b7S3be6clae94d23a8e46_ls И закрытого ключа карты получается следующее значение подписи отданных Data'.

Sign = ea903S4fee62ab026461cdl34791fdla\\ cE6aa2c6a.cE6i»884/2923eif/ece5247ccEa\\ сеЕ9863сс73/57М01/6сЬ725с64еЕ550е\\ d07f9b601cdl939b 28 721^249I53d52₁₆

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6al51101030700663246509/cE5\\

ea90354/ee62ai?026461ccil34791/dla\\

cE6aa2c6acE6b334/2923eb/ece5247ccEa\\

cd9863cc78fS7bl01f6cb72Sc64dSS0e\\

d07f9b601cdl939b28721d249l53clS2\\

A.2.3 Комбинированная аутентификация платежного приложения

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

Data = 151101310700663246509/еЕ5\\

405с75Ь8ес5с75Ь8ес\\

сЕб аа2 сб ad6 b334/29 2 3ebfe се5247сеЕа\\

сеЕ9363сс73/57 b 101/6с£>725с64е£550е\\

11211303₁₆

Для формирования подписи отданных Data вычисляется их хэш-код:

HashData — (b22dbabl88cS4abbddf331dl4c47134S\\ с9еЕеЕ37/0е0333с03сЬ0с0е33843еае38_1Ё

С помощью случайного числа к, равного

к = е303//5сссЬ/16бМ4сЬ2е/3291844е7\\ ЗЬ9сЕ05265536030519а38Ье1сЗс8Ь4е3_1й и закрытого ключа карты S_icc получается следующее значение подписи отданных Data'.

Sign = сЕЗа0ссЕа7911еЗ/0сЕЗаЗс/е248сЕ0462с2\\ 9с96сЕ1с6501009/69е6с69329с646а/7\\

10

еЕ310бЬ5е447£>54202Ь73284сс65е[8274\\

а919Ь/42607е9о.е46ее30а89446йЗа73_1й

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6a.l51101310700663246509/eE5\\

405с75Ь8ес5с75£>8ес\\

d6aa2c6ad6b884/2923ebfeceS247cda\\

cd9G63cc78fS7bl01f6cb72Sc64d5S0e\\

d8a0cda79Ile3f0d8a3cfe248d0462c2\\

9c96dlc6501009/69e6c69329c646a/7\\

еШ0бЬ5е447Ь54202Ь73284сс65еЕ8274\\

a.919b/42607e9ae46ee30a89446cE3a73\\

bcis

A.3 Исходные данные ATT = 0010₁₆

MK_IDN = 32623 6064be404964eE716c47 db6bBdab\\ 75d9cb0cb599db24:0c782db8fal40ac7₁₆

Закрытый ключ карты:

Sw = 246954/9881еЕ2913/373с01£>6еЕ8с9сс0\\

01563еЕ191073316e3a3 ae 11741329523₁₆ Открытый ключ карты:

Р_гсс = 4fc5f57ab09aa6f0f74:33edefbb4bcbe\\ 4363d64/c/5ec69452982c/ae/61/еЕс6\\ ae37764i?c9/910905995e92389537//3\\ Ьб32938а4обЬ8е5с[1Ьее20с[ее371е258₁₆

A.3.1 Формирование объекта ICC Dynamic Number (IDN)

С помощью исходных данных и мастер-ключа MK_lON получается следующее значение IDN: IDN = Ь074461Ь04с6479е₁₆

А.3.2 Динамическая аутентификация платежного приложения

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

Data = 1511010908b074461i>04c6479el2aal698₁₆

Для формирования подписи отданных Data вычисляется их хэш-код:

HashData = 06eM9d75d4894d5257993/cd34996c2\\ b24/a403ijQ7eSl/66609da6i?0/793d50₁₆

С помощью случайного числа к, равного

к = 15Ь318с/е252177/9bbaSfbfbbA18a$5\\ 7са303/25е6а85987//1е71Ь9с804933₁₆

P 1323565.1.016—2018

И закрытого ключа карты S_icc получается следующее значение подписи отданных Data'.

Sign = C232895a96827d6d9dabl7019ff2e7b2\\ 1995a29d7f956f3c8331f80f763cd941\\ 3tt0eE0686964425395abceEelSb7S272cb\\ 3/9ЬсЕес417124Ь514364ссЕ99237ее985_1е

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6al511010908b074461b04c6479e\\

C232895a96327d6d9dabl7019ff2e7b2\\

199Sa29d7f9S6f3c8331f80f76Scd941\\

3a0d0686964425395abcdel8b78272cb\\

3f9bdec417124bS14364cd99237ee98S\\

bci₆

A.3.3 Комбинированная аутентификация платежного приложения

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

Data = 1511013208Ь074461Ь04с6479е\\ 405c75b8ec5c75b8ec\\ 3a0d063696442539Sabcdel3b73272cb\\ C232895a96827d6d9dabl7019ff2e7b2\\ 12аа1698₁₆

Для формирования подписи отданных Data вычисляется их хэш-код:

HashData = 676а396/98/92398сс3436/Ь/с2сЬ571\\ 7399fcc9b8bhm 1//7544/е8Ь0421875_1е

С помощью случайного числа к, равного

к = сЕс4038595асЕ9е94013асЕ898665е46617\\ 1о.5/4с7сс4с/688е494Ьб7/250сс09е/₁₆ и закрытого ключа карты получается следующее значение подписи отданных Data'.

Sign = f88l574fdddd25b547e31fl7d99bc4e0\\ e7dee679c9af018fd32d36bf27ab6fb3\\

0/6 dO 7ff7 b If 8 c9 7 Леса \feb73 be 6fc4\ \ 1309eae6d24f09d90bd3adlb5e465cb6_li

В итоге получается следующее значение объекта Signed Dynamic Application Data:

Signed Dynamic Application Data = 6al511013208b074461b04c6479e\\

405c75b8ec5c75b8ec\\

3a0d0636964425395abcdel8b78272cb\\

C232895a9b827dbd9dabl7019ff2e7b2\\

12

f33l574fdddd25b547e31fl7d99bc4e0\\ e7dee679c9af013fd32d36bf27ab6fb3\\ Of 6 dO 7ff7 blf3 c974ccalfe b7 3 6e 6/c4\\ 1309eae6d2if09d90bd3adlbSe46Scb6\\

УДК 681.3.06:006.354    ОКС 35. 040

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

14

БЗ 3—2018/54

Редактор Л.С. Зимилова Технический редактор И.Е. Черепкова Корректор И.А. Королева Компьютерная верстка И.А. Налейкиной

Сдано в набор 06.03.2018. Подписано в печать 21.03.2018. Формат 60><84¹/₈. Гарнитура Ариал. Уел. печ. л. 2,32. Уч.-изд. л. 2,10. Тираж 20 экз. Зак. 459.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Издано и отпечатано во ФГУП «СТАНДАРТИНФОРМ», 123001 Москва, Гранатный пер., 4.

www.gostinfo.ru info@gostinfo.ru

P 1323565.1.016—2018

Содержание

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

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

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

4    Описание алгоритмов.................................................................3

4.1    Алгоритм формирования объекта ICC Dynamic Number (IDN).............................3

4.2    Динамическая аутентификация платежного приложения (DDA)...........................3

4.3    Комбинированная аутентификация платежного приложения (CDA)........................4

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

Введение

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

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

Команда GENERATE АС отправляет связанные с транзакцией данные на карту, которая вычисляет и возвращает криптограмму приложения.

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

Примечание — Настоящие рекомендации дополнены приложением А.

IV

P 1323565.1.016—2018

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

Информационная технология

КРИПТОГРАФИЧЕСКАЯ ЗАЩИТА ИНФОРМАЦИИ

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

Information technology. Cryptographic data security.

Using block encryption algorithm modes, digital signature algorithm and hash function in offline authentication

of the payment application

Дата введения — 2018—08—01

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

Настоящие рекомендации предназначены для описания алгоритмов, используемых в процессе оффлайновой аутентификации в платежной системе «МИР».

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

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

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

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

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

Р 1323565.1.010—2017 Информационная технология. Криптографическая защита информации. Использование функции диверсификации для формирования производных ключей платежного приложения

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

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

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

P 1323565.1.016—2018

Unpredictable Number — случайное число, генерируемое терминалом. Длина значения равна

4 байтам.

4 Описание алгоритмов

Суть методов состоит в том, что терминал генерирует случайное число, передаваемое карте вместе с некоторыми другими данными для подписи.

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

Оффлайновая аутентификация карты выполняется при каждой транзакции. Выбор метода аутентификации осуществляется терминалом на основе возможностей терминала и профиля обмена приложениями.

Для оффлайновой аутентификации карты используются специальные сертификаты, формат которых представлен в Рекомендации «Задание параметров алгоритмов электронной подписи и функции хэширования в профиле сертификатов открытых ключей платежных систем».

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

4.1    Алгоритм формирования объекта ICC Dynamic Number (IDN)

Объект данных IDN представляет собой результат зашифрования (j!7'C|rOxOO^J||'OjtOO^J|rOjcOO^J|rOjOO^J||'OxOO^,||'OjOOO на ключе МК_ШЯ в соответствии с ГОСТ 28147-89 в режиме простой замены с узлом замены id-tc26-gost-28147-param-Z:

IDN = * (ЛГС| |U*Oir| lllrtir I ITtaOlTI |'0*00* | |U*Off| Г0х011>

В качестве IDN выбираются n левых (старших) байтов результата зашифрования, где п = IDN Length (принимает значение от 2 до 8).

4.2    Динамическая аутентификация платежного приложения (DDA)

4.2.1 Формирование данных и установка подписи платежного приложения

Карта в соответствии со списком объекта DDOL формирует поля, определенные в таблице 1.

Таблица 1

Имя поля Длина, байт Описание Signed Data Format (формат подписываемых данных) 1 Значение ‘0x15’ Public Key Algorithm Indicator (индикатор алгоритма подписи) 1 Идентифицирует алгоритм подписи; принимает значение ‘0x1 Т, соответствующее алгоритму id-tc26-gost3410-2012-256 Public Key Parameters Indicator (индикатор набора параметров алгоритма подписи) 1 Идентифицирует набор параметров алгоритма подписи; принимает значение ‘0х0Т, соответствующее id-GostR3410-2001 -С ryptoPro-A-ParamSet ICC Dynamic Data Length (длина динамических данных карты) 1 Длина динамических данных в байтах ICC Dynamic Data (динами-ческие данные карты) IDN Length Ldd 1 Динамические данные, сформированные картой или сохраненные на карте IDN 2—8 Unpredictable Number 4 Случайное число, генерируемое терминалом

3

Данные таблицы 1 подписываются секретным ключом карты S_icc в соответствии с ГОСТ Р 34.10-2012 с длиной ключа порядка 256 бит. После чего формируется Signed Dynamic Application Data согласно таблице 2.

Таблица 2

Имя поля Длина, байт Описание Data Header (заголовок) 1 Значение ‘0x6а’ Signed Data Format (формат данных) 1 Значение ‘0x15’ Public Key Algorithm Indicator (индикатор алгоритма подписи) 1 Идентифицирует алгоритм подписи; принимает значение ‘0x11 ’, соответствующее алгоритму id-tc26-gost3410-2012-256 Public Key Parameters Indicator (индикатор набора параметров алгоритма подписи) 1 Идентифицирует набор параметров алгоритма подписи; принимает значение ‘0х0Т, соответствующее id-GostR3410-2001 -С ryptoPro-A-ParamSet ICC Dynamic Data Length (длина динамических данных карты) 1 Длина динамических данных в байтах ICC Dynamic Data (динамические дан-ные карты) IDN Length Ldd 1 Динамические данные, сформированные картой или сохраненные на карте IDN 2—8 Signature (подпись) 64 Подпись от данных, приведенных в таблице 1, в соответствии с ГОСТ Р 34.10-2012 256 бит Data Trailer 1 ‘Oxbc’

Полученный результат (Signed Dynamic Application Data) направляется терминалу в поле данных ответа на команду INTERNAL AUTHENTICATE.

4.2.2 Проверка подписи данных платежного приложения карты терминалом

Проверка терминалом полученного значения Signed Dynamic Application Data выполняется с помощью открытого ключа карты P_icc. Для этого:

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

-    верифицируется сертификат открытого ключа эмитента C_icc__iss согласно Р 1323565.1.015—2018;

-    извлекается открытый ключ эмитента

-    верифицируется сертификат открытого ключа карты C_iCF согласно Р 1323565.1.015—2018;

-    извлекается открытый ключ карты

-    формируются данные таблицы 1;

-    выполняется проверка цифровой подписи (Signature), приведенной в таблице 2, в соответствии с ГОСТ Р 34.10-2012 с длиной ключа порядка 256 бит;

-    производится проверка элемента «Формат данных» (Signed Data Format), который должен быть равен ‘0x15’.

Карта считается успешно аутентифицированной, когда все проверки завершились успешно. В этом случае терминал запоминает значение IDN, если оно присутствует в данных Signed Dynamic Application Data, для последующей пересылки эмитенту при верификации.

4.3 Комбинированная аутентификация платежного приложения (CDA)

4.3.1 Формирование данных и установка подписи платежного приложения

Карта формирует объект Transaction Data Hash Code, для чего используется алгоритм ГОСТ Р 34.11-2012 с длиной ключа порядка 256 бит, выполняемый над приведенными ниже данными, взятыми в следующем порядке:

-    поля данных объектов, определенных в списке PDOL, взятые в том же порядке, в котором они приведены в PDOL;

-    поля данных объектов, определенных в списке CDOL1, взятые в том же порядке, в котором они приведены в CDOL1;

4

P 1323565.1.016—2018

-    поля данных объектов, определенных в списке CDOL2, взятые в том же порядке, в котором они приведены в CDOL2;

-    значения полей Tag, Length, Value объектов данных (за исключением объекта Signed Dynamic Application Data), возвращаемых картой в ответе на первую (вторую) команду GENERATE АС, взятые в том же порядке, в котором они возвращаются терминалу.

После формирования Transaction Data Hash Code карта создает Signed Dynamic Application Data, для чего формирует поля, определенные в таблице 3.

Таблица 3

Имя поля Длина, байт Описание Signed Data Format (формат подписываемых данных) 1 Значение ‘0x15’ Public Key Algorithm Indicator (индикатор алгоритма подписи) 1 Идентифицирует алгоритм подписи; принимает значение ‘0x1 Т, соответствующее алгоритму id-tc26-gost3410-2012-256 Public Key Parameters Indicator (индикатор набора параметров алгоритма подписи) 1 Идентифицирует набор параметров алгоритма подписи; принимает значение ‘0x01’, соответствующее id-GostR3410-2001 -С ryptoPro-A-ParamSet ICC Dynamic Data Length (длина динамических данных карты) 1 Длина динамических данных в байтах ICC Dynamic Data (динамические данные карты) IDN Length 1 Динамические данные, сформированные картой или сохраненные на карте IDN 2 — 8 CID 1 Криптограмма TC, AAC или ARQC 8 Transaction Data Hash Code 32 Unpredictable Number 4 Случайное число, генерируемое терминалом

Затем данные, приведенные в таблице 3, подписываются секретным ключом карты S_icc в соответствии с ГОСТ Р 34.10-2012 с длиной ключа порядка 256 бит. После чего формируется Signed Dynamic Application Data согласно таблице 4.

Таблица 4

Имя поля Длина, байт Описание Data Header (заголовок) 1 Значение ‘ОхбА’ Signed Data Format (формат подписываемых данных) 1 Значение ‘0x15’ Hash Algorithm Indicator (идентификатор алгоритма хэширования) 1 Идентифицирует алгоритм хэширования; принимает значение ‘0x11’, соответствующее алгоритму id-tc26-gost3411-2012-256 Public Key Algorithm Indicator (индикатор алгоритма подписи) 1 Идентифицирует алгоритм подписи; принимает значение ‘0x11’, соответствующее алгоритму id-tc26-gost3410-2012-256 Public Key Parameters Indicator (индикатор набора параметров алгоритма подписи) 1 Идентифицирует набор параметров алгоритма подписи; принимает значение‘0x01’, соответствующее id-GostR3410-2001 -CryptoPro-A-ParamSet

5

Окончание таблицы 4

Имя поля Длина, байт Описание ICC Dynamic Data Length (длина динамических данных карты) 1 Длина динамических данных в байтах ICC Dynamic Data (динамические данные карты) Ldd Динамические данные, сформированные картой или сохраненные на карте Signature (подпись) 64 Подпись отданных, приведенных в таблице 3, в соответствии с ГОСТ Р 34.10-2012 с длиной ключа порядка 256 бит Data Trailer 1 ‘ОхВС’

Полученный результат (Signed Dynamic Application Data) направляется терминалу в поле данных ответа на команду GENERATE АС.

Структура поля данных ответа на команду GENERATE АС представлена в таблице 5.

Таблица 5

Имя поля Тэг Длина, байт Описание CID ‘ 9F27’ 1 Определяет тип криптограммы АТС ‘ 9F36’ 2 Счетчик транзакций приложения Signed Dynamic Application Data ‘9F4B’ 120 Подписанные критические данные приложения при использовании DDA или CDA Issuer Application Data ‘ 9F10’ 32 Issuer Application Data дает эмитенту информацию о приложении в процессе онлайн-транзакции в авторизационном запросе и, после завершения транзакции, в записях по клирингу

4.3.2 Проверка подписи данных платежного приложения карты терминалом

Проверка терминалом полученного значения Signed Dynamic Application Data выполняется с помощью открытого ключа карты P_icc-Для этого:

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

- верифицируется сертификат открытого ключа эмитента    согласно Р 1323565.1.015—2018;

-    извлекается открытый ключ эмитента

-    верифицируется сертификат открытого ключа карты C_icc согласно Р 1323565.1.015—2018;

-    извлекается открытый ключ карты P_icc-₃

-    формируются данные таблицы 3;

-    выполняется проверка цифровой подписи (Signature), приведенная в таблице 4, в соответствии с ГОСТ Р 34.10-2012 с длиной ключа порядка 256 бит;

-    выполняется проверка элемента «Формат данных» (Signed Data Format), который должен быть равен ‘0x15’;

-    производится проверка равенства значений CID, полученных из подписанных данных и из поля данных ответа на команду GENERATE АС;

-    производится проверка равенства значений Transaction Data Hash Code, полученных из подписанных данных и вычисленных терминалом самостоятельно на основе имеющихся в его распоряжении значений данных, используемых для вычисления Transaction Data Hash Code.

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