ГОСТ Р ИСО/МЭК 7816-4-2013. Национальный стандарт Российской Федерации. Карты идентификационные. Карты на интегральных схемах. Часть 4. Организация, защита и команды для обмена

(утв. и введен в действие Приказом Росстандарта от 22.11.2013 № 1630-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р ИСО/МЭК 7816-4-2004"]:::rst
  click n0 "https://bukva.ai/docs/ukazanie-ukazaniya-muk-4-1-1625-03" "ГОСТ Р ИСО/МЭК 7816-4-2004. Национальный стандарт Российской Федерации. Информационная технология. Карты идентификационные. Карты на интегральных схемах с контактами. Часть 4... (п"
  n1["ГОСТ Р ИСО/МЭК 7816-4-2013"]:::doc
  click n1 "https://bukva.ai/docs/standart-gost-r-isomek-7816-4-2013" "ГОСТ Р ИСО/МЭК 7816-4-2013. Национальный стандарт Российской Федерации. Карты идентификационные. Карты на интегральных схемах. Часть 4. Организация, защита и команды для обмена (ут"
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 22 ноября 2013 г. № 1630-ст

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

КАРТЫ ИДЕНТИФИКАЦИОННЫЕ

КАРТЫ НА ИНТЕГРАЛЬНЫХ СХЕМАХ

ЧАСТЬ 4

ОРГАНИЗАЦИЯ, ЗАЩИТА И КОМАНДЫ ДЛЯ ОБМЕНА

Identification cards. Integrated circuit cards. Part 4. Organization, security and commands for interchange

ISO/IEC 7816-4:2005 Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange (IDT)

ГОСТ Р ИСО/МЭК 7816-4-2013

Группа Э46

ОКС 35.240.15 ОКП 40 8470

Дата введения 1 января 2015 года

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ) и Техническим комитетом по стандартизации ТК 22 «Информационные технологии» на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 22 ноября 2013 г. № 1630-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 7816-4:2005 «Карты идентификационные. Карты на интегральных схемах. Часть 4. Организация, защита и команды для обмена» (ISO/IEC 7816-4:2005 «Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange»), включая изменение A1:2008, которое выделено в тексте одинарной линией.

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВЗАМЕН ГОСТ Р ИСО МЭК 7816-4-2004

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. Международная организация по стандартизации (ИСО) и Международная электротехническая комиссия (МЭК) не несут ответственности за идентификацию подобных патентных прав

Правила применения настоящего стандарта установлены в ГОСТ 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в годовом (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячно издаваемом информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте национального органа Российской Федерации по стандартизации в сети Интернет (gost.ru).

Введение

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

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

Пять стандартов из серии ИСО/МЭК 7816 относятся к картам с гальваническими контактами, а три из них определяют электрический интерфейс:

ИСО/МЭК 7816-1 — определяет физические характеристики карт с контактами;

ИСО/МЭК 7816-2 — определяет размеры и расположение контактов;

ИСО/МЭК 7816-3 — определяет электрический интерфейс и протоколы передачи для асинхронных карт;

ИСО/МЭК 7816-10 — определяет электрический интерфейс и ответ на восстановление для синхронных карт;

ИСО/МЭК 7816-12 — определяет электрический интерфейс и рабочие процедуры для USB карт.

Все остальные стандарты не зависят от технологии физического интерфейса. Они применяются к картам, имеющим доступ при помощи контактов и/или радиочастоты:

ИСО/МЭК 7816-4 — определяет организацию, защиту и команды для обмена информацией;

ИСО/МЭК 7816-5 — определяет регистрацию провайдеров прикладных программ;

ИСО/МЭК 7816-6 — определяет элементы данных для межотраслевого обмена;

ИСО/МЭК 7816-7 — определяет команды языка структурированных запросов для карты;

ИСО/МЭК 7816-8 — определяет команды, обеспечивающие операции по защите информации;

ИСО/МЭК 7816-9 — определяет команды для управления картами;

ИСО/МЭК 7816-11 — определяет верификацию личности биометрическими методами;

ИСО/МЭК 7816-13 — определяет команды для управления приложением в мульти-прикладной среде.

ИСО/МЭК 7816-15 — определяет приложение с криптографической информацией.

ИСО/МЭК 10536 [13] определяет доступ при помощи поверхностного действия. ИСО/МЭК 14443 [15] и ИСО/МЭК 15693 [17] определяют радиочастотный доступ. Такие карты известны также как бесконтактные карты.

ИСО и МЭК обращают внимание на заявление о том, что соответствие настоящему стандарту может включать использование следующих патентов и иностранных эквивалентов:

JPN 2033906 Portable electronic device;

JPN 2557838 Integrated circuit card;

JPN 2537199 Integrated circuit card;

JPN 2856393 Portable electronic device;

JPN 2137026 Portable electronic device;

JPN 2831660 Portable electronic device;

DE 198 55 596 Portable microprocessor-assisted data carrier that can be used with or without contacts.

ИСО и МЭК не занимают никакой позиции относительно наличия, действительности и области применения данных патентных прав.

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

Международный стандарт ИСО/МЭК 7816-4 подготовлен подкомитетом № 17 «Карты и идентификация личности» совместного технического комитета № 1 ИСО/МЭК «Информационные технологии» (ISO/IEC JTC 1/SC 17).

1 Область применения

Настоящий стандарт устанавливает:

• содержание пар команда-ответ, передаваемых между устройством сопряжения и картой;
• средства извлечения элементов данных и информационных объектов из карты;
• структуры и содержание байтов предыстории для описания рабочих характеристик карт;
• структуры для приложений и данных в карте, прослеживаемые на стыке между картой и устройством сопряжения при обработке команд;
• методы доступа к файлам и данным, содержащимся в карте;
• архитектуру безопасности, определяющую права доступа к файлам и данным, содержащимся в карте;
• средства и механизмы для идентификации и способов адресации приложений, содержащихся в карте;
• методы безопасного обмена сообщениями;
• методы доступа к алгоритмам, обрабатываемым картой (исключая описание самих алгоритмов);

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

Настоящий стандарт не зависит от технологии физического сопряжения. Он применяется к картам, имеющим доступ при помощи одного или нескольких следующих методов: контактов, поверхностного действия и радиочастоты.

2 Нормативные ссылки

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

ИСО/МЭК 7816-3 карты идентификационные. Карты на интегральных схемах. Часть 3. Карты с контактами. Электрический интерфейс и протоколы передачи (ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols»).

ИСО/МЭК 7816-6 карты идентификационные. Карты на интегральных схемах. Часть 6. Межотраслевые элементы данных для обмена информацией (ISO/IEC 7816-6, Identification cards — Integrated circuit cards — Part 6: Interindustry data elements for interchange).

ИСО/МЭК 8825-1:2002 <1> Информационная технология. Правила кодирования АСН.1. Часть 1 Спецификация базовых (BER), канонических (CER) и отличительных (DER) правил кодирования (ISO/IEC 8825-1:2002, Information technology — ASN.1 encoding rules. Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER))

<1> Заменен на ИСО/МЭК 8825-1:2008.

3 Термины и определения

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

3.1 правило доступа (access rule): Элемент данных, который содержит метод доступа, связанный с действием, и условия секретности, которым необходимо соответствовать перед началом действия.

3.2 файл Ответа-на-Восстановление (Answer-to-Reset file): Дополнительный EF, который указывает рабочие характеристики карты.

3.3 приложение (application): Структуры, элементы данных и программные модули, необходимые для выполнения определенных функций.

3.4 DF приложения (application DF): Структура, принимающая приложение в карте.

3.5 идентификатор приложения (application identifier): Элемент данных (до шестнадцати байт), который идентифицирует приложение.

3.6 метка приложения (application label): Элемент данных для использования в человеко-машинном интерфейсе.

3.7 провайдер приложения (application provider): Организация, предоставляющая компоненты, которые составляют приложение в карте.

3.8 шаблон приложения (application template): Множество информационных объектов, относящихся к приложению и включающих один информационный объект «идентификатор приложения».

3.9 асимметричный криптографический метод (asymmetric cryptographic technique): Метод криптографии, который использует две взаимосвязанные операции: открытую операцию, определенную открытым числом или открытым ключом, и приватную операцию, определенную приватным числом или приватным ключом (две операции обладают таким свойством, что при наличии открытой операции вычислительно невозможно определить приватную операцию).

3.10 сертификат (certificate): Цифровая подпись, связывающая конкретного человека или объект с его соответствующим открытым ключом (организация, выдающая сертификат, также действует в качестве органа, распределяющего теги для элементов данных в сертификате).

3.11 пара команда-ответ (command-response pair): Набор из двух сообщений на стыке сопряжения: командного APDU и следующего за ним ответного APDU в противоположном направлении.

3.12 элемент данных (data element): Смысловой элемент информации, прослеживаемый на стыке между картой и устройством сопряжения, для которого определены наименование, описание логического содержания, формат и кодирование.

3.13 информационный объект (data object): Информация, прослеживаемая на стыке между картой и устройством сопряжения, состоящая из сцепления обязательного поля тега, обязательного поля длины и условного поля значения.

3.14 единица данных (data unit): Наименьший набор битов, на который можно дать однозначную ссылку в пределах EF, поддерживающего единицу данных.

3.15 назначенный файл (dedicated file): Структура, содержащая контрольную информацию файла и, возможно, свободную память для распределения.

3.16 имя DF (DF name): Элемент данных (до шестнадцати битов), который уникальным образом идентифицирует DF в карте.

3.17 цифровая подпись (digital signature): Присоединенные данные или криптографически преобразованные данные, позволяющие получателю данных подтвердить источник и целостность данных и защитить их от подделки, например получателем.

3.18 справочный файл (directory file): Дополнительный EF, содержащий список приложений, поддерживаемых картой, и дополнительно связанные элементы данных.

3.19 элементарный файл (elementary file): Набор единиц данных или записей, или информационных объектов, которые совместно используют один и тот же идентификатор файла и один(ни) и тот (те) же атрибут(ы) секретности.

3.20 файл (file): Структура для приложения и/или для данных, имеющихся в карте, прослеживаемая на стыке между картой и устройством сопряжения при обработке команд.

3.21 идентификатор файла (file identifier): Элемент данных (двухбайтовый), используемый для обращения к файлу.

3.22 список заголовков (header list): Сцепление пар полей тегов и полей длины без разграничения.

3.23 идентификационная карта (identification card): Карта, которая содержит данные о ее держателе и эмитенте и может содержать сведения, необходимые в качестве входных данных для применения карты в соответствии с ее назначением и выполнения основанных на них транзакций.

[ИСО/МЭК 7810 [2]]

3.24 внутренний элементарный файл (internal elementary file): EF для хранения данных, интерпретируемых картой.

3.25 ключ (key): Последовательность символов управления криптографической операцией (например, операциями шифрования и дешифрования, приватной или открытой операциями в динамической аутентификации, получением подписи, верификацией подписи).

3.26 главный файл (masterfile): Уникальный DF, представляющий собой корень файловой структуры в карте, использующей иерархию файлов DF.

3.27 смещение (offset): Число последовательных обращений к единице данных в EF, который поддерживает эту единицу данных, или байт при записи.

3.28 родительский файл (parent file): DF, непосредственно предшествующий заданному файлу в пределах иерархии файлов DF.

3.29 пароль (password): Данные, которые могут быть затребованы приложением от пользователя карты для аутентификации.

3.30 путь (path): Сцепление идентификаторов файлов без разграничения.

3.31 приватный ключ (private key): Ключ субъекта пары асимметричных ключей, который может использовать только этот субъект.

[ИСО/МЭК 9798-1 [8]]

3.32 провайдер (provider): Орган, имеющий или получивший право на создание DF в карте.

3.33 открытый ключ (public key): Ключ субъекта пары асимметричных ключей, который может быть сделан общедоступным.

[ИСО/МЭК 9798-1 [8]]

3.34 запись (record): Строка байтов, к которой карта обращается и которую карта обрабатывает в пределах EF, поддерживающего запись.

3.35 идентификатор записи (record identifier): Числовое значение, используемое для обращения к одной или более записей в пределах EF, поддерживающего запись.

3.36 номер записи (record number): Порядковый номер, который однозначно идентифицирует каждую запись в пределах EF, поддерживающего запись.

3.37 зарегистрированный идентификатор провайдера приложения (registered application provider identifier): Элемент данных (из пяти байтов), который однозначно идентифицирует провайдер приложения.

3.38 секретный ключ (secret key): Ключ, используемый в методах симметричной криптографии при помощи установки определенных объектов.

[ИСО/МЭК 11770-3 [14]]

3.39 безопасный обмен сообщениями (secure messaging): Совокупность методов для криптографической защиты [частей] пары команда-ответ.

3.40 атрибут секретности (security attribute): Условие использования объектов, имеющихся в карте, включающих записанные данные и функции обработки данных, выраженные как элемент данных, содержащий одно или несколько правил доступа.

3.41 безопасная среда (security environment): Совокупность компонентов, необходимых для приложения в карте, для обеспечения безопасного обмена сообщениями или для операций по защите.

3.42 асимметричный криптографический метод (asymmetric cryptographic technique): Криптографический метод, который использует один и тот же секретный ключ, как для операций отправителя, так и для операций получателя (без секретного ключа невозможно путем вычислений определить обе операции).

3.43 список тегов (tag list): Сцепление полей тегов без разграничения.

3.44 шаблон (template): Множество информационных объектов BER-TLV для формирования поля значения составного информационного объекта BER-TLV.

3.45 рабочий элементарный файл (working elementary file): EF для хранения данных, не интерпретируемых картой.

4 Сокращения и обозначения

В настоящем стандарте применены следующие сокращения.

AID — идентификатор приложения (application identifier);

APDU — блок данных прикладного протокола (application protocol data unit));

ARR — указатель правила доступа (access rule reference);

ASN.1 — абстрактно-синтаксическая нотация версии 1 (abstract syntax notation one) (см. ИСО/МЭК 8825-1);

AT — шаблон управляющих ссылок аутентификации (control reference template for authentication);

ATR — Ответ-на-Восстановление (Answer-to-Reset);

BER — базовые правила кодирования абстрактно-синтаксической нотации версии 1 (АСН.1) (basic encoding rules of ASN.1) (см. ИСО/МЭК 8825-1);

CCT — шаблон управляющих ссылок «криптографическая контрольная сумма» (control reference template for cryptographic checksum);

CLA — байт класса (class byte);

CRT — шаблон управляющих ссылок (control reference template);

CT — шаблон управляющих ссылок конфиденциальности (control reference template for confidentiality);

DF — назначенный файл (dedicated file);

DIR — директория (directory);

DST — шаблон управляющих ссылок цифровой подписи (control reference template for digital signature);

EF — элементарный файл (elementary file);

EF.ARR — файл указателя правил доступа (access rule reference file);

EF.ATR — файл Ответа-на-Восстановление (Answer-to-Reset file);

EF.DIR — справочный файл (directory file);

FCI — контрольная информация файла (file control information);

FCP — контрольный параметр файла (file control parameter);

FMD — данные управления файлом (file management data);

HT — шаблон управляющих ссылок хэш-кода (control reference template for hash-code);

INS — командный байт (instruction byte);

KAT — шаблон управляющих ссылок для согласования ключей (control reference template for key agreement);

Lc field — поле Lc (поле длины для кодирования числа Nc);

LCS byte — байт состояния жизненного цикла (life cycle status byte);

Le field — поле Le (поле длины для кодирования числа Ne);

MF — главный файл (master file);

Nc — число байтов в поле данных команды;

Ne — максимальное число байтов, ожидаемое в поле данных ответа;

Nr — число байтов в поле данных ответа;

PIX — проприетарное расширение идентификатора приложения (proprietary application identifier extension);

P1-P2 — байты параметров (parameter bytes (указаны для ясности, тире не существенно));

RFU — зарезервировано для использования в будущем (reserved for future use);

RID — зарегистрированный идентификатор провайдера приложения (registered application provider identifier);

SC — условие секретности (security condition);

SCQL — язык структурированных запросов для карты (structured card query language);

SE — безопасная среда (security environment);

SEID byte — байт идентификатора безопасной среды (security environment identifier byte);

SM — безопасный обмен сообщениями (secure messaging);

SW1-SW2 — байты состояния (status bytes (указаны для ясности, тире не существенно));

(SW1-SW2) — значение сцепления байтов SW1 и SW2 (первый байт является старшим значащим байтом);

TLV — тег, длина, значение (tag, length, value);

{T-L-V} — информационный объект (указан для ясности, дефис и фигурные скобки не существенны);

'XX' — обозначение, использующее шестнадцатеричные цифры от '0' до '9' и от 'A' до 'F', равно XX по основанию 16.

5 Организация обмена информацией

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

1. Пары команда-ответ;

2. Информационные объекты;

3. Структуры для приложений и данных;

4. Архитектура безопасности.

5.1 Пары команда-ответ

В таблице 1 приведена пара команда-ответ, а именно командный APDU, за которым следует ответный APDU в противоположном направлении (см. ИСО/МЭК 7816-3). Чередования пары команды-ответа на стыке сопряжения не должно быть, т.е. ответный APDU должен быть получен до инициализации другой пары команды-ответа.

Таблица 1

Пара команда-ответ

В любой паре команда-ответ, включающей в себя и поле Le и поле Lc (см. ИСО/МЭК 7816-3), короткое и расширенное поля длины не должны складываться: либо оба поля длины короткие, либо оба поля длины расширенные.

Если в карте явно заявлена возможность обрабатывать «расширенные поля Lc и Le» (см. таблицу 88, третья таблица программных функций) в байтах предыстории (см. 8.1.1) или EF.ATR (см. 8.2.1.1), то карта обрабатывает короткое и расширенное поле длины. В противном случае (значение по умолчанию), карта работает только с короткими полями длины.

Nc обозначает число байтов в поле данных команды. Поле Lc кодирует Nc.

• Если поле Lc отсутствует, то Nc равно нулю;
• короткое поле Lc состоит из одного байта, которое отлично от '00' и принимает значения:
• от '01' до 'FF'. Этот байт кодирует Nc от одного до 255;
• Расширенное поле Le состоит из трех байтов: одного байта, установленного на '00', за которым следуют два байта, которые отличны от '0000', и принимают значения:
• от '0001' до 'FFFF'. Эти два байта кодируют Nc от одного до 65535.

Ne обозначает максимальное число байтов, ожидаемое в поле данных ответа. Поле Le кодирует Ne.

Если поле Le отсутствует, то Ne равно нулю;

короткое поле Le состоит из одного байта с произвольным значением:

от '01' до 'FF'. Этот байт кодирует Ne от одного до 255;

если этот байт установлен на '00', то Ne равно 256.

• Расширенное поле Le состоит либо из трех байтов (один байт установлен на '00', за которым следуют два байта с произвольным значением), если поле Le отсутствует, либо из двух байтов (с произвольным значением), если расширенное поле Le присутствует:
• от '0001' до 'FFFF'. Эти два байта кодируют Ne от одного до 65535;
• если два байта установлены на '0000', то Ne равно 65536.

Nr обозначает число байтов в поле данных ответа. Nr должно быть меньше или равно Ne. Поэтому в любой паре команда-ответ отсутствие поля Le является обычным способом получения поля данных без ответа. Если поле Le содержит только установленные на '00' байты, то значение Ne максимально, т.е. в пределах 256 для короткого поля Le или в пределах 65356 для расширенного поля Le, при этом все имеющиеся байты должны быть возвращены.

Если операция прерывается, то карта может стать невосприимчивой. Однако если возникает ответный APDU, то поле данных ответа должно отсутствовать и SW1-SW2 должны показывать ошибку.

P1-P2 указывают элементы управления и опции для обработки команд. Байт параметров, установленный на '00' обычно не обеспечивает дальнейшее уточнение. Других общих правил для кодирования байтов параметров не существует.

Ниже установлены общие правила для кодирования байта класса CLA (см. 5.1.1), командного байта INS (см. 5.1.2) и байтов состояний (см. 5.1.3). В этих байтах биты, зарезервированные для использования в будущем, должны быть установлены на 0, пока не будет определено иначе.

5.1.1 Байт класса

CLA указывает класс команды. С учетом требований, определенных в ИСО/МЭК 7816-3, значение 'FF' является недействительным. Бит 8 в CLA проводит различие между межотраслевым классом и проприетарным классом.

Бит 8, установленный на 0, указывает межотраслевой класс. Ниже определены значения 000x xxxx и 01xx xxxx. Значения 001x xxxx зарезервированы для использования в будущем ИСО/МЭК СТК 1/ПК 17.

В таблице 2 значения 000x xxxx определены как первые межотраслевые значения:

• Биты 8, 7 и 6 установлены на 000;
• Бит 5 управляет сцеплением команд (см. 5.1.1.1);
• Биты 4 и 3 указывают безопасный обмен сообщениями (см. 6);
• Биты 2 и 1 кодируют номер логического канала от нуля до трех (см. 5.1.1.2).

Таблица 2

Первые межотраслевые значения CLA

В таблице 3 значения 01xx xxxx определены как последующие межотраслевые значения:

• Биты 8 и 7 установлены на 01;
• Бит 6 указывает безопасный обмен сообщениями (см. 6);
• Бит 5 управляет сцеплением команд (см. 5.1.1.1);
• Биты с 4 по 1 кодируют число от нуля до пятнадцати; данное число плюс четыре — это номер логического канала от четырех до девятнадцати (см. 5.1.1.2).

Таблица 3

Последующие межотраслевые значения CLA

Бит 8, установленный на 1, указывает проприетарный класс, за исключением значения 'FF', которое является недействительным. Контекст приложения определяет остальные биты.

5.1.1.1 Управление сцеплением команд

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

Если карта поддерживает этот механизм, то это должно быть указано (см. таблицу 88, третья таблица программных функций) в байтах предыстории (см. 8.1.1) или в EF.ATR (см. 8.2.1.1).

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

Для сцепления в межотраслевом классе должен использоваться бит 5 в CLA, пока остальные семь бит остаются постоянными.

• Если бит 5 установлен на 0, то команда является последней или единственной командой в цепи;
• Если бит 5 установлен на 1, то команда не является последней командой в цепочке.

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

• Если SW1-SW2 установлены на '6883', то ожидается последняя команда в цепочке;
• Если SW1-SW2 установлены на '6884', то сцепление команд не поддерживается.

5.1.1.2 Логические каналы

В настоящем разделе определен механизм, посредством которого в межотраслевом классе пара команда-ответ может обратиться к логическим каналам.

Если карта поддерживает механизм, то она должна указывать максимальное число доступных каналов (см. таблицу 88, третья таблица программных функций) в байтах предыстории (см. 8.1.1) или в EF.ATR (см. 8.2.1.1).

Если указанное картой число доступных каналов ? четыре или меньше, то следует применять таблицу 2.

Если указанное картой число доступных каналов ? пять или более, то следует применять еще таблицу 3.

Для обращения к логическим каналам в межотраслевом классе следует применять следующие правила:

• CLA кодирует номер канала пары команда-ответ;
• основной канал должен быть постоянно доступен, т.е. он не может быть закрыт. Ему присваивается нулевой номер;
• карты, не поддерживающие данный механизм (по умолчанию), должны использовать только основной канал;
• любой другой канал может быть открыт при завершении либо команды SELECT (см. 7.1.1), при этом CLA кодирует номер еще не использованного канала, либо команды MANAGE CHANNEL с функцией открытия (см. 7.1.2);
• любой другой канал может быть закрыт при завершении команды MANAGE CHANNEL с функцией закрытия. После закрытия канал становится доступным для повторного использования;
• только один канал должен быть активен единовременно. Использование логических каналов не снимает запрет чередования пар команда-ответ на стыке интерфейса, т.е. ответный APDU должен быть получен до инициализации другой пары команда-ответ (см. 5.1);
• для одной и той же структуры можно открыть более одного канала (см. 5.3), т.е. для DF, и возможно для DF приложения, а также возможно и для EF, если это явно не исключено байтом описателя файла (см. таблицу 14).

Каждый логический канал имеет свое состояние защиты (см. 5.4). Метод распределения состояний защиты выходит за рамки настоящего стандарта.

5.1.2 Командный байт

INS указывает команду для обработки. Учитывая положения ИСО/МЭК 7816-3, значения '6X' и '9X' являются недействительными.

В таблице 4 приведены все команды, указанные в ИСО/МЭК 7816 на момент публикации.

В таблице 4.1 приведены наименования команд в алфавитном порядке.

В таблице 4.2 приведены коды INS числовом порядке.

Таблица 4.1

Команды в алфавитном порядке

• Настоящий стандарт (см. 7) определяет команды для обмена информацией;
• ИСО/МЭК 7816-7 [4] определяет команды языка структурированных запросов для карт (SCQL);
• ИСО/МЭК 7816-8 [4] определяет команды для операций по защите информации;
• ИСО/МЭК 7816-9 [4] определяет команды для управления картами.

В межотраслевом классе бит 1 в INS указывает следующий формат поля данных:

• если бит 1 установлен на 0 (четный код INS), то никаких указаний не предусмотрено;
• если бит 1 установлен на 1 (нечетный код INS), то кодирование BER-TLV (см. 5.2.2) должно применяться следующим образом:
• в несцепленных командах с SW1, не установленным в '61', поля данных, если имеются, должны быть закодированы в BER-TLV;
• сцепление команд и/или использование SW1, установленного на '61', позволяет сделать передачу слишком длинной строки данных за одну команду. Такая операция позволяет разделить информационные объекты на поля данных, которые посылаются в виде последовательности в одном направлении, т.е. в обратном направлении поле данных не посылают. При сцеплении команд и/или использовании SW1, установленного на '61' сцепление всех последовательных полей данных в том же направлении той же последовательности должно быть закодировано в BER-TLV.

5.1.3 Байты состояний

SW1-SW2 указывают состояния обработки. Учитывая положения ИСО/МЭК 7816 любые значения, отличные от '6XXX' и '9XXX' являются недействительными; любые значения '60XX' являются также недействительными.

Значения '61XX', '62XX', '63XX', '64XX', '65XX', '66XX', '68XX', '69XX', '6AXX' и '6CXX' являются межотраслевыми. Учитывая положения ИСО/МЭК 7816-3, значения '67XX', '6BXX', '6DXX', '6EXX', '6FXX' и '9XXX' являются проприетарными, за исключением значений '6700', '6B00', '6D00', '6E00', '6F00' и '9000', которые являются межотраслевыми.

На рисунке 1 показана структурная схема значений '9000' и от '61XX' до '6FXX' для SW1-SW2.

Рисунок 1 — Структурная схема значений SW1-SW2

В таблице 5 перечислены межотраслевые значения SW1-SW2 и представлено их общее смысловое содержание. ИСО/МЭК СТК1/ПК17 зарезервировал для использования в будущем межотраслевые значения SW1-SW2, не определенные в серии ИСО/МЭК 7816.

Таблица 5

Общее смысловое содержание межотраслевых значений SW1-SW2

Если процесс прерван со значением SW1 от '64' до '6F', то поле данных ответа должно отсутствовать.

Если SW1 установлен в '63' или '65', то состояние энергонезависимой памяти будет изменено. Если SW1 установлен в '6X', за исключением '63' и '65', то состояние энергонезависимой памяти будет без изменений.

В ответе на команду, которая не является последней командой в цепочке (см. 5.1.1.1) межотраслевая индикация предупреждения не допускается (см. ИСО/МЭК 7816-3), т.е. SW1 не должен быть установлен ни на '62', ни на '63'.

Два межотраслевых значения SW1 зависят от протокола передачи:

• если SW1 установлен на '61', то процесс будет завершен; до выдачи какой-либо команды, команда GET RESPONSE может быть выдана с тем же CLA и с использованием SW2 (число еще доступных байтов данных) в качестве короткого поля Le;
• если SW1 установлен на '6C', то процесс будет прерван; до выдачи какой-либо команды та же команда может быть повторно выдана с использованием SW2 (точное число доступных байтов данных) в качестве короткого поля Le.

В таблице 6 перечислены специфические межотраслевые состояния предупреждения и состояния ошибок, используемые в серии ИСО/МЭК 7816.

Таблица 6

Специфические межотраслевые состояние предупреждения и состояний ошибок

5.2 Информационные объекты

Каждое поле данных или сцепление полей данных, если оно (они) закодировано(ы) в TLY, представляет собой последовательность информационных объектов. В данном разделе определены две категории информационных объектов: информационные объекты SIMPLE-TLV и информационные объекты BER-TLV.

5.2.1 Информационный объект SIMPLE-TLV

Каждый информационный объект SIMPLE-TLV должен состоять из двух или трех последовательных полей: обязательного поля тега, обязательного поля длины и условного поля значения. Записью (см. 7.3.1) может быть информационный объект SIMPLE-TLV.

Поле тега состоит из одиночного байта, кодирующего номер тега от 1 до 254. Значения '00' и 'FF' являются недействительными для поля тега. Если записью является информационный объект SIMPLE-TLV, то тег может использоваться как идентификатор записи.

Поле длины состоит из одного или трех последовательных байтов:

• если первый байт не установлен в 'FF', то поле длины состоит из одиночного байта, кодирующего число от нуля до 254 и обозначается как N;
• если первый байт установлен в 'FF', то поле длины продолжается последующими двумя байтами со значениями, кодирующими число от нуля до 65535 и обозначается как N.

Если № равно нулю, то поле значения отсутствует, т.е. информационный объект является пустым. В противном случае (N > 0), поле значения состоит из № последовательных байтов.

5.2.2 Информационный объект BER-TLV

Каждый информационный объект BER-TLV состоит из двух или трех последовательных полей (см. базовые правила кодирования АСН.1 по ИСО/МЭК 8825-1): обязательного поля тега, обязательного поля длины и условного поля значения:

Поле тега состоит из одного или большего числа последовательных байтов. Оно указывает класс и кодирование и кодирует номер тега. Значение '00' является недействительным для первого байта полей тега (см. ИСО/МЭК 8825-1).

Поле длины состоит из одного или большего числа последовательных байтов. Оно кодирует длину, т.е. число N.

Если № равно нулю, то поле значения отсутствует, т.е. информационный объект является пустым. В противном случае (N > 0), поле значения состоит из № последовательных байтов.

5.2.2.1 Поля тегов BER-TLV

Стандарты серии ИСО/МЭК 7816 поддерживают поля тегов из одного, двух или трех байтов; более длинные поля тегов зарезервированы для использования в будущем.

Биты 8 и 7 первого байта поля тега указывают класс:

• значение 00 указывает информационный объект универсального класса;
• значение 01 указывает информационный объект класса приложения;
• значение 10 указывает информационный объект контекстно-зависимого класса;
• значение 11 указывает информационный объект приватного класса.

Бит 6 первого байта поля тега указывает кодирование:

• значение 0 указывает простое кодирование информационного объекта, т.е. поле значения не кодировано в BER-TLV;
• значение 1 указывает составное кодирование информационного объекта, т.е. поле значения кодировано в BER-TLV.

Если биты с 5 по 1 первого байта поля тега не все установлены в состояние 1, то они должны кодировать номер тега от нуля до тридцати, при этом поле тега состоит из единственного байта.

В противном случае (биты с 5 по 1 установлены в состояние 1) поле тега должно продолжаться на один или большее число последующих байтов:

• бит 8 каждого последующего байта, за исключением последнего байта, должен быть установлен в состояние 1;
• биты с 7 по 1 первого последующего байта не должны быть все установлены в состояние 0;
• биты с 7 по 1 первого последующего байта, сцепленные с битами с 7 по 1 каждого из остальных последующих байтов, включая биты с 7 по 1 последнего байта, должны кодировать номер тега.

В таблице 7 показаны первые байты поля тега. Значение '00' является недействительным.

Таблица 7

Первый байт BER-TLV полей тегов по ИСО/МЭК 7816.

В полях данных, кодированных в BER-TLV, байты, установленные в '00', могут присутствовать до, между или после информационных объектов (например, за счет удаления или изменения информационных объектов в пределах EF, поддерживающего единицу данных). Такое заполнение запрещено в пределах полей значения составных информационных объектах и называется в ИСО/МЭК 7816 «шаблонами».

Если байт кодирования данных присутствует в байтах предыстории (см. 8.1.1) или в EF.ATR (см. 8.2.1.1) или в контрольной информации какого-либо файла (см. тег '82' в таблице 12), то этот байт (см. таблицу 87) указывает, является ли значение 'FF':

• действительным для первого байта длинного поля тега приватного класса, составного кодирования (заданного в явном виде), или
• недействительным для первого байта полей тегов (значение по умолчанию), т.е. используется для аналогичного назначения (заполнения) и при тех же условиях, что и значение '00'.

В полях тега двух или более байтах значения от '00' до '1E' и '80' являются недействительными для второго байта.

• В двухбайтных полях тега второй байт состоит из бита 8, установленного в состояние 0, и битов с 7 по 1, кодирующих число, большее тридцати. Второй байт имеет значения от '1F' до '7F'; номер тега — от 31 до 127.
• В трехбайтовых полях тега второй байт состоит из бита 8, установленного в состояние 1, и битов с 7 по 1, не все из которых установлены в состояние 0; третий байт состоит из бита 8, установленного в состояние 0, и битов с 7 по 1, принимающих любые значения. Второй байт принимает значения от '81' до 'FF', а третий байт — от '00' до '7F'; номер тега принимает значения от 128 до 16383.

5.2.2.2 Поля длины BER-TLV

В коротком формате поле длины состоит из единичного байта, в котором бит 8 установлен в состояние 0, а биты с 7 по 1 кодируют число байтов в поле значения. Таким образом, одним байтом может быть закодировано любое число от нуля до 127.

Примечание — Любое число от одного до 127 кодируется в поле длины BER-TLV так же, как в полях Lc и Le. Кодирование отличается для ноля, 128 и более. Для примера см. кодирование информационных объектов в команде GET DATA в 7.4.2

В длинном формате поле длины состоит из двух или более байтов. Бит 8 первого байта установлен в состояние 1, а биты с 7 по 1 не должны быть все равны, таким образом происходит кодирование последующих байтов в поле длины. Эти последующие байты должны кодировать число байтов в поле значения.

В стандартах серии ИСО/МЭК 7816 не используют «неопределенную длину», указанную базовыми правилами кодирования АСН.1.

В стандартах серии ИСО/МЭК 7816 поддерживаются поля длины из одного, двух, ... до пяти байтов (см. таблицу 8). В ИСО/МЭК 7816 значения '80' и от '85' до 'FF' являются недействительными для первого байта полей длины.

Таблица 8

Поля длины BER-TLV по ИСО/МЭК 7816

5.2.3 Поля данных, поля значений, информационные объекты и элементы данных

Каждое поле данных команды или ответа может быть закодировано в BER-TLV, например в паре команда-ответ, где CLA указывает безопасный обмен сообщениями (см. 6) или где бит 1 в INS установлен в состояние 1 (нечетный код INS, см. 5.1.2).

• Любой информационный объект BER-TLV обозначается {T-L-V} с полем тега, за которым следует поле длины, кодирующее число. В зависимости от того является ли число нулевым или нет, поле значения отсутствует (пустой информационный объект) или присутствует.
• Любой составной информационный объект обозначается {T-L-{T1-L1-V1}...-{Tn-Ln-Vn}} с полем тега, за которым следует поле длины, кодирующее число. Если число не является нулевым, то поле значения составного информационного объекта, т.е. шаблона, состоит из одного или более информационных объектов BER-TLV, каждый из которых состоит из поля тега, поля длины, кодирующего число, и если это число является нулевым, то из поля значения.

Некоторые поля данных, например команды для работы с единицами данных (см. 7.2), поля значений информационный объектов SIMPLE-TLV и поля значений некоторых простых информационных объектов состоят из элементов данных в соответствии с характеристиками команд или в соответствии с тегом информационного объекта.

Некоторые поля данных, например команды для работы с записями (см. 7.3) и поля значений некоторых простых информационных объектов BER-TLV состоят из информационных объектов SIMPLE-TLV.

Некоторые поля данных, например команды для работы с информационными объектами (см. 7.4) и поля значений составных информационных объектов BER-TLV, т.е. шаблонов, состоят из информационных объектов BER-TLV.

5.2.4 Идентификация элементов данных

Идентификация элементов данных основывается на следующих принципах:

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

2. На стыке интерфейса между картой и устройством сопряжения элемент данных обычно присутствует в поле значения информационного объекта BER-TLV.

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

4. Обращение к элементу данных может осуществляться через непосредственно связанный с ним тег BER-TLV. Элемент данных может быть связан с другим элементом данных, который устанавливает контекст, к которому он принадлежит.

5. Один или несколько информационных объектов «команда на выполнение» могут непосредственно ссылаться на элемент данных.

6. При наличии, информационные объекты универсального класса (первый байт от '01' до '3F') принимают общее значение.

7. Все информационные объекты класса приложения (первый байт от '40' до '7F') являются межотраслевыми до тех пор, пока не будет указано иное. Настоящий стандарт и другие стандарты серии ИСО/МЭК 7816 выделяют теги для класса приложения. Каждый тег класса приложения, не определенный в серии ИСО/МЭК 7816 зарезервирован ИСО/МЭК СТК 1/ПК 17.

8. В настоящем стандарте определено множество межотраслевых элементов данных. В дополнение к определенным далее межотраслевым элементам данных, стандарты серии ИСО/МЭК 7816 содержат исчерпывающий перечень межотраслевых элементов данных, определенных в ИСО/МЭК 7816.

9. В карте может быть несколько одинаковых межотраслевых информационных объектов.

10. В поле данных команды и ответа все информационные объекты контекстно-зависимого класса (первый байт от '80' до 'BF') должны быть вложены в межотраслевые шаблоны, за исключением контрольной информации файла (см. 5.3.3) и безопасного обмена сообщениями (см. 6).

11. В последующих разделах (см. приложение A) определена схема распределения тегов для идентификации межотраслевых информационных объектов в полях данных. Эти схемы распределения тегов, используемые для идентификации межотраслевых информационных объектов, показаны в таблице 9 для уведомления органа, ответственного за распределение тегов.

Таблица 9

Межотраслевые информационные объекты для органа распределения тегов

5.2.4.1 Совместимая схема распределения тегов

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

Эти дополнительные информационные объекты должны быть вложены в межотраслевые шаблоны, связанные с тегами от '70' до '77' (за исключением тега '73', зарезервированного для проприетарных информационных объектов, см. 5.2.4.3). Содержание тегов класса приложения в пределах этих шаблонов настоящий стандарт и стандарты серии ИСО/МЭК 7816 не определяют, за исключением тегов '41', '42' и '4F' для идентификации органа распределения тегов, как показано в таблице 9.

Использование контекстно-зависимого класса (первый байт от '80' до 'BF') в пределах межотраслевых шаблонов с тегами '65' (данные, относящиеся к держателю карты), '66' (данные карты), '67' (аутентификационные данные) и '6E' (данные, относящиеся к приложению) не рекомендуется.

Для идентификации совместимой схемы распределения тегов и органа, ответственного за эту схему, может быть использован межотраслевой шаблон, связанный с тегом '78'. При наличии, такой шаблон должен содержать один из межотраслевых информационных объектов, показанных в таблице 9, для идентификации органа распределения тегов.

• Если тег '78' имеется в строке начальных данных (см. 8.1.2) или в EF.ATR, то орган распределения тегов действителен для карты в целом.
• Если тег '78' присутствует в данных управления DF (см. 5.3.3), то орган распределения тегов является действительным в пределах этого DF.

5.2.4.2 Сосуществующая схема распределения тегов

В сосуществующих схемах распределения тегов могут использовать теги с интерпретацией, которая не определена в стандартах серии ИСО/МЭК 7816. Для идентификации сосуществующей схемы распределения тегов и органа, ответственного за эту схему, должен быть использован межотраслевой шаблон, связанный с тегом '79'. Если такой шаблон имеется, то он должен содержать один из межотраслевых объектов данных, показанных в таблице 9, для того, чтобы идентифицировать орган распределения тегов.

• Если орган распределения тегов действителен для карты в целом, тогда тег '79' должен присутствовать в строке начальных данных (см. 8.1.2) или в EF.ATR (см. 8.2.1.1).
• Если орган распределения тегов действителен в пределах DF, тогда тег '79' должен присутствовать в данных управления DF (5.3.3).

В такой схеме все межотраслевые информационные объекты должны быть вложены в межотраслевые шаблоны, связанные с тегом '7E'. Кроме того, теги '79' '7E' не должны интерпретироваться иначе, чем теги '62', '64', '6F' (шаблоны FCP, FMD и FCI, см. 5.3.3) и '7D' (шаблон SM, см. 6)

5.2.4.3 Независимые схемы распределения тегов

В этих схемах распределения тегов могут использовать теги с иной интерпретацией, чем принятая в настоящем стандарте и стандартах серии ИСО/МЭК 7816, которая не подчиняется требованиям 5.2.4.2. Такие схемы распределения тегов делают невозможным межотраслевой обмен информацией и не согласуются с настоящим стандартом.

Использование межотраслевых произвольных информационных объектов с тегами '53' для представления произвольных элементов данных и тегами '73' для вложения проприетарных информационных объектов в произвольные шаблоны дает возможность применения проприетарных элементов данных и информационных объектов, сохраняя в то же время соответствие настоящему стандарту.

5.3 Структуры приложений и данных

В настоящем подразделе определена структура приложений и данных, прослеживаемые на стыке интерфейса между картой и устройством сопряжения при обработке команд, используемых в межотраслевом классе. Размещение данных в физической памяти и структурная информация сверх той, что представлена в данном подразделе, находятся за пределами компетенции настоящего стандарта и стандартов серии ИСО/МЭК 7816.

Настоящий стандарт поддерживает следующие две категории структур: назначенный файл (DF) и элементарный файл (EF).

Файлы DF выполняют хостинг приложений и/или группы файлов и/или хранят информационные объекты. DF приложения является файлом DF, который выполняет хостинг приложения. DF может быть родительским файлом или иным файлом. Считается, что эти иные файлы находятся непосредственно под DF.

Файлы EF хранят данные. EF не может быть родительским или иным файлом. Определены следующие две категории файлов EF:

• внутренние EF хранят данные, интерпретируемые картой, т.е. данные, используемые картой в целях управления и контроля;
• рабочие EF хранят данные, не интерпретируемые картой, т.е. данные, подлежащие использованию исключительно внешними устройствами.

Предусмотрено два типа логической организации:

На рисунке 2 показана иерархия файлов DF с их соответствующей архитектурой безопасности (см. 5.4). В такой организации карт файл DF в основании иерархии называется главным файлом (MF); любой DF может быть файлом DF приложения с или без своей собственной иерархией файлов DF.

Рисунок 2 — Пример иерархии файлов DF

На рисунке 3 показаны файлы DF приложения с параллельной структурой без MF на стыке интерфейса, т.е. без видимой иерархии файлов DF. Такая организация поддерживает независимые приложения в карте, где любое DF приложения может иметь свою собственную иерархию файлов DF с соответствующей архитектурой безопасности.

Рисунок 3 — Пример независимых файлов DF приложения

5.3.1 Выбор структуры

5.3.1.1 Методы выбора структуры

Выбор структуры позволяет получить доступ к данным структуры и, если структура представляет собой DF, то и к ее подструктуре. Структура может быть выбрана неявно, т.е. автоматически после восстановления и возможного выбора протокола и параметров (см. ИСО/МЭК 7816-3). Если структура не может быть выбрана неявно, то она должна быть выбрана явно, т.е. с помощью, по меньшей мере, одного из следующих методов.

Выбор по имени DF — Обращение к любому DF может быть осуществлено по имени DF. Оно представляет собой строку до шестнадцати байтов. Любой идентификатор приложения (AID, см. 8.2.1.2) может быть использован в качестве имени DF. Для того чтобы однозначно выбирать по имени DF, например, когда выбор осуществляется путем использования идентификаторов приложений, имя каждого DF должно быть уникальным в данной карте.

Выбор посредством идентификатора файла — Обращение к любому файлу может быть осуществлено с помощью идентификатора файла. Он состоит из двух байт. Значение '3F00' зарезервировано для обращения к MF. Значение 'FFFF' зарезервировано для использования в будущем. Значение '3FFF' также зарезервировано (см. ниже и 7.4.1). Значение '0000' зарезервировано (см. 7.2.2 и 7.4.1). Для того чтобы однозначно выбирать любой файл с помощью его идентификатора, все файлы EF и DF, находящиеся в иерархии непосредственно под данным DF, должны иметь разные идентификаторы.

Выбор через путь — Обращение к любому файлу может быть осуществлено через путь. Он представляет собой сцепление идентификаторов файлов. Путь начинается с идентификатора DF (MF для абсолютного пути или текущего DF для относительного пути) и заканчивается идентификатором выбираемого файла. Между этими двумя идентификаторами путь состоит из идентификаторов последовательных (в рамках иерархии) родительских DF, если они имеются. Порядок следования идентификаторов файлов — всегда в направлении от родительского файла к дочернему. Если идентификатор текущего DF не известен, в начале пути может использоваться значение '3FFF' (зарезервированное значение). Значения '3F002F00' и '2F002F01' зарезервированы (см. 8.2.1.1). Использование пути позволяет осуществлять однозначный выбор любого файла из MF или из текущего DF (см. 8.3).

Обращение посредством короткого идентификатора EF — Обращение к любому EF может быть осуществлено с помощью короткого идентификатора EF. Он состоит из пяти бит, которые не все равны друг другу, т.е. представляют собой значение от одного до тридцати. Значение ноль, т.е. 00000, используемое в качестве короткого идентификатора EF, указывает на выбираемый в текущий момент EF. На уровне MF число тридцать, т.е. 111100 в бинарном выражении, зарезервировано (см. 8.2.1.1). Короткие идентификаторы файлов EF не могут быть использованы в последовательности пути или в качестве идентификатора файла EF (например, в команде SELECT).

Выбор посредством короткого идентификатора EF должен быть указан, если он поддерживается.

• Если первая таблица программных функций (см. таблицу 86) присутствует в байтах предыстории (см. 8.1.1) или в EF.ATR (см. 8.2.1.1), то индикация является действительной на уровне карты.
• Если короткий идентификатор EF (тег '88', см. таблицу 12) присутствует в контрольных параметрах (см. 5.3.3) файла EF, то индикация является действительной на уровне EF.

5.3.1.2 Элемент данных «ссылка на файл»

Связанный с тегом '51' данный межотраслевой элемент данных обращается к файлу. Он может иметь произвольную длину.

• Пустой информационный объект обращается к MF.
• Если длина равна единице и если биты с 8 по 4 элемента данных не все равны друг другу, и если биты с 3 по 1 установлены на 000, то биты с 8 по 4 кодируют число от одного до тридцати, которое является коротким идентификатором EF.
• Если длина равна двум, то элемент данных представляет собой идентификатор файла.
• Если длина больше двух, то элемент данных представляет собой путь:
• если длина четная и если первые два байта установлены на '3F00', то путь является абсолютным. Элемент данных представляет собой сцепление, как минимум, двух идентификаторов файла и идентификатора MF;
• если длина четная и если первые два байта не установлены на '3F00', то путь является относительным. Элемент данных представляет собой сцепление, как минимум, двух идентификаторов файла, начиная с идентификатора текущего DF;
• если длина нечетная, то путь специфицированный. Элемент данных является или абсолютным путем без '3F00', или относительным путем без идентификатора текущего DF, за которым следует байт, используемый в качестве P1 в одной или нескольких командах SELECT (см. 7.1.1 и 8.3).

В таблице 10 показан информационный объект «ссылка на файл».

Таблица 10

Информационный объект «ссылка на файл»

5.3.2 Методы обращения к данным

В файлах DF обращение к данным может осуществляться как к информационным объектам (см. 5.2). Файл DF прослеживается на стыке интерфейса между картой и устройством сопряжения как совокупность информационных объектов, имеющих доступ при помощи команд для работы с информационными объектами (см. 7.4).

В файлах EF обращение к данным может осуществляться как к единицам данных (см. 7.2.1), записям (см. 7.3.1) или информационным объектам (см. 5.2). Метод обращения к данным является характеристикой, зависящей от EF. Определены три структуры файлов EF:

• прозрачная структура, при которой файл EF прослеживается на стыке интерфейса между картой и устройством сопряжения как одиночная непрерывная последовательность единиц данных, имеющих доступ при помощи команд для работы с единицей данных (см. 7.2). Размер единицы данных является характеристикой, зависящей от EF;

• структура TLV, при которой EF прослеживается на стыке интерфейса между картой и устройством сопряжения как совокупность информационных объектов, имеющих доступ при помощи команд для работы с информационными объектами (см. 7.4). Тип информационного объекта в EF, т.е. или SIMPLE-TLV или BER-TLV, является характеристикой, зависящей от EF.

Для обращения к данным в файлах EF карта поддерживает, по крайней мере, одну из пяти структур, показанных на рисунке 4.

1. прозрачная структура;

2. линейная структура с записями фиксированного размера;

3. линейная структура с записями переменного размера;

4. циклический EF с записями фиксированного размера

(стрелка указывает на последнюю сделанную запись);

5. структура TLV

Рисунок 4 — Структуры EF

5.3.3 Контрольная информация файла

Контрольная информация файла представляет собой строку байтов данных, содержащуюся в ответе на команду SELECT (см. 7.1.1). Она может быть у любой структуры, т.е. у любого DF или EF.

Если первый байт имеет значение от '00' до 'BF', то строка байтов должна быть закодирована в BER-TLV. ИСО/МЭК СТК1/ПК17 зарезервировал для использования в будущем все значения в диапазоне от '00' до 'BF', которые не определены в настоящем стандарте.

Если первый байт имеет значения от 'C0' до 'FF', то строка байтов не кодируется в соответствии с настоящим стандартом.

В таблице 11 приведены три межотраслевых шаблона для вложенных информационных объектов BER-TLV контрольной информации файла.

• Шаблон FCP представляет собой совокупность контрольных параметров файла, т.е. логических, структурных атрибутов и атрибутов секретности, перечисленных в таблице 12 и определенных далее. В пределах шаблона FCP контекстно-зависимый класс (первый байт от '00' до 'BF') зарезервирован для контрольных параметров файла; теги '85' и 'A5' обращаются к произвольным данным.
• Шаблон FMD представляет собой совокупность данных управления файлом, т.е. межотраслевые информационные объекты, такие как идентификатор приложения по 8.2.1.2, уровень приложения по 8.2.1.4 и дата истечения срока действия по ИСО/МЭК 7816-6, возможно вложенные в пределах шаблона приложения по 8.2.1.3. В пределах шаблона FMD теги '53' и '73' обращаются к произвольным данным.
• Шаблон FCI представляет собой совокупность контрольных параметров файла и данных управления файлом.

Таблица 11

Межотраслевые шаблоны для контрольной информации файла

Извлечение этих трех шаблонов может осуществляться по опциям выбора команды SELECT (см. таблицу 40).

Если установлена опция FCI, то тег FCI является необязательным для представления шаблона в поле данных ответа.

Если установлена опция FCP или FMD, то использование соответствующего тега является обязательным для представления шаблона.

В таблице 12 перечислены контрольные параметры файла (все в контекстно-зависимом классе). Если контрольный параметр имеется для файла, то в таблице указано возникает ли он только один раз (явная индикация) или он может повторяться (без индикации).

Таблица 12

Информационные объекты «контрольные параметры файла»

Часть контрольной информации файла DF может быть дополнительно представлена в файле EF под управлением приложения, ссылка на который приводится под тегом '87' в контрольных параметрах. В таком EF, если он имеется, контрольная информация файла должна быть представлена соответствующим тегом: или тегом FCP, или тегом FCI.

5.3.3.1 Короткий идентификатор EF

Для использования тега '88' в контрольных параметрах любого EF применяют следующие правила:

• если карта поддерживает выбор посредством коротких идентификаторов EF (см. 5.3.1.1) и если тег '88' отсутствует, то второй байт идентификатора файла (тег '83'), биты с 5 по 1 кодируют короткий идентификатор EF;
• если тег '88' присутствует с длиной, установленной на ноль, то EF не поддерживает короткий идентификатор;
• если тег '88' присутствует с длиной, установленной на единицу и если биты с 8 по 4 элемента данных не все равны друг другу, и если биты с 3 по 1 установлены на 000, то биты с 8 по 4 кодируют короткий идентификатор EF (т.е. число от одного до тридцати).

5.3.3.2 Байт состояния жизненного цикла

И карта, и файлы, и другие объекты имеют жизненный цикл; состояние жизненного цикла позволяет карте и устройству сопряжения идентифицировать различные логические состояния защиты при использовании карты, файлов или иных объектов в карте. Для поддержки гибкости управления жизненным циклом как атрибутом (см. ИСО/МЭК 7816-9 [4]) в настоящем разделе определены четыре основные состояния жизненного цикла в следующем порядке:

1. состояние создания;

2. состояние инициализации;

3. рабочее состояние;

4. состояние завершения.

Байт состояния жизненного цикла (байт LCS) должен быть интерпретирован в соответствии с таблицей 13:

• значения от '00' до '0F' являются межотраслевыми;
• значения от '10' до 'FF' являются проприетарными.

Таблица 13

Байт состояний жизненного цикла

Файл байта LCS, связанный с тегом '8A', может присутствовать в контрольных параметрах любого файла (см. таблицу 12).

Байт LCS карты может присутствовать в байтах предыстории (см. 8.1.1.3). Байт LCS карты, связанный с тегом '48', может присутствовать в EF.ATR (см. 8.2.1.1). Если он имеет MF, то карта находится, по крайней мере, в состоянии создания.

Примечание - Пока не указано иное, атрибуты секретности являются действительными для рабочего состояния.

5.3.3.3 Байт описателя файла

Элемент данных, связанный с тегом '82', может присутствовать в контрольных параметрах любого файла (см. таблицу 12).

Первым байтом элемента данных является байт описателя файла (см. таблицу 14).

Если элемент данных состоит из двух или более байтов, то вторым байтом является байт кодирования данных (см. таблицу 87). Если карта создает байты кодирования данных в нескольких местах, то индикация является действительной для заданного файла в ближайшей позиции, так что файл находится в пределах пути от MF до этого файла.

Таблица 14

Байт описателя файла

5.4 Архитектура безопасности

5.4.1 Общие положения

В настоящем подразделе рассмотрены состояние защиты, атрибуты секретности и механизмы защиты.

Состояние защиты. Состояние защиты представляет собой текущее состояние, которое может достигаться после завершения ответа на восстановление и возможного выбора протокола и параметров и/или отдельной команды или последовательности команд, возможно выполняющих процедуры аутентификации. Состояние защиты может являться также результатом завершения процедуры защиты, связанной с идентификацией участвующих сторон, если таковая применяется, например посредством проверки знания пароля (например, с использованием команды VERIFY), проверки знания ключа (например, с использованием команды GET CHALLENGE, сопровождаемой командой EXTERNAL AUTHENTICATE или последовательностью команд GENERAL AUTHENTICATE), или безопасного обмена сообщениями (например, на основе аутентификации сообщений). Рассматриваются следующие три состояния защиты.

• Глобальное состояние защиты. В карте, использующей иерархию файлов DF, глобальное состояние защиты может видоизменяться в результате завершения процедуры аутентификации, относящейся к MF (например, аутентификации участвующей стороны по паролю или ключу, присоединенному к MF).
• Состояние защиты, связанное с (конкретным) приложением. Оно может видоизменяться в результате завершения процедуры аутентификации, относящейся к приложению (например, аутентификации участвующей стороны по паролю или ключу, присоединенному к приложению); оно может быть сохранено, восстановлено или утрачено при выборе приложения; данное изменение может относиться только к приложению, к которому относится процедура аутентификации. Если применяют логические каналы, то состояние защиты, связанное с приложением может зависеть от логического канала.
• Файловое состояние защиты (т.е. ориентированное на файл). Файловое состояние защиты может видоизменяться в результате завершения процедуры аутентификации, относящейся к DF (например, аутентификации участвующей стороны по паролю или ключу, присоединенному к конкретному DF); оно может быть сохранено, восстановлено или утрачено при выборе файла; данное изменение состояния защиты может быть уместно только для приложения, с которым связана процедура аутентификации. Если применяют логические каналы, то файловое состояние защиты может зависеть от логического канала.
• Командное состояние защиты (т.е. ориентированное на команду). Командное состояние защиты имеет место лишь во время выполнения команды, предусматривающей аутентификацию с использованием безопасного обмена сообщениями; такая команда может оставлять без изменений другое состояние защиты.
• Атрибуты секретности. Атрибуты секретности, если они имеются, определяют разрешенные действия и условия. Атрибуты секретности файла зависят от его категории (DF или EF) и возможных параметров в его контрольной информации и/или в контрольной информации его родительского(их) файла(ов). Атрибуты секретности могут сопутствовать командам, информационным объектам и таблицам и представлениям. В частности, атрибуты секретности могут:
• определять состояние защиты карты, чтобы быть в действующем состоянии перед осуществлением доступа к данным;
• ограничить доступ к данным для определенных функций (например, только для чтения), если карта имеет особое состояние;
• определить, какие защитные функции должны быть выполнены, чтобы получить определенное состояние защиты.

Механизмы защиты. Настоящий стандарт устанавливает следующие механизмы защиты:

• Аутентификация участвующей стороны по паролю. Карта сравнивает данные, полученные от внешнего устройства, с секретными внутренними данными. Этот механизм может использоваться для защиты прав пользователя;
• Аутентификация участвующей стороны по ключу. Участвующая сторона, подвергаемая аутентификации, должна доказать знание соответствующего секретного или приватного ключа в ходе процедуры аутентификации (например, с использованием команды GET CHALLENGE, сопровождаемой командой EXTERNAL AUTHENTICATE и последовательностью команд GENERAL AUTHENTICATE);
• Аутентификация данных. Используя внутренние данные (или секретный ключ, или открытый ключ), карта проверяет избыточные данные, полученные от внешних устройств. В свою очередь, используя секретные внутренние данные (или секретный ключ, или приватный ключ) карта вычисляет элемент данных (криптографическую контрольную сумму или электронную цифровую подпись) и вставляет его в данные, посылаемые внешнему устройству. Данный механизм может использоваться для защиты прав провайдера;
• Шифрование данных. Используя секретные внутренние данные (или секретный ключ или приватный ключ), карта осуществляет дешифрование криптограммы, полученной в поле данных. В свою очередь, используя внутренние данные (или секретный ключ или открытый ключ), карта вычисляет криптограмму и вставляет ее в поле данных, возможно вместе с другими данными. Данный механизм может использоваться для обеспечения услуги конфиденциальности, например, для управления ключами и условного доступа. В дополнение к механизму с криптограммой, конфиденциальность данных может достигаться за счет сокрытия данных. В этом случае карта вычисляет строку скрывающих байтов и прибавляет ее с помощью операции сложения «исключающее ИЛИ» к байтам данных, полученным от внешнего устройства или посылаемым внешнему устройству. Данный механизм может использоваться для защиты личных секретных данных и для снижения возможностей фильтрации сообщений.

Результат аутентификации может регистрироваться во внутреннем EF в соответствии с требованиями приложения.

5.4.2 Шаблон «идентификатор криптографического механизма»

Связанный с тегом 'AC' один или несколько шаблонов «идентификатор криптографического механизма» может присутствовать в контрольных параметрах любого DF (см. таблицу 12). Каждый шаблон явно указывает значение ссылки криптографического механизма в DF и его иерархию. Такой шаблон должен состоять из одного или нескольких информационных объектов:

• Первый информационный объект должен быть ссылкой криптографического механизма, тег '80' (см. таблицу 33);
• Второй информационный объект должен быть идентификатором объекта, тег '06' (по ИСО/МЭК 8825-1). Идентифицированный объект должен быть криптографическим механизмом, определенным или зарегистрированный в стандарте, например, в стандартах серии ИСО. Примерами криптографических механизмов являются алгоритмы шифрования (например, ИСО/МЭК 18033 [18]), коды аутентификации сообщений (например, ИСО/МЭК 9797 [7]), протоколы аутентификации (например, ИСО/МЭК 9798 [8]), цифровые подписи (например, ИСО/МЭК 9796 [6] или ИСО/МЭК 14888 [16]), зарегистрированные криптографические алгоритмы (например, ИСО/МЭК 9979 [9]) и т.д.
• Последующие информационные объекты (один или более), если они имеются, должны или идентифицировать механизм, тег '06', используемый в предыдущем механизме (т.е. режим операции, например, ИСО/МЭК 10116 [11], или хэш-функция, например, ИСО/МЭК 10118 [12]), или указывать параметры (тег зависит от предыдущего механизма).

Примеры — См. пояснения в приложении A.

{'AC' — '0B' — {'80' — '01' — '01'} — {'06' — '06' — '28818C710201'}}

Шаблон связывает локальную ссылку '01' первого алгоритма шифрования по ИСО/МЭК 18033-2 [18].

{'AC' — '11' — {'80' — '01' — '02'} — {'06' — '05' — '28CC460502'} — {'06' — '05' — '28CF060303'}}

Первый идентификатор объекта относится ко второму механизму аутентификации по ИСО/МЭК 9798-5 [8]. Второй идентификатор объекта относится к третьей выделенной хэш-функции по ИСО/МЭК 10118-3 [12]. Поэтому шаблон связывает локальную ссылку '02' с GQ2, используя SHA-1.

5.4.3 Атрибуты секретности

Связанные с тегами '86', '8B', '8C', '8E', 'A0', 'A1', 'AB' атрибуты секретности могут присутствовать в контрольных параметрах любого файла (см. таблицу 12). Любой объект в карте (например, команда, файл, информационный объект, таблица и представление) может быть связан с больше чем одним атрибутом секретности и/или со ссылкой, содержащейся в атрибуте секретности.

Шаблон «атрибуты секретности», связанный с тегом 'A0', для информационного объекта может присутствовать в контрольных параметрах любого файла. Такой шаблон является сцеплением информационного объекта «атрибуты секретности» (теги '86', '8B', '8C', '8E', 'A0', 'A1', 'AB') и информационного объекта «список тегов» (тег '5C', см. 8.5.1), указывающего соответствующий информационный объект в файле.

Атрибут секретности канала, связанный с тегом '8E' (не более одного), может присутствовать в контрольных параметрах любого файла (см. таблицу 12) и в любой соответствующей безопасной среде (SE, см. 6.3.3). Он может быть интерпретирован в соответствии с таблицей 15.

• «Нет совместного доступа» означает, что должно быть доступно не более одного логического канала. Физически технология может быть ограничена.
• «Снабженный средствами защиты» означает, что SM ключи (см. 6) должны быть доступными (например, созданный при предыдущей аутентификации).
• «Пользователь аутентифицирован» означает, что пользователь должен быть аутентифицирован (например, при успешной проверке паролем).

Таблица 15

Атрибут секретности канала

В среде SCQL (см. ИСО/МЭК 7816-7 [4], команды языка структурированных запросов для карты) атрибуты секретности могут быть определены в операциях SCQL, например в командах CREATE TABLE и CRETE VIEW. Если используются атрибуты секретности, установленные в настоящем разделе, то они должны быть переданы в информационный объект с тегами '8B', '8C' или 'AB' в параметры атрибутов секретности SCQL операций.

Форматы. В настоящем разделе определены два формата для связанных объектов и атрибутов секретности: сжатый формат, основанный на битовом отображении, и расширенный формат, который расширяет сжатый формат с помощью управления TLV.

5.4.3.1 Сжатый формат

В сжатом формате правило доступа состоит из байта режима доступа, за которым следует один или несколько байтов условий секретности. Управление доступом к объекту организуют путем сцепления правил доступа со связанным объектом. Если в поле значения информационного объекта с тегом '8C' (см. таблицу 12) присутствуют несколько правил доступа, то они представляют собой условие логического И.

Байты режима доступа. Каждый бит с 7 по 1 указывает либо на отсутствие байта условия секретности, если байт установлен на 0, либо на присутствие байта условия секретности при той же последовательности бит (биты с 7 по 1), если он установлен на 1. Если бит 8 установлен на 1, то биты с 7 по 4 могут быть использованы для дополнительных команд, например для команд, связанных с (конкретным) приложением.

В таблицах с 16 по 19 определены байты режима доступа для файлов DF, EF, информационных объектов и таблиц и представлений, соответственно.

Таблица 16

Байт режима доступа для файлов DF

Таблица 17

Байт режима доступа для файлов EF

Таблица 18

Байт режима доступа для информационных объектов

Таблица 19

Байт режима доступа для таблиц и представлений

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

Таблица 20

Байт условия секретности

Биты с 8 по 5 указывают требуемые условия секретности. Если не все равны, то биты с 4 по 1 идентифицируют безопасную среду (см. 6.3.4, байт SEID от одного до четырнадцати), а механизмы, определенные в безопасной среде, должны быть использованы в соответствии с указаниями в битах с 7 по 5 для команд по обеспечению безопасности и/или внешней аутентификации, и/или аутентификации пользователя.

• Если бит 8 установлен на 1, то все условия, установленные в битах с 7 по 5, должны быть выполнены.
• Если бит 8 установлен на 0, то должно быть выполнено, как минимум, одно условие, установленное в битах с 7 по 5.
• Если бит 7 установлен на 1, то шаблон управляющих ссылок (см. 6.3.1) безопасной среды, идентифицированный в битах с 4 по 1, т.е. байте SEID от одного до четырнадцати, описывает должен ли применяться безопасный обмен сообщениями для поля данных команды и/или поля данных ответа (см. использование байта квалификатора, см. таблицу 35).

5.4.3.2 Расширенный формат

В расширенном формате правило доступа состоит из информационного объекта «режима доступа», за которым следует один или несколько информационных объектов «условие секретности». Управление доступом к объекту организуют путем обращения соответствующего объекта к правилам доступа. Для таких правил шаблон с тегом 'AB' может присутствовать в контрольных параметрах любого файла (см. таблицу 12).

Информационный объект «режим доступа». Информационный объект «режим доступа» содержит или байт режима доступа (см. таблицы с 16 по 19), или список описаний команд, или проприетарное описание состояния машины; последующие информационные объекты «условие секретности» относятся ко всем указанным командам. В таблице 21 показан информационный объект «режим доступа».

Таблица 21

Информационный объект «режим доступа»

Если тег — от '81' до '8F', то элемент данных режима доступа представляет собой список возможных комбинаций значений четырех байтов: CLA, INS, P1 и P2 в заголовке команды. В зависимости от значения бит с 4 по 1 для тега список содержит только те значения, которые описаны в таблице 22. Для того чтобы определить набор команд, могут возникнуть несколько групп, например, значения INS P1 P2, INS P1 P2, ... для тега '87'.

Таблица 22

Теги с '81' по '8F' для информационного объекта «режим доступа»

Информационный объект «условие секретности». В соответствии с таблицей 23 информационный объект «условие секретности» определяет действия по обеспечению безопасности, требуемые для получения доступа к объекту, защищенному определенным информационным объектом режима доступа. Шаблон управляющих ссылок (см. 6.3.1), связанный с тегом 'A4' (AT), 'B4' (CCT), 'B6' (DST) или 'B8' (CT) (при использовании в качестве условия секретности) должен содержать информационный объект «квалификатор применимости» (см. таблицу 35), указывающий действия по обеспечению безопасности.

Таблица 23

Информационный объект «условие секретности»

К одной операции может быть прикреплено несколько информационных объектов «условие секретности»:

• если информационные объекты «условие секретности» вложены в шаблон OR (тег 'A0'), то, по крайней мере, одно условие секретности должно быть выполнено до начала работы;
• если информационные объекты условия секретности не вложены в шаблон OR (тег 'A0') или они вложены в шаблон AND (тег 'AF'), то каждое условия секретности должно быть выполнено до начала работы;
• если информационные объекты «условие секретности» вложены в шаблон NOT (тег 'A7'), то условия секретности являются истинными, пока они не выполнены.

5.4.3.3 Указатели правил доступа

Правила доступа расширенного формата могут быть сохранены в EF, поддерживающем линейную структуру с записями переменной длины. Такой EF называется EF.ARR. Одно или несколько правил доступа может храниться в каждой записи, на которую ссылается номер записи. Такой номер записи называется байтом ARR. В таблице 24 показана компоновка EF.ARR.

Таблица 24

Компоновка EF.ARR

Связанные с тегом '8B' информационные объекты «атрибут секретности», ссылающиеся на расширенный формат (см. таблицу 25) могут присутствовать в контрольных параметрах любого файла (см. таблицу 12).

Таблица 25

Информационные объекты «атрибут секретности», ссылающиеся на расширенный формат

Если длина равна единице, то поле значения — байт ARR, который ссылается на запись в неявно известном EF.ARR.

Если длина равна трем, то поле значения — идентификатор файла, за которым следует байт ARR; идентификатор файла ссылается на EF.ARR, а байт ARR является числом записей в EF.ARR.

Если длина четная и не менее четырех, то поле значения — идентификатор файла, за которым следует одна или несколько пар байт. Каждая пара состоит из байта SEID, за которым следует байт ARR; байт SEID идентифицирует безопасную среду, в которой правила доступа ссылаются на применяемый байт ARR.

Байт ARR текущей SE указывает правила доступа, действительные для текущего доступа к DF приложения.

Примечание - Если SE установлена в форме команды MANAGE SECURITY ENVIRONMENT, то SE по умолчанию будет текущая SE.

5.4.4 Элементы данных «обеспечение безопасности»

В настоящем разделе определено множество элементов данных «обеспечение безопасности» с правилами, определяющими метод обработки их данных. Элементы данных «обеспечение безопасности» расширяют и оптимизируют информационные объекты «управляющие ссылки». Карта может обеспечить базовую поддержку механизмов защиты, которые выполняет приложение. Приложения могут найти их по ссылке для безопасного обмена сообщениями и для операций по защите информации (см. ИСО/МЭК 7816-8 [4]). В настоящем разделе не определены некоторые характеристики элементов данных «обеспечение безопасности», например их длина, а также алгоритмы, которые изменяют их значение.

Принципы. Карта должна поддерживать и использовать значение элементов данных «обеспечение безопасности» следующим образом:

• обновление совершается с новыми значениями, либо вычисленными картой, либо предоставленными внешними устройствами, в соответствии со специальным правилом для специального типа элемента данных «обеспечение безопасности»;
• обновление выполняется до того, как какой-нибудь результат будет создан для команды, вызывающей обновление. Обновление не зависит от состояния завершения команды. Если значение должно использоваться приложением в операции, которая вызывает обновление, то обновление выполняется до того, как значение будет использовано;
• доступ к элементам данных «обеспечение безопасности», связанных с конкретным приложением, ограничен функциями, выполняемыми этим специфичным приложением.

Примечание - Реальная безопасность, достигаемая в паре команда-ответ, прежде всего, зависит от алгоритмов и протоколов, определяемых приложением; карта обеспечивает поддержку только с этими элементами данных и соответствующими правилами применения.

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

• счетчик сессий карты увеличивается один раз во время активации карты;
• идентификатор сессии вычисляется через счетчик сессий карты и из данных, предоставленных внешними устройствами.

Определены два типа значений прогрессии:

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

Ссылки. Карта может обеспечить доступ к значениям элементов данных «обеспечение безопасности» следующим образом:

• EF может присутствовать в MF, например для счетчика сессий карт, или в DF приложения, например, для значений прогрессии, связанных с конкретным приложением;
• вспомогательные информационные объекты (теги '88', '92', '93', см. таблицу 33) могут присутствовать в шаблоне управляющих ссылок. Эти теги могут использоваться, если SE поддерживает однозначное использование этих элементов данных;
• в межотраслевом шаблоне, связанном с тегом '7A', контекстно-зависимый класс (первый байт от '80' до 'BF') зарезервирован для информационного объекта «обеспечение безопасности», как перечислено в таблице 26.

Таблица 26

Информационные объекты «обеспечение безопасности»

6 Безопасный обмен сообщениями

Безопасный обмен сообщениями (SM) защищает все (или части) пары команда-ответ, или сцепление последовательных полей данных (сцепление команд, см. 5.1.1.1; использование SW1, установленного на '61'), посредством обеспечения двух основных защитных функций: конфиденциальности данных и аутентификации данных. Безопасный обмен сообщениями достигается путем применения одного или большего числа механизмов защиты. Возможно идентифицированный в явном виде с помощью шаблона «идентификатор криптографического механизма» (см. 5.4.2) в параметрах управления каким-либо DF (см. 5.3.3), каждый механизм защиты включает в себя криптографический алгоритм, режим работы, ключ, аргумент (входные данные) и, зачастую, исходные данные.

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

6.1 Поля SM и информационные объекты SM

Любое поле данных команды или ответа в формате SM, а также шаблон SM (тег '7D') являются полем SM. Каждое поле SM должно кодироваться в BER-TLV (см. 5.2.2), где контекстно-зависимый класс (первый байт от '80' до 'BF') зарезервирован для информационного объекта SM. В паре команда-ответ формат SM может быть выбран или неявно, т.е. он известен до вызова команды, или явно, т.е. он указан CLA (см. 5.1.1).

Примечание - Сцепление команд и/или использование SW1, установленного на '61', вызывает последовательность команд, в которых поля данных (и, следовательно, информационные объекты) могут разбиваться на более маленькие последовательные поля данных. В таком случае, при использовании формата SM, сцепление всех последовательных полей данных в одном направлении в той же последовательности образует поле SM.

В таблице 27 показаны информационные объекты SM, определенные в настоящем стандарте, все в контекстно-зависимом классе. Некоторые информационные объекты SM (теги '82', '83', 'B0', 'B1' SM) являются рекурсивными, т.е. поле простого значения является полем SM.

Таблица 27

Информационные объекты SM

В каждом поле SM бит 1 последнего байта поля тега (контроль по четности тега) каждого информационного объекта SM (контекстно-зависимый класс) указывает, должны ли информационные объекты SM быть включены (бит 1 установлен на 1, номер тега нечетный) или не включены (бит 1 установлен на 0, номер тега четный) при вычислении элементов данных для аутентификации (криптографическая контрольная сумма, см. 6.2.3.1, или цифровая подпись, см. 6.2.3.2). Информационные объекты других классов, если представлены, (например, межотраслевые информационные объекты) должны быть включены при вычислении. Если происходит такое вычисление, то элементом данных должно быть поле значения информационного объекта SM для аутентификации (тег SM '8E', '9E') в конце поля SM.

Существует две категории информационных объектов:

• каждый основной информационный объект SM (см. 6.2) передает либо простое значение, либо входные или результирующие данные о механизме защиты;
• каждый вспомогательный информационный объект SM (см. 6.3) передает шаблон управляющих ссылок, или идентификатор безопасной среды, или шаблон описателя ответа.

Примечание — Основные информационные объекты SM также используются для управления операций по защите информации (см. ИСО/МЭК 7816-8 [4]). Вспомогательные информационные объекты SM также используются для управления безопасной средой (см. 7.5.11). Общий подход к защите с использованием безопасного обмена сообщениями выделяет несколько вопросов, относящихся к обеспечению безопасности, по операциям по защите информации. В приложении B проиллюстрировано взаимодействие двух подходов.

6.2 Основные информационные объекты SM

6.2.1 Информационные объекты SM для инкапсуляции простых значений

Для полей SM и для данных, не закодированных в BER-TLV, инкапсуляция является обязательной. Она не является обязательной для информационных объектов BER-TLV, не включающих в себя SM. В таблице 28 показаны информационные объекты SM для инкапсуляции простых значений.

Таблица 28

Информационные объекты SM для инкапсуляции простых значений

6.2.2 Информационные объекты SM для конфиденциальности

В таблице 29 показаны информационные объекты SM для конфиденциальности

Таблица 29

Информационные объекты SM для конфиденциальности

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

• для вычисления криптограммы, которой должен предшествовать индикатор заполнения незначащей информацией, механизм по умолчанию представляет собой блочное шифрование в режиме «электронный кодовый справочник», который может включать в себя заполнение блоков данных незначащей информацией. Заполнение незначащей информацией для конфиденциальности оказывает влияние на передачу, криптограмма (один или большее число блоков) получается длиннее простого значения;
• для вычисления криптограммы, которой не должен предшествовать байт индикатора заполнения незначащей информацией, механизм по умолчанию представляет собой поточное шифрование. В этом случае криптограмма является результатом операции сложения «Исключающее ИЛИ», выполняемой над строкой байтов данных, подлежащих сокрытию, и скрывающей строкой той же длины. Сокрытие, таким образом, не требует заполнения незначащей информацией, а строкой байтов данных восстанавливается при помощи той же операции.

Если простое значение не закодировано в BER-TLV, заполнение незначащей информацией и/или информационное наполнение должно иметь индикацию. Если оно применяется, но индикации нет, то для него действуют правила, определяемые в 6.2.3.1. В таблице 30 показан байт индикатора заполнения незначащей информацией/с информационным наполнением.

Таблица 30

Байт индикатора заполнения незначащей информацией/с информационным наполнением

6.2.3 Информационные объекты SM для аутентификации

В таблице 31 показаны информационные объекты SM для аутентификации

Таблица 31

Информационные объекты SM для аутентификации

6.2.3.1 Элемент данных «криптографическая контрольная сумма»

Вычисление криптографической контрольной суммы предусматривает наличие исходного контрольного блока, секретного ключа и или алгоритма блочного шифрования (см. ИСО/МЭК 18033 [18]), или хэш-функции (см. ИСО/МЭК 10118 [12]).

Метод вычисления может быть частью системной спецификации. С другой стороны, шаблон «идентификатор криптографического механизма», см. 5.4.2, может идентифицировать стандарт (например, ИСО/МЭК 9797-1 [7]), устанавливающий метод вычисления.

Если не указано иное, должен использоваться следующий метод вычисления. Алгоритм под управлением связанного с ним ключа, по существу, преобразует блок текущего ввода из k байтов (обычно 8, 16 или 20) в блок текущего вывода той же длины. Вычисление выполняется последовательно по этапам.

Начальный этап. Начальный этап должен задать один из следующих блоков в качестве исходного контрольного блока:

• нулевой блок, т.е. k байтов, установленных на '00';
• связующий блок, т.е. результат предыдущих вычислений, а именно: для команды — результирующий контрольный блок предшествующей команды, для ответа — результирующий контрольный блок предшествующего ответа;
• блок с начальным значением, предоставленный, например, внешним устройством;
• вспомогательный блок, являющийся результатом преобразования вспомогательных данных под управлением ключа. Если вспомогательные данные составляют менее k байтов, то они озаглавливаются битами, установленными в ноль, до достижения длины блока.

Промежуточный этап(ы). Заголовок команды (CLA INS P1 P2) может быть инкапсулирован для защиты (тег SM '89'). Однако если биты с 8 по 6 в CLA установлены на 000, а биты с 4 по 3 на 11 (см. 5.1.1), то первый блок данных состоит из заголовка команды (CLA INS P1 P2), за которым следуют один байт, установленный на '80' и k-5 байт, установленных на '00'.

Криптографическая контрольная сумма должна включать любой информационный объект «безопасный обмен сообщениями», имеющий нечетный номер тега, и любой информационный объект с первым байтом от '80' до 'BF'. Эти информационные объекты должны быть включены поблочно в текущий контрольный блок. Разбивка на блоки данных должна осуществляться по следующим правилам:

• объединение в блоки должно быть непрерывным на границе между смежными информационными объектами, подлежащими включению;
• заполнение незначащей информацией должно применяться в конце каждого подлежащего включению информационного объекта, за которым либо следует информационный объект, не подлежащий включению, либо отсутствует дальнейший информационный объект. Незначащая информация состоит из одного обязательного байта, установленного на '80', за которым, если требуется, должны следовать от 0 до k — 1 байтов, установленных на '00', пока соответствующий блок данных не будет заполнен k байтами. Заполнение незначащей информацией для аутентификации не оказывает влияния на передачу, поскольку заполняющие байты не должны передаваться.

В таком механизме, режимом работы является «последовательное блочное шифрование» (см. ИСО/МЭК 10116 [11]). Первый ввод представляет собой операцию сложения «Исключающее ИЛИ» над исходным контрольным блоком и первым блоком данных. Первый вывод является результатом первого ввода. Текущий ввод представляет собой операцию сложения «Исключающее ИЛИ» над предыдущим выводом и текущим блоком данных. Текущий вывод является результатом текущего ввода.

Заключительный этап. Результирующий контрольный блок является последним выводом. Заключительный этап выделяет криптографическую контрольную сумму (первые m байтов, но не менее четырех) из результирующего контрольного блока.

6.2.3.2 Элемент данных «цифровая подпись»

Схемы цифровой подписи основываются на асимметричных криптографических методах (см. ИСО/МЭК 9796 [6], ИСО/МЭК 14888 [16]). Вычисление предполагает использование хэш-функции (см. ИСО/МЭК 10118 [12]). Ввод данных состоит из поля значения информационного объекта ввода цифровой подписи, либо из сцепления полей значения информационных объектов, формирующих шаблон ввода цифровой подписи. Ввод данных может определяться согласно механизму, определяемому в 6.2.3.1.

6.3 Вспомогательные информационные объекты SM

В таблице 32 показаны вспомогательные информационные объекты SM.

Таблица 32

Вспомогательные информационные объекты SM

6.3.1 Шаблоны управляющих ссылок

Определены шесть шаблонов управляющих ссылок: действительный для аутентификации (AT), для согласования ключей (KAT), хэш-кода (HT), криптографической контрольной суммы (CCT), цифровой подписи (DST) и конфиденциальности (CT), использующие или симметричные, или асимметричные криптографические методы (CT-sym и CT-asm).

Каждый механизм защиты включает в себя в своем режиме работы криптографический алгоритм и использует ключ и, возможно, исходные данные. Эти элементы выбирают либо неявно, т.е. они известны до выдачи команды, либо явно, т.е. с помощью информационного объекта «управляющие ссылки», вложенного в шаблоны управляющих ссылок. В рамках шаблонов управляющих ссылок контекстно-зависимый класс (первый байт от '80' до 'BF') зарезервирован для информационных объектов «управляющие ссылки».

В поле SM последняя возможная позиция шаблона управляющих ссылок — непосредственно перед первым информационным объектом, для которого применяется указываемый механизм. Например, последняя возможная позиция шаблона, действительного для криптографической контрольной суммы (CCT) располагается непосредственно перед первым информационным объектом для включения его при вычислении.

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

6.3.2 Информационные объекты «управляющие ссылки» в шаблонах управляющих ссылок

Каждый шаблон управляющих ссылок (CRT) — это набор информационных объектов «управляющие ссылки»: ссылка на криптографический механизм, ссылка на файл и ключ, ссылка на исходные данные, квалификатор применимости и, только в шаблоне управляющих ссылок для конфиденциальности ссылка на содержание криптограммы.

• Ссылка на криптографический механизм обозначает криптографический алгоритм в режиме работы. Контрольные параметры любого DF (см. тег 'AC' в таблице 12) может содержать шаблон «идентификатор криптографического механизма» (см. 5.4.2). Каждый из них указывает на значение ссылки криптографического механизма.
• Ссылка на файл (то же кодирование, что и в 5.3.1.2) обозначает файл, в котором ссылка на ключ действительна. Если ссылка на файл не представлена, то ссылка на ключ действительна в текущем DF, возможно, в DF приложения. Ссылка на ключ однозначно идентифицирует ключ, подлежащий использованию.
• Ссылка на исходные данные, при использовании для криптографических контрольных сумм, указывает исходный контрольный блок. Если ссылка на исходные данные не представлена и не выбран неявным образом исходный контрольный блок, то применяют нулевой блок.

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

В таблице 33 перечислены информационные объекты «управляющие ссылки» и указаны к каким шаблонам управляющих ссылок они относятся. Все информационные объекты «управляющие ссылки» находятся в контекстно-зависимом классе.

Таблица 33

Информационные объекты «управляющие ссылки» в шаблонах управляющих ссылок

В любом шаблоне управляющих ссылок шаблон применимости ключа (тег 'A3') может связать ссылку на файл и ключ со счетчиком применимости ключа и/или счетчиком повтора ключа (см. таблицу 34).

Таблица 34

Информационные объекты «применимость ключа»

В любом шаблоне управляющих ссылок для аутентификации (AT), для согласования ключей (KAT), для криптографической контрольной суммы (CCT), для конфиденциальности (CT) или для цифровой подписи (DST) байт квалификатора применимости (тег '95') может определять использование шаблона либо в качестве условия секретности (см. 5.4.3.2 и таблицу 23), либо в соответствии с командой MANAGE SECURITY ENVIRONMENT (см. 7.5.11). В таблице 35 показан байт квалификатора применимости.

Таблица 35

Байт квалификатора применимости

В любом шаблоне управляющих ссылок для конфиденциальности (CT), ссылка на содержание криптограммы (тег '8E') может установить содержание криптограммы. Первый байт поля значения обязателен; его называют байтом описателя криптограммы. В таблице 36 показан байт описателя криптограммы.

Таблица 36

Байт описателя криптограммы

6.3.3 Безопасная среда

В настоящем разделе определена безопасная среда (SE) для обращения к криптографическим алгоритмам, режимам работы, протоколам, процедурам, ключам и дополнительным данным, необходимым для безопасного обмена сообщениями и для операций по защите информации (см. ИСО/МЭК 7816-8 [4]). SE состоит из элементов данных, сохраненных в карте или полученных в результате некоторого вычисления, которые должны обрабатываться специальными алгоритмами. SE может содержать механизм для инициализации непостоянных данных, которые должны использоваться в среде, например сеансовый ключ. SE может обеспечить управление обработкой результатов вычислений, например хранение в карте. Межотраслевой шаблон SE (тег '7B') описывает SE.

Идентификатор SE. Идентификатор SE (байт SEID) может ссылаться на любую безопасную среду, например для обращения к безопасному обмену сообщениями, а также для хранения и восстановления используют команды MANAGE SECURITY ENVIRONMENT (см. 7.5.11).

• Пока приложением не определено иначе, значение '00' обозначает, что среда пустая, т.е. безопасный обмен сообщениями и аутентификация не определены.
• Значение 'FF' обозначает, что никакая операция не может быть выполнена в данной среде.
• Пока приложением не определено иначе, значение '01' зарезервировано для SE, установленной по умолчанию, которая доступна всегда. В настоящем разделе не определено содержание SE, установленной по умолчанию; она может быть пустой.
• Значение 'EF' зарезервировано для использования в будущем.

Компоненты. Шаблоны управляющих ссылок (CRT) могут описывать различные компоненты SE. Любая относительная управляющая ссылка (файлы, ключи или данные), установленная с помощью механизма в определении среды, должна быть разрешена относительно DF, выбранного перед использованием механизма. В рамках SE компоненты могут иметь два аспекта: один действителен для SM в поле данных команды, а другой — для SM в поле данных ответа.

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

• некоторые компоненты являются частью SE, установленной по умолчанию и связанной с текущим DF;
• некоторые компоненты передаются в команды, используя безопасный обмен сообщениями;
• некоторые компоненты передаются в команды MANAGE SECURITY ENVIRONMENT;
• некоторые компоненты вызываются байтом SEID в команде MANAGE SECURITY ENVIRONMENT.

Текущая SE действительна до тех пор, пока происходит «горячее» восстановление или деактивация контактов (см. ИСО/МЭК 7816-3), изменение контекста (например, при выборе другого DF приложения) или установка команды MANAGE SECURITY ENVIRONMENT или замена текущей SE.

В SM информационные объекты «управляющая ссылка», передаваемые в CRT, должны иметь преимущественное право перед любым соответствующим информационным объектом «управляющая ссылка», присутствующим в текущей SE.

Авторизация держателя сертификата. Процедуры авторизации могут использовать сертификаты, верифицируемые картой, т.е. шаблоны, которые могут интерпретироваться и верифицироваться картой с помощью операции VERIFY CERTIFICATE, используя открытый ключ (см. ИСО/МЭК 7816-8 [4]). В таком сертификате авторизация держателя сертификата (например, идентификатор назначения) может быть передана в межотраслевой элемент данных, связанный с тегом '5F4C'. Если такой элемент данных используется в условиях секретности для того, чтобы выполнить доступ к данным или функциям, то информационный объект (тег '5F4C') должен присутствовать в шаблоне управляющих ссылок аутентификации (AT), описывающем процедуру аутентификации.

Примечание — В первом издании ИСО/МЭК 7816-9 [4], тег '5F4B' ссылается на авторизацию держателя сертификата (элемент данных из пяти или более байт). В изменении № 1 к первому изданию ИСО/МЭК 7816-9 тег '5F4B' ссылается на идентификатор изготовителя интегральной схемы (однобайтовый элемент данных). В результате тег '5F4B' исключен в серии ИСО/МЭК 7816.

Управление доступом. Карта может хранить безопасную среду, используемую для управления доступом в файлах EF (см. тег '8D' в таблице 12), содержащих межотраслевые шаблоны SE (тег '7B'). В рамках межотраслевых шаблонов SE (тег '7B') контекстно-зависимый класс (первый байт от '80' до 'BF') зарезервирован для информационных объектов «безопасная среда». Как перечислено в таблице 37, для каждой включенной SE шаблон «безопасная среда» содержит информационный объект «байт SEID» (тег '80'), дополнительный информационный объект «байт LCS» (тег '8A'), один или несколько дополнительных шаблонов «идентификатор криптографического механизма» (тег 'AC') и один или несколько CRT (теги 'A4', 'A6', 'AA', 'B4', 'B6', 'B8', как теги SM).

Таблица 37

Информационные объекты «безопасная среда»

Если информационный объект «байт LCS» присутствует в шаблоне SE, то он указывает какое состояние жизненного цикла SE действительно. Если SE используется для управления доступом, например, для управления доступом файла, то байт LCS файла и байт LCS для SE должны совпадать. Если информационный объект «байт LCS» не присутствует, то SE действительна для активированного рабочего состояния.

В шаблоне SE, если CRT содержит несколько информационных объектов с тем же тегом (например, информационные объекты, определяющие ссылку на ключ), то, как минимум, один из информационных объектов должен быть выполнен (условие ИЛИ).

Извлечение SE. Любой CRT в текущей SE может быть извлечен с помощью команды GET DATA с P1-P2, установленными на '004D' (расширенный список заголовка, см. 8.5.1), и поля данных команды, состоящего из шаблона SE (тег '7B'), который сцепляет одну или несколько пар, каждая из которых состоит из тега CRT, за которым следует '80' (см. 8.5.1 для использования длины, установленной на '80' в расширенном списке заголовка).

6.3.4 Шаблон описателя ответа

Каждое поле данных команды может содержать шаблон описателя ответа. Шаблон описателя ответа, если он представлен в поле данных команды, должен указывать информационные объекты SM, необходимые в поле данных ответа. Внутри шаблона описателя ответа механизмы защиты пока не применяют; получатель должен применить их для построения поля данных ответа. Элементы защиты (алгоритмы, режимы операций, ключи и исходные данные), используемые для обработки поля данных команды, могут отличаться от элементов защиты, используемых для выработки поля данных последующего ответного сообщения. Должны применяться следующие правила:

• карта должна заполнять каждый пустой простой информационный объект SM;
• каждый CRT, присутствующий в шаблоне описателе ответа, должен быть представлен в ответе на том же месте с тем же информационными объектами «управляющие ссылки» для механизмов защиты, файла и ключей: - если шаблон описателя ответа предоставляет вспомогательные данные, тогда соответствующий информационный объект в ответе должен быть пустым; - если в шаблоне описателя ответа присутствует пустой ссылочный информационный объект для вспомогательных данных, то в ответе он должен быть заполнен; - применяя соответствующие механизмы защиты вместе с выбранными элементами защиты, карта должна осуществлять вывод всех запрашиваемых основных информационных объектов SM.

6.4 Влияние SM на пары команда-ответ

На рисунке 5 показана пара команда-ответ.

Рисунок 5 — Пара команда-ответ

Для обеспечения защиты пары команда-ответ межотраслевого класса (см. 5.1.1) применяют следующие правила, т.е. при переключении либо бита 1 из состояния 0 в состояние 1 в CLA, где биты 8, 7 и 6 установлены на 000, либо бита 6 из состояния 0 в состояние 1 в CLA, где биты 8 и 7 установлены на 01. Запись CLA* означает, что безопасный обмен сообщениями показан в CLA.

• Защищенное поле данных команды — поле SM; оно должно формироваться следующим образом:
• если поле данных команды присутствует (N_{c}>0) , то либо информационный объект «простое значение» (теги SM '80', '81', 'B2', 'B3'), либо информационный объект для конфиденциальности (теги SM '84', '85', '86', '87') должны передавать N_{c} байты; - заголовок команды (четыре байта) может быть инкапсулирован для защиты (тег SM '89');
• если поле L_{e} присутствует, то новое поле L_{e} (содержащее только установленные на '00' байты) и информационный объект L_{e} (теги SM '96', '97') должны присутствовать. И ноль, и пустой информационный объект L_{e} означают максимум, т.е. 256 или 65536, в зависимости от того является ли новое поле L_{e} коротким или расширенным.
• Защищенное поле данных ответа — поле SM; оно должно формироваться следующим образом: - информационный объект «простое значение» (теги SM '80', '81', 'B₂', 'B₃'), если имеется, или информационный объект для конфиденциальности (теги SM '84', '85', '86', '87') передают байты данных ответа; - информационный объект «состояние обработки» (тег SM '99'),

если  имеется,  передает  SW1-SW2,  инкапсулированные  для  защиты.  Пустой
информационный   объект   "состояние   обработки"   означает,  что  SW1-SW2

установлены на '9000'.

На рисунке 6 показана соответствующая защищенная пара команда-ответ.

Рисунок 6 — Защищенная пара команда-ответ

Если бит 1 в INS установлен в состояние 1 (нечетный код INS, см. 5.1.2), то незащищенные поля данных кодируются в BER-TLV и теги SM 'B2', 'B3', '84' и '85' должны использоваться для их инкапсуляции. В противном случае, так как формат для полей данных для защиты не всегда видим, то рекомендованы теги SM '80', '81', '86' и '87'.

• Защищенные поля данных — поля SM; они могут содержать дополнительные или другие информационные объекты SM, например криптографическую контрольную сумму (тег SM '8E') или цифровую подпись (тег SM '9E') на конце.
• Новое поле Lc кодирует число байт в защищенном поле данных команды.
• Новое поле Le должно быть пустым, если не ожидается поле данных в защищенном поле данных ответа; в противном случае оно должно содержать только установленные на '00' байты;
• Завершитель ответа указывает состояние принимающей стороны после обработки защищенной команды. Могут происходить следующие специфические состояния ошибок:
• если SW1-SW2 установлены на '6987', то ожидаемый информационный объект «безопасный обмен сообщениями» отсутствует;
• если SW1-SW2 установлены на '6988', то информационный объект «безопасный обмен сообщениями» с ошибкой.

В приложении B приведены проиллюстрированные примеры безопасного обмена сообщениями.

7 Команды для обмена

В настоящем разделе определены команды для обмена, представленные ниже:

1. выбор;

2. обработка блока данных;

3. обработка записи;

4. обработка информационного объекта;

5. обработка основной защиты;

6. обработка передачи.

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

7.1 Выбор

После ответа на восстановление MF или DF приложения неявно вызывают с помощью основного логического канала (см. 5.1.1.2), пока не будет определено иначе в байтах предыстории (см. 8.1.1) или в строке исходных данных (см. 8.1.2)

7.1.1 Команда SELECT

После своего завершения команда SELECT открывает логический канал (см. 5.1.1.2), пронумерованный в CLA (см. 5.1.1), если он до этого не был открыт, и устанавливает текущую структуру в рамках этого логического канала. Последующие команды могут неявно обращаться к текущей структуре через этот логический канал.

• Выбранный DF (MF или DF приложения) становится текущим в логическом канале. К предыдущему выбранному DF, если он имеется, больше не обращаются с помощью этого логического канала, и он становится предшествующим текущим DF.
• Выбор EF устанавливает пару текущих файлов: EF и его родительский DF.

Если не дается иных указаний, то к каждому логическому каналу в рамках иерархии файлов DF применяют следующие правила:

• если заменяется текущий EF, или текущего EF больше нет, состояние защиты, если оно применялось, ориентированное на предшествующий текущий EF, утрачивается;
• если текущий DF является потомком предшествующего текущего DF или ему идентичен, состояние защиты, ориентированное на предшествующий текущий DF, сохраняется;
• если текущий DF не является потомком предшествующего текущего DF и не идентичен ему, состояние защиты, ориентированное на предшествующий текущий DF, утрачивается. Состояние защиты, общее для всех общих предков предшествующего и нового текущего DF, сохраняется.

Пара команда-ответ SELECT представлена в таблице 38.

Таблица 38

Пара команда-ответ SELECT

Если P1 установлен на '00', то карта распознает, является ли выбираемый файл файлом MF, DF или EF, либо благодаря особому кодированию идентификатора файла, либо из-за контекста выполнения команды.

• Если P2 установлен на '00' и поле данных команды предоставляет идентификатор файла, то он должен быть уникальным в следующих трех средах: непосредственных потомках текущего DF, родительских DF, непосредственных потомках родительского DF.
• Если P2 установлен '00' и поле данных пустое или установлено на '3F00', то осуществляется выбор MF.

Если P1 установлен на '04', то поле данных представляет собой имя DF, возможно, укороченное справа, которым может быть идентификатор приложения (см. 8.2.1.2). Если выбор по укороченному имени DF поддерживается, то следующие одна за другой такие команды с одним и тем же полем данных должны выбирать файлы DF, чьи имена совпадают с их полем данных, т.е. с него начинаются. Если карта принимает команду SELECT с пустым полем данных, то может осуществляться последовательный выбор всех файлов DF или их подмножества.

Если поле Le содержит только установленные на '00' байты, то все байты, соответствующие опциям выбора должны быть выданы в пределах максимума 256 для короткого поля Le или 65536 для расширенного поля Le. Если поле Le отсутствует, т.е. нет контрольной информации файла для выдачи, то поле данных ответа должно также отсутствовать.

Таблица 39

P1

Таблица 40

P2

7.1.2 Команда MANAGE CHANNEL

После своего завершения команда MANAGE CHANNEL открывает и закрывает логический канал (см. 5.1.1.2), отличный от основного канала, т.е. канал нумеруется от одного до девятнадцати (большие номера зарезервированы для использования в будущем).

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

• Если бит 8 байта P1 установлен на 0 (т.е. P1 установлен на '00', так как остальные семь бит зарезервированы для использования в будущем), то команда MANAGE CHANNEL должна открыть канал с номером от одного до девятнадцати следующим образом:
• если P2 установлен на '00', то поле Le должно быть установлено на '01' и поле данных ответа должно состоять из одиночного байта для кодирования ненулевого канала, назначенного картой от '01' до '13';
• если P2 принимает значения от '01' до '13', то он кодирует назначенный извне номер ненулевого канала, а поле Le должно отсутствовать.
• После того, как функция открытия приводится в действие с основного логического канала (кодирование нуля в CLA так же, как и номера канала).
• После того, как функция открытия приводится в действие с неосновного логического канала (кодирование ненулевого номера канала в CLA), текущий DF на канал, пронумерованный в CLA, должен стать текущим в новом канале.

Функция закрытия в явной форме закрывает логический канал, отличный от основного канала. Поле Le должно отсутствовать. После закрытия логический канал должен быть доступен для повторного использования.

• Если бит 8 байта P1 установлен на 1 (т.е. P1 установлен на '80', так как остальные семь бит зарезервированы для использования в будущем), то команда MANAGE CHANNEL должна закрыть канал с номером от 1 до девятнадцати следующим образом:
• если P2 установлен на '00', то канал, пронумерованный в CLA (ненулевой номер канала) должен быть закрыт;
• если P2 имеет значения от '01' до '13', то канал, пронумерованный в P2, должен быть закрыт.

Примечание - Функция закрытия может быть прервана, если CLA не указывает ни основной канал, ни канал, пронумерованный в P2.

Пара команда-ответ MANAGE CHANNEL представлена в таблице 41.

Таблица 41

Пара команда-ответ MANAGE CHANNEL

7.2 Обработка единицы данных

7.2.1 Единицы данных

В рамках каждого EF, поддерживающего единицы данных, обращение к любой единице данных должно осуществляться при помощи смещения. Начиная с нуля для первой единицы данных файла EF, смещение увеличивается на единицу для каждой последующей единицы данных. Элемент данных «смещение» бинарно кодирован при минимальном числе байт. Ссылка на единицу данных, не содержащуюся в EF, является ошибкой.

Карта может предоставить байт кодирования данных (см. таблицу 87) в байтах предыстории (см. 8.1.1), в EF.ATR (см. 8.2.1.1) и в контрольной информации любого файла (см. тег '82' в таблице 12). Байт кодирования данных фиксирует размер единицы данных.

• Если карта предоставляет байты кодирования данных в разных местах, то байт кодирования данных, действительный для данного EF, находится на ближайшей позиции к этому EF, в пределах пути от MF до этого EF.
• В отсутствие индикации в рамках пути, размер единицы данных — один байт (значение по умолчанию) для этого EF.

7.2.2 Общие положения

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

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

INS P1 P2 — Все команды этой группы должны использовать бит 1 для INS и бит 8 для P1 следующим образом:

• если бит 1 для INS установлен на 0, а бит 8 для P1 — на 1, то биты 7 и 6 для P1 устанавливают на 00 (RFU), биты с 5 по 1 для P1 кодируют короткий идентификатор, а P2 (восемь бит) кодируют смещение от нуля до 255;
• если бит 1 для INS установлен на 0, а бит 8 для P1 — на 0, то P1-P2 (пятнадцать бит) кодируют смещение от нуля до 32767;
• если бит 1 для INS установлен на 1, то P1-P2 должны идентифицировать EF. Если первые семь бит в P1-P2 установлены на 0 и если биты с 5 по 1 не равны и если карта и/или EF поддерживает выбор с помощью короткого идентификатора EF, то биты с 5 по 1 для P2 кодируют короткий идентификатор EF (число от одного до тридцати). В противном случае, P1-P2 — это идентификатор файла. P1-P2, установленные на '0000' идентифицируют текущий EF. Как минимум один информационный объект «смещение» с тегом '54' должен присутствовать в поле данных команды. Данные, если они присутствуют в поле данных команды или ответа, должны быть инкапсулированы в произвольный информационный объект с тегом '53' или '73'.

В этой группе команд SW1-SW2, установленные на '63CX', указывают на успешный обмен состояния памяти, но после внутренней программы повторений; 'X' > '0' кодирует число повторных попыток; 'X' = '0' означает, что счетчик не предусмотрен.

7.2.3 Команда READ BINARY

Поле данных ответа передает содержимое (его часть) файла EF, поддерживающего единицы данных.

Если поле Le содержит только установленные на '00' байты, то все байты до конца файла должны считываться в пределах 256 для короткого поля Le, или 65536 для расширенного поля Le.

Таблица 42

Пара команда-ответ READ BINARY

7.2.4 Команда WRITE BINARY

Команда инициирует одну из следующих операций в EF в соответствии с атрибутами файла:

• однократной записи бит, передаваемых в поле данных команды (команда должна прерываться, если строка единиц данных не находится в логическом состоянии после стирания);
• логического OR над битами, уже присутствующими в карте, и битами, передаваемыми в поле данных команды (логическое состояние битов файла после стирания представлено нулем);
• логического AND над битами, уже присутствующими в карте, и битами, передаваемыми в поле данных команды (логическое состояние битов файла после стирания представлено единицей).

По умолчанию, т.е. когда байт кодирования данных (см. таблицу 87) отсутствует в байтах предыстории (см. 8.1.1), в EF.ATR (см. 8.2.1.1) и в контрольных параметрах (см. тег '82' в таблице 12) каждого файла в пределах пути от MF до переданного EF, логическое OR должно применяться для этого EF.

Пара команда-ответ WRITE BINARY представлена в таблице 43.

Таблица 43

Пара команда-ответ WRITE BINARY