Статус документа
Статус документа

ГОСТ Р ИСО/МЭК 7816-4-2004 Информационная технология (ИТ). Карты идентификационные. Карты на интегральных схемах с контактами. Часть 4. Межотраслевые команды для обмена

     5.7 Влияние безопасного обмена сообщениями на структуры APDU-сообщений


Структуры APDU-сообщений установлены в 5.3. В соответствии с 5.3.1 командный APDU состоит из обязательного заголовка команды из четырех байтов, за которым условно следует тело команды (см. рисунки 3 и 4); декодирование тела команды установлено в 5.3.2 (см. рисунок 5 и таблицу 5). В соответствии с 5.3.3 ответный APDU состоит из условного тела ответа, за которым следует обязательный завершитель ответа из двух байтов (см. рисунок 6). На рисунке 8 представлены структуры APDU-сообщений.


Рисунок 8 - Структуры APDU-сообщений



Раздел 6 устанавливает APDU-команды и APDU-ответы для основных межотраслевых команд. Раздел 7 устанавливает APDU-команды и APDU-ответы для межотраслевых команд, ориентированных на передачу данных. Разделы 6 и 7 не описывают влияние безопасного обмена сообщениями (см. 5.6) на структуры APDU-сообщений. Поэтому семантические значения полей длины и полей данных в разделах 6 и 7 кажутся противоречащими их синтаксическим значениям в 5.3.

Настоящий подраздел определяет влияние безопасного обмена сообщениями, установленного в 5.6, на структуры APDU-сообщений, установленные в 5.3, с тем чтобы избежать вышеупомянутого возможного неправильного понимания.

Для обеспечения защиты APDU-команды, где байт CLA имеет определенное значение, соответствующее таблице 9, а именно '0Х', '8Х', '9Х' или 'АХ', бит b4 в байте CLA должен быть установлен в единицу, что обозначено CLA* на рисунке 9 и в приложении Е; если тело команды присутствует, оно должно быть декодируемым в соответствии с 5.3.2 и инкапсулировано следующим образом.

При наличии поля данных перенос байтов данных должен осуществляться:

- либо посредством информационного объекта с незашифрованным значением (тег равен '80', '81', 'В2', 'ВЗ', см. таблицу 19);

- либо посредством информационного объекта для конфиденциальности (тег со значением от '84' до '87', см. таблицу 22).

При наличии поля перенос значения должен осуществляться посредством информационного объекта, представляющего (тег равен '96' или '97', см. таблицу 19); его поле значения кодирует положительное целое число без знака в одном или двух байтах; нулевое значение и пустой информационный объект означают максимум.

Аналогично ответный APDU должен быть инкапсулирован следующим образом.

При наличии поля данных перенос байтов данных должен осуществляться:

- либо посредством информационного объекта с незашифрованным значением (тег равен '80', '81', 'В2', 'В3', см. таблицу 19);

- либо посредством информационного объекта для конфиденциальности (тег со значением от '84' до '87', см. таблицу 22).

При необходимости перенос завершителя ответа должен осуществляться посредством информационного объекта, представляющего информацию о состоянии (тег равен '99', см. таблицу 19); пустой информационный объект означает, что последовательность байтов SW1-SW2='9000'.

На рисунке 9 представлены структуры защищенных APDU-сообщений, при этом:

- каждое новое поле данных может нести дополнительные информационные объекты, связанные с SM, например в конце - криптографическую контрольную сумму (тег равен '8Е'). В приложении Е приведены примеры для иллюстрации;

- новое поле дает длину нового поля данных защищенного командного APDU;

- новое поле должно быть пустым, если не ожидается поле данных в защищенном ответном APDU; в противном случае оно должно содержать только нули;

- новый завершитель ответа кодирует состояние принимающей стороны после обработки защищенной команды. Для защиты он может быть инкапсулирован.

 Примечания

1 Длина от 1 до 127 кодируется в поле длины информационных объектов BER-TLV также как в полях длины APDU-сообщений. Для длины 128 и более способы кодирования различаются.

2 Как указано выше, в новых полях данных могут быть представлены дополнительные (дальнейшие) или другие информационные объекты, связанные с SM.

3 При безопасном обмене сообщениями не всегда выявляется, имеют ли данные, подлежащие защите, структуру BER-TLV. В таких случаях рекомендуются теги '80', '81', '86' и '87'.