Известная международная организация GlobalPlatform, занимающаяся стандартизацией в области смарт-карт, в июле 2022 года опубликовала документ со статусом Public Review, где предложила новый вариант протокола защищенного обмена сообщениями (ЗОС): SCP04.

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

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

Стандарты GlobalPlatform широко применяются, например, в области платежных карт. На них опирается свод стандартов платежных систем EMV, дублируя их описание, что подтверждается спецификацией «EMV Card Personalisation Specification».

Введение

В 1996 году производитель смарт-карт Schlumberger впервые представил смарт-карту с поддержкой технологии Java. Эта первая реализация была со значительными упрощениями и ограничениями, но тем не менее вызвала огромный интерес, потому что предоставила возможность вовлечь в процесс разработки широкие массы программистов и повысить динамичность внедрения новых продуктов.

Замечание. Подразделение Schlumberger, занимающееся смарт-картами, позднее отделилось от головного предприятия под названием Axalto, а спустя некоторое время после слияния с Gemplus появилось Gemalto. Сегодня Gemalto — часть французского концерна Thales.

В 1998 году VISA издала спецификацию Open Platform, чтобы подробно описать способы загрузки приложений в Java-карты. Чуть позднее VISA передала эту спецификацию в только что созданное объединение ведущих участников рынка смарт-карт под названием GlobalPlatform. С тех пор спецификация GlobalPlatform для карт претерпела множество изменений, но общая архитектура осталась прежней.

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

Со временем GlobalPlatform расширил сферу своего влияния с карт на более широкий класс устройств, акцентируя внимание на их архитектуре и безопасности взаимодействия друг с другом.

Далее ограничимся обсуждением только GlobalPlatform Card Specification (GPCS). В этом документе и его дополнениях описан, в частности, механизм защищенного обмена данными между картой и терминалом (off-card entity), который называется Secure Channel Protocol (SCP). Суть механизма заключается в том, что сначала выполняется взаимная аутентификация карты с терминалом и согласование общих сеансовых ключей, а далее с их использованием защищается последующий обмен данными с помощью шифрования APDU и кода аутентификации сообщения (MAC). Причем со стороны самой карты это реализовано так, что все криптографические вычисления и упаковку/распаковку команд/ответов выполняет ОС карты (Card Manager или Issuer Domain, если точнее), а приложение в виде java апплета посредством специального API просто пользуется услугами ОС для организации работы SCP и всех сопутствующих вычислений. В этом случае SCP для апплета становится прозрачным и простым в применении.

Протоколы

В документе GPCS, Version 2.0.1 от 2000 года (на титуле еще можно прочесть подзаголовок «Open Platform») протокол SCP01 еще не назван первым, потому что он единственный.

В ОС карты изначально есть особое привилегированное приложение, через которое осуществляется управление всей картой и её содержанием: Card Manager. В нем обязательно хранятся постоянные криптографических ключи, сгруппированные по три. Каждая такая группа названа key set, а в каждом key set’е содержатся три функционально разных ключа:

K_ENC — ключ шифрования; из него вырабатывается сеансовый ключ шифрования и выработки криптограмм;
K_MAC — ключ вычислений MAC; из него вырабатывается сеансовый ключ для вычисления MAC;
K_KEK (Key Encryption Key) — ключ шифрования ключей; используется для специфических целей управления ключами Card Manager в рамках текущего защищенного сеанса.

В SCP01 базовый алгоритм — 3DES с двойным ключом, и все ключи — длиной 16 байт. В самом начале ЗОС указывается номер key set’а, с использованием которого далее будут выполнены все вычисления.

Для выполнения взаимной аутентификации терминал и карта обмениваются случайными числами (host_challenge и card_challenge), на основе которых вырабатываются как общие сеансовые ключи K_enc и K_mac, так и криптограммы (card_cryptogram и host_cryptogram). Далее, после успешной взаимной проверки криптограмм терминал выбирает подходящий уровень защиты канала (security level):

все APDU команды передаются в открытом виде;
защищаются только APDU команды с помощью MAC на ключе K_mac;
защищаются только APDU команды шифрованием на K_enc и вычисление MAC на K_mac.

Если необходимо зашифровать данные APDU команд, то эти данные зашифровываются с помощью 3DES в режиме CBC, а MAC вычисляется как последний блок при шифровании 3DES в режиме CBC.

Ответы передаются всегда в открытом незащищенном виде.

В настоящее время, пожалуй, самый распространенный протокол — это SCP02, хотя в GPCS v2.3.1 он помечен как устаревший. Главные изменения в SCP02 по сравнению с SCP01:

Изменилась функция диверсификации сеансовых ключей: 3DES/CBC вместо 3DES/ECB ранее. Она существенно зависит от значения счетчика из памяти карты и табличной константы, но не от случайных чисел. Новая схема диверсификации позволяет выработать четыре различных сеансовых ключа из трех постоянных, даже если постоянные ключи совпадут:
1. K_enc из K_ENC для шифрования данных APDU,
2. K_c_mac из K_MAC для защиты APDU команд,
3. K_r_mac из K_MAC для защиты APDU ответов
4. K_dek из K_DEK.
  В SCP01 вычислялось только два сеансовых ключа: K_enc, K_mac. Ключ K_KEK использовался без диверсификации
Введены в оборот два новых сеансовых ключа: K_r_mac и K_dek. Задача K_r_mac — обеспечить защиту APDU ответов с помощью MAC. Применение третьего статического ключа расширено по сравнению с SCP01, поэтому он переименован из K_KEK в K_DEK (Data Encryption Key). Теперь кроме обмена ключевой информацией можно предавать в приложение зашифрованные данные в виде команды STORE DATA.
Алгоритм вычислений MAC сменился на т.н. Retail-MAC (одинарный DES в режиме CBC + последний блок на 3DES).
Увеличилось число уровней защиты канала:
1. открытый режим;
2. MAC только для команд;
3. шифрование и MAC только для команд;
4. MAC для команд и ответов;
5. шифрование для команд и MAC для команд и ответов.
Если текущий уровень защиты канала подразумевает ответы в незащищенном виде, то с помощью команды BEGIN R-MAC SESSION можно временно повысить уровень защиты канала и заставить карту вычислять МАС для ответов, а потом отключить эту опцию командой END R-MAC SESSION.

Шифрование данных, как и в прежнем протоколе, возможно только для команд APDU, но не ответов.

Поскольку DES не дает прежних гарантий стойкости, его постепенно по мере создания новых продуктов заменяют более стойкими алгоритмами шифрования. Главной задачей SCP03 является внедрение AES. Теперь в Card Manager должны храниться постоянные ключи AES одной из трех возможных длин: 128 бит, 192 бита, 256 бит. Кроме этого в SCP03:

Схема диверсификации изменилась и получила более широкое применение. В её основе используется функция KDF из NIST 800-108 с AES-CMAC в роли псевдослучайной функции. Во-первых, новая схема позволяет диверсифицировать сеансовые ключи с учетом их длины. Во-вторых, обе криптограммы взаимной аутентификации (card_cryptogram и host_cryptogram) теперь вычисляются также с помощью новой схемы диверсификации. Все вычисляемые величины существенно зависят и от табличной константы, и от значений случайных чисел host_challenge и card_challenge.
Состав сеансовых ключей остался прежним, но изменилось применение ключа K_enc. С помощью него теперь шифруются данные не только APDU команд, но и ответов. Теперь для защиты APDU команды используются сеансовые ключи K_enc и K_c_mac, а для защиты ответа — K_enc и K_r_mac.
MAC вычисляется с помощью AES-CMAC (алгоритм описан в NIST 800-38B), а шифрование выполняется с помощью AES-CBC.
Самый высокий уровень защиты канала (security level) теперь подразумевает шифрование и вычисление MAC как для APDU команд, так и ответов.
Команда BEGIN R-MAC SESSION позволяет на карте не только вычислять MAC для ответов, но и шифровать данные, а команда END R-MAC SESSION обеспечит возврат к базовому уровню защиты канала.

В июле 2022 года вышло описание SCP04 в виде «Card Specification v2.3 – Amendment K» со статусом Public Review. GlobalPlatform настроен сделать новый протокол универсальным и максимально гибким. Главная идея — модульность, обеспечивающая чтобы, допустим, появление нового криптографического алгоритма или режима не приводило к необходимости создания нового протокола, а становилось бы опцией, расширяющей возможности уже работающего механизма. Протокол представляется как набор следующих основных криптографических функций:

Диверсификация данных (Data Derivation Protocol Function)
Вычисление MAC (Message Authentication Code Protocol Function)
Обновление ключей (Rekeying Protocol Function)
Шифрование (Cipher Protocol Function)
ДСЧ (Random Number Generation Protocol Function)

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

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

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

Новая для GP особенность — обновление ключей (rekeying). Предполагается, что можно будет задать некий дополнительный алгоритм, который должен оценивать нагрузку на сеансовые ключи и периодически их менять при достижении пороговых значений нагрузки. Пока что реализации никакой не предложено, видимо, это задумка на будущее.

Базовые алгоритмы протокола — AES, AES-GCM, SM4. Для них уже предопределены три возможные конфигурации. Например, конфигурация для AES в целом повторяет SCP03. Получается, реализовав в своих продуктах SCP03, можно достаточно быстро представить реализацию SCP04 в минимальном варианте.

Видно, что организация GP постоянно совершенствует механизмы защиты обмена данными терминала с картой и пытается соответствовать современным тенденциям, оставаясь в рамках архитектуры карты, выбранной более 20 лет назад. Интересно, с какой интенсивностью и в каком объеме производители смарт-карт будут внедрять новые протоколы.

Таблица 1. Сравнение основных свойств протоколов ЗОС

Таблица 2. Сравнение схем диверсификации

Источники:

Протоколы защищенного обмена сообщениями и новинка от GlobalPlatform