Таблица 52 - Явная аутентификация ключа – ответ
Параметры отклика | Значение |
Поле данных | '7C' L7C '86' L86 < MAC[KMAC] (PuK. IFD. DH2) > [ || '87' L87 <Ссылка на сертификационный центр CAR1> |
SW1-SW2 | Согласно ISO/IEC 7816‑4 |
Объекты данных DO '87', '88' обусловлены наличием объекта данных CHAT с тегом «7F 4C» (см. EN 419212-3, раздел 5.8.7) и вторым доверительным якорем.
Вычисление маркеров аутентификации MAC [KMAC] (PuK. IC C. DH2) и MAC [KMAC] (PuK. IFD. DH2) указано в разделе 11.5.
9 Безопасная передача сообщений
9.1 Общие положения
После успешного завершения аутентификации устройства команды и ответы передаются в режиме SM, как указано условиями доступа. Выведенные или согласованные симметричные ключи будут использоваться для защиты целостности и / или конфиденциальности информации, передаваемой по интерфейсу во внешний мир, или наоборот.
Обычно безопасный обмен сообщениями обеспечивается с помощью симметричных ключей сеанса, полученных из предыдущих шагов аутентификации. Результатами аутентификации являются сеансовые ключи для TDES [26] или AES [25], построенные, например, согласно EN 419212-3, раздел 3.10.
Статический SM - это еще один вариант, используя симметричный ключ, зарезервированный для безопасного обмена сообщениями. В случае статического SM ключи всегда доступны в ICC. Поэтому не требуется ключевой метод соглашения/деривации. Статический SM выходит за рамки настоящего стандарта.
При использовании Secure Messaging формат обычного текстового сообщения будет изменяться в соответствии с определениями в ISO/IEC 7816 4, когда он передается с защищенным сообщением.
Политика SM для входящих данных и исходящих данных должна быть одинаковой, т. Е. Если ICC требует, чтобы команда APDU была зашифрована, ICC также должен шифровать APDU ответа.
9.2. Байт CLA
Наличие защищенных сообщений указано в b3 и b4 байта CLA команды APDU. Согласно ISO / IEC 7816 4, 5.4.1 биты b3 и b4 устанавливаются в 1, указывая, что заголовок команды включен в аутентификацию сообщения.
Использование логических каналов с 4 по 19 с безопасным обменом сообщениями требует дополнительных механизмов, как описано в ИСО / МЭК 7816 4. Описание этих механизмов не выходит за рамки настоящего стандарта.
9.3. Кодирование TLV команд и ответных сообщений
Если применяется защищенная связь, команда и ответное сообщение должны быть закодированы в соответствии с ISO / IEC 7816 4, глава 10.
Для идентификации криптограммы определены два тега. Один для четных кодов команд ('87'), а другой для кодов нечетных команд ('85'), где данные отправляются в BER-TLV.
Для определения простого значения определены два тега. Один для четных кодов команд ('81'), а другой для нечетных кодов команд ('B3'), где данные отправляются в BER-TLV.
Таблица 53 - Объекты данных SM
Метка | Значение | Имя |
'81' | Обычное значение (для защиты CC) | Tpl |
'87' | Байт индикатора содержимого ('01' для ISO-Padding), за которым следует криптограмма | Tcg |
'85' | Криптограмма (равное значение в BER-TLV, но не включая объект данных SM). | Tcg |
'8E' | Криптографическая контрольная сумма (MAC) | Tcc |
'97' | Le (для защиты CC) | Tle |
'99' | Статус обработки (SW1-SW2, защищенный MAC) | Tsw |
'B3' | Обычное значение, закодированное в BER-TLV, но не включающее объекты данных SM | Tpv |
На четных кодах INS индикатор заполнения PI всегда устанавливается на «01», то есть заполнение в соотв. к ISO / IEC 7816 4 ('80 ... 00 '). PI отправляется как первый байт, за которым следует криптограмма в DO '87'.
При нечетных кодах INS в DO '85' не передается индикатор заполнения.
Криптографическая контрольная сумма должна включать любой объект данных защищенного обмена сообщениями, имеющий номер нечетного тега.
9.4. Обработка SM-ошибок
EN 419212-3, в разделе 3.13 описаны критерии, относящиеся к прерыванию текущей сессии. Здесь описаны условия, относящиеся к аборту из-за неправильного SM.
Когда ICC распознает ошибку SM при интерпретации команды, тогда байты состояния возвращаются без SM. В ISO / IEC 7816 4 для определения ошибок SM определены следующие байты состояния:
'6987': Отсутствуют ожидаемые объекты данных SM;
'6988': объекты данных SM неверны.
ПРИМЕЧАНИЕ. Другие байты состояния SM могут встречаться в конкретных контекстах приложения.
9.5 Заполнение для расчета контрольной суммы
Механизм прокладки в соотв. к ISO / IEC 7816 4 ('80 ... 00 ').
9.6 Счетчик последовательности отправки (SSC)
Счетчик Send Sequence Counter - это номер, который инициализируется сразу после успешной аутентификации устройства.
Счетчик последовательности отправки SSC должен увеличиваться (+1) каждый раз перед отправкой APDU с помощью Secure Messaging. Этот (приращенный) SSC затем применяется к ENC (если применимо) и MAC APDU, то есть если начальное значение равно x, в следующей команде значение SSC равно x + 1. Значением SSC первого ответа является x + 2.
9.7 Структура сообщений APDU Secure Messaging
9.7.1 Криптограммы
Криптограммы построены с симметричным алгоритмом (TDES или AES) в режиме CBC с вектором Null или зашифрованным счетчиком последовательности отправки (SSC) в качестве начального цепочки. Длина этого блока соответствует размеру блока алгоритма [33].
Криптограмма (Tag = '87' или '85') всегда связывает криптографическую контрольную сумму с тегом = '8E'. Сначала шифрование должно выполняться с данными, а затем вычислять криптографическую контрольную сумму по зашифрованным данным. Этот порядок соответствует ISO / IEC 7816 4 и имеет последствия для безопасности, как описано в [10].
В случае четного кода команды:
- Индикатор заполнения должен быть PI = '01' (т. Е. Алгоритм CBC и padding = '80 ... 00 ').
В случае нечетного кода команды:
- Механизм криптограммы по умолчанию такой же, как механизм криптограммы, используемый в случае четного кода команды (т. Е. Алгоритм CBC и padding = '80 ... 00 '), но не используется индикатор заполнения.
Фактическое значение Lc будет изменено на Lc 'после применения безопасного обмена сообщениями.
На следующем рисунке показан пример безопасного обмена сообщениями при использовании шифрования TDES. В этом случае SSC не используется.

Рисунок 8 - Пример вычисления CG (даже INS) с использованием TDES в команде APDU без SSC

Рисунок 9 - Пример для команды шифрования данных APDU (даже INS) с использованием AES без SSC (CBC-Mode)
Header – заголовок
Data – данные
Incorning Data - Неверные данные
Bytes – байты
Encrypted Formated Block (EDFB) Зашифрованный сформированный блок (EDFB)
47
EN 419212-2:2017 (E)

Рисунок 10 - Пример для шифрования данных APDU (даже INS) с использованием AES с SSC (CBC-Mode)
Header – заголовок
Data – данные
Constant –Постоянная
Padding – Набивка
Data subject cryptographic checksum (retail MAC calculation) - Криптографическая контрольная сумма данных субъекта (расчет розничного МАС)
cryptographic checksum - криптографическая контрольная сумма
Value –Значение
Incrypt – зашифровывать
Decrypt - расшифровывать
Incorning Data - Неверные данные
Bytes – байты
cryptographic checksum Formated Block (EDFB) - Криптографическая контрольная сумма Отформатированный блок
9.7.2 Криптографические контрольные суммы
Заголовок команды должен быть включен в криптографическую контрольную сумму. n
Часть данных разделяется на блоки данных по каждой из длины <размер блока блока>.
СCH Заголовок команды (CLA * INS P1 P2)
где байт CLA * указывает на использование безопасного обмена сообщениями (SM).
PB Набивка данных ('80 00 ... 00 ') заполняется до следующего <размера блока алгоритма>
объекты данных, включенные в расчет ЦК, зависят от случая команды
Случай 1 CH || PB
Случай 2 CH || PB || DO (Le) || PB
Случай 3 CH || PB || DO (CG) || PB
Случай 4 CH || PB || DO (CG) || DO (Le) || PB
Для ответов SM данные, охватываемые CC:
Случай 1 + 3 DO (SW) || PB
Случай 2 + 4 DO (CG) || DO (SW) || PB
CC всегда имеет размер <размер блока алгоритма>. Количество передаваемых байтов может варьироваться от 8 до <размер блока блока> крайние левые байты CC.
Для использования алгоритма TDES и AES см. 9.9 «Использование TDES и AES».

Рисунок 11 - Пример для команды APDU-вычисления криптографической контрольной суммы TDES с SSC
Второй подраздел K2 CMAC не используется, поскольку данные всегда заполняются размером блока алгоритма перед вызовом CMAC.
Header – заголовок
Data – данные
Constant –Постоянная
Padding – Набивка
Data subject cryptographic checksum (retail MAC calculation) - Криптографическая контрольная сумма данных субъекта (расчет розничного МАС)
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |


