Таблица 52 - Явная аутентификация ключа – ответ


Параметры отклика

Значение

Поле данных

'7C' L7C

        '86' L86 < MAC[KMAC] (PuK. IFD. DH2) >

        [ ||         '87' L87 <Ссылка на сертификационный центр CAR1>
|| '88' L88 <Ссылка на сертификационный центр CAR2>] (CONDITIONAL)
CAR1 и CAR2 возвращаются, только если CHAT предоставляет соответствующую информацию.
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