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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объект данных IDN представляет собой результат зашифрования (ATC||'0x00'||'0x00'||'0x00'||'0x00'||'0x00'||'0x00') на ключе MK_IDN в соответствии с ГОСТ 28147-89 в режиме простой замены с узлом замены id-tc26-gost-28147-param-Z:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Приводимое ниже значение счетчика ATC, а также значения ключей карты S_icc, P_icc, мастер-ключ MK_IDN рекомендуется использовать только для проверки корректной работы конкретной реализации алгоритмов, описанных в настоящих рекомендациях.

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

В данном приложении двоичные строки из V*, длина которых кратна 4, записываются в шестнадцатеричном виде, а символ конкатенации ("||") опускается. То есть строка будет представлена в виде a_r-1 a_r-2 ... a₀, где , i = 0, 1, ..., r = 1. Соответствие между двоичными строками длины 4 и шестнадцатеричными строками длины 1 задается естественным образом (таблица А.1).

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

А.1 Исходные данные

ATC = 0010₁₆

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

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

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

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

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

IDN = f8262238₁₆

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

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

Data = 1511010504f826223801020304₁₆

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

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

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

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

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

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

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

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

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

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

А.2 Исходные данные

ATC = 0010₁₆

MK_IDN = 23df44a5dd9e2c755504dc4c736427b8\\

6478841d8fea535fb09c34a1410f3097₁₆

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

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

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

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

IDN = 00663246509fd5₁₆

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

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

Data = 151101080700663246509fd511211308₁₆

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

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

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

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

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

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

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

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

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

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

А.3 Исходные данные

ATC = 0010₁₆

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

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

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

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

IDN = b074461b04c6479e₁₆

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

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

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

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

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

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

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

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

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

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

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

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