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

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

Группа Э46

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


Информационная технология

Карты идентификационные

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

Часть 4

Межотраслевые команды для обмена

Information technology. Identification cards. Integrated circuit(s) cards with contacts

Part 4. Interindustry commands for interchange

ОКС 35.240.15
ОКП 40 8470

Дата введения 2005-01-01

     
     
Предисловие

1 РАЗРАБОТАН Техническим комитетом по стандартизации ТК 22 "Информационные технологии”, Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении" (ВНИИНМАШ), ОАО "Московский комитет по науке и технологиям"
     
     ВНЕСЕН ТК 22 "Информационные технологии"
     

2 ПРИНЯТ И ВВЕДЕН В ДЕЙСТВИЕ Постановлением Госстандарта России от 9 марта 2004 г. N 116-ст
     

3 Настоящий стандарт представляет собой аутентичный текст международного стандарта ИСО/МЭК 7816-4:1995 "Информационная технология. Карты идентификационные. Карты на интегральной(ых) схеме(ах) с контактами. Часть 4. Межотраслевые команды для обмена" с Изменением N 1 (1997 г.)
     

4 ВВЕДЕН ВПЕРВЫЕ
     
     

Введение

Введение

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

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

     Настоящий стандарт устанавливает:
     
     - содержание сообщений (команд и ответов), передаваемых устройством сопряжения карте и обратно;
     
     - структуру и содержание байтов предыстории, посылаемых картой во время ответа на восстановление;
     
     - структуру файлов и данных, прослеживаемую на стыке между картой и устройством сопряжения при обработке межотраслевых команд;
     
     - методы доступа к файлам и данным, содержащимся в карте;
     
     - архитектуру безопасности, определяющую права доступа к файлам и данным, содержащимся в карте;
     
     - методы безопасного обмена сообщениями;
     
     - методы доступа к алгоритмам, обрабатываемым картой (исключая описание самих алгоритмов).
     
     Стандарт не распространяется на реализацию обмена данными внутри карты и/или внешнего окружения.
     
     Стандарт допускает дальнейшую стандартизацию дополнительных межотраслевых команд и архитектур безопасности.
     
     

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

     В настоящем стандарте использованы ссылки на следующие стандарты и классификатор:
     
     ГОСТ Р ИСО/МЭК 7816-6-2003 Карты идентификационные. Карты на интегральных схемах с контактами. Часть 6. Элементы данных для межотраслевого обмена
     
     ГОСТ Р ИСО/МЭК 8825-93 Информационная технология. Взаимосвязь открытых систем. Спецификация базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)
     
     ГОСТ Р ИСО/МЭК 10116-93 Информационная технология. Режимы работы для алгоритма -разрядного блочного шифрования
     
     ИСО/МЭК 7812-1:2000* Карты идентификационные. Идентификация эмитентов. Часть 1. Система нумерации
     
     ИСО/МЭК 7816-3:1997* Информационная технология. Карты идентификационные. Карты на интегральной(ых) схеме(ах) с контактами. Часть 3. Электронные сигналы и протоколы передачи
     
     ИСО/МЭК 7816-5:1994* Карты идентификационные. Карты на интегральной(ых) схеме(ах) с контактами. Часть 5. Система нумерации и процедура регистрации для идентификаторов приложений
     
     ИСО/МЭК 9796-2:1997* Информационная технология. Методы защиты. Схемы цифровой подписи, обеспечивающие восстановление сообщения. Часть 2. Механизмы, использующие хэш-функцию
     
     ИСО/МЭК 9796-3:2000* Информационная технология. Методы защиты. Схемы цифровой подписи, обеспечивающие восстановление сообщения. Часть 3. Механизмы, основанные на дискретном логарифме
     
     ИСО/МЭК 9797:1994* Информационная технология. Методы защиты. Механизм обеспечения целостности данных с применением криптографической контрольной функции, использующей алгоритм блочного шифрования
     
     ИСО/МЭК 9979:1999* Информационная технология. Методы защиты. Процедуры регистрации криптографических алгоритмов
     
     ИСО/МЭК 10118-1:2000* Информационная технология. Методы защиты. Хэш-функции. Часть 1. Общие положения
     
     ИСО/МЭК 10118-2:2000 Информационная технология. Методы защиты. Хэш-функции. Часть 2. Хэш-функции, использующие - битовое блочное шифрование
________________
     * Международные стандарты ИСО/МЭК - во ВНИИКИ Госстандарта России.
     
     ОК (МК (ИСО 3166) 004-97) 025-2001 Общероссийский классификатор стран мира
     
     

3 Определения

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

3.1 файл ответа на восстановление: Элементарный файл, который указывает рабочие характеристики карты.
     

3.2 пара команда-ответ: Набор из двух сообщений: команды и следующего за ней ответа.
     

3.3 единица данных: Наименьший набор битов, на который можно дать однозначную ссылку.
     

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

3.5 информационный объект: Информация, прослеживаемая на стыке между картой и устройством сопряжения, состоящая из тега, длины и значения (т.е. элемента данных). В настоящем стандарте информационные объекты именуются как информационные объекты BER-TLV, COMPACT-TLV и SIMPLE-TLV.
     

3.6 назначенный файл: Файл, содержащий контрольную информацию файла и, как возможность, свободную память для распределения. Он может быть родительским файлом элементарных (EF) и/или назначенных (DF) файлов.
     

3.7 имя DF: Строка байтов, которая уникальным образом идентифицирует назначенный файл в карте.
     

3.8 справочный файл: Элементарный файл, определяемый в ИСО/МЭК 7816-5.
     

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

3.10 контрольные параметры файла: Логические, структурные атрибуты и атрибуты секретности файла.
     

3.11 идентификатор файла: Двухбайтовое двоичное значение, используемое для обращения к файлу.
     

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

3.13 внутренний элементарный файл: Элементарный файл для хранения данных, интерпретируемых картой.
     

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

3.15 сообщение: Строка байтов, передаваемая устройством сопряжения карте или наоборот, исключая знаки, ориентированные на управление передачей, как определено в ИСО/МЭК 7816-3.
     

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

3.17 пароль: Данные, которые могут быть затребованы приложением от пользователя карты.
     

3.18 путь: Сцепление идентификаторов файлов без разграничения. Если путь начинается с идентификатора главного файла, то это абсолютный путь.
     

3.19 провайдер: Орган, имеющий или получивший право на создание назначенного файла в карте.
     

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

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

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

3.23 рабочий элементарный файл: Элементарный файл для хранения данных, не интерпретируемых картой.
     
     

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

В настоящем стандарте применяют следующие сокращения.
     
     APDU - блок данных прикладного протокола (Application protocol data unit).
     
     ATR - ответ на восстановление (Answer to reset).
     
     BER - базовые правила кодирования абстрактно-синтаксической нотации версии 1 (АСН.1) (Basic encoding rules of ASN.1), см. приложение Г.
     
     CLA - байт класса (Class byte).
     
     DIR - справочный (Directory).
     

DF - назначенный файл (Dedicated file).
     

EF - элементарный файл (Elementary file).
     
     FCI - контрольная информация файла (File control information).
     
     FCP - контрольный параметр файла (File control parameter).
     
     FMD - данные управления файлом (File management data).
     
     INS - командный байт (Instruction byte).
     

MF - главный файл (Master file).
     
     P1, P2 - байты параметров (Parameter bytes).
     
     PTS - выбор типа протокола (Protocol type selection).
     
     RFU - зарезервировано для будущего использования (Reserved for future use).
     

SM - безопасный обмен сообщениями (Secure messaging).
     
     SW1, SW2 - байты состояния (Status bytes).
     
     TLV - тег, длина, значение (Tag, length, value).
     
     TPDU - блок данных протокола передачи (Transmission protocol data unit).
     
     В настоящем стандарте применяют следующие обозначения.
     
     '0' - '9' и 'A' - 'F' - шестнадцать шестнадцатеричных цифр.
     
     () - значение байта .
     
      || - сцепление байтов (старший байт) и (младший байт).
     
     ( || ) - значение сцепления байтов и .
     
     # - номер.
     
     

5 Основные организационные структуры

5.1 Структуры данных

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

5.1.1 Организация файлов
     
     Настоящий стандарт поддерживает следующие две категории файлов:
     
     - назначенный файл (DF);
     
     - элементарный файл (EF).
     
     Логическая организация данных в карте представляет собой следующую структурную иерархию назначенных файлов:
     
     - DF в основании иерархии, называемый главным файлом (MF). MF является обязательным;
     
     - прочие DF, являющиеся необязательными.
     
     Определены следующие два типа файлов EF:
     
     - внутренние, предназначаемые для хранения данных, интерпретируемых картой, т.е. данных, анализируемых и используемых картой в целях управления и контроля;
     
     - рабочие, предназначаемые для хранения данных, не интерпретируемых картой, т.е. данных, подлежащих использованию исключительно внешним окружением.
     
     На рисунке 1 показан пример логической организации файлов в карте.
     

Рисунок 1 - Пример логической организации файлов

Рисунок 1 - Пример логической организации файлов

     

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

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

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

в) Обращение посредством короткого идентификатора EF
     
     Обращение к любому EF может быть осуществлено при помощи короткого идентификатора EF, кодируемого в пяти битах, представляющих значение от 1 до 30. Значение 0, используемое в качестве короткого идентификатора EF, указывает на выбираемый в текущий момент EF. Короткие идентификаторы файлов EF не могут быть использованы в последовательности пути или в качестве идентификатора файла (например, в команде ВЫБРАТЬ ФАЙЛ).
     

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

5.1.3 Структуры элементарных файлов
     
     Определены следующие структуры файлов EF:
     
     - прозрачная структура, при которой EF прослеживается на стыке между картой и устройством сопряжения как последовательность единиц данных;
     
     - структура из записей, при которой EF прослеживается на стыке между картой и устройством сопряжения как последовательность отдельно идентифицируемых записей.
     
     Для файлов EF со структурой из записей определены следующие атрибуты:
     
     - размер записей - либо фиксированный, либо переменный;
     
     - способ организации записей: либо в виде последовательного ряда (линейная структура), либо в виде кольца (циклическая структура).
     
     Карта должна поддерживать по меньшей мере один из следующих четырех методов структурирования файлов EF:
     
     - "прозрачный EF";
     
     - "линейный EF с записями фиксированного размера";
     
     - "линейный EF с записями переменного размера";
     
     - "циклический EF с записями фиксированного размера".
     
     На рисунке 2 представлены четыре структуры файлов EF, соответствующие четырем методам структурирования.
     

Рисунок 2 - Структуры файлов EF

     Примечание Стрелка указывает на последнюю сделанную запись.

Рисунок 2 - Структуры файлов EF

     

5.1.4 Методы обращения к данным
     
     Обращение к данным может осуществляться как к записям, единицам данных или информационным объектам. Предполагается, что данные должны храниться в виде одной непрерывной последовательности записей (в пределах EF со структурой из записей) или единиц данных (в пределах EF с прозрачной структурой). Обращение к записи или единице данных вне EF является ошибкой.
     
     Метод обращения к данным, метод нумерации записей и размер единиц данных являются характеристиками, зависящими от EF. Карта может давать соответствующие указания в ATR, файле ATR и контрольной информации любого файла. Если карта дает указания в нескольких местах, то действительным для данного EF является ближайшее к нему указание в пределах пути от MF до этого EF.
     

5.1.4.1 Обращение к записи
     
     В пределах каждого EF со структурой из записей обращение к каждой записи может осуществляться при помощи идентификатора записи и/или номера записи. Идентификаторы и номера записей представляют собой целые восьмибитовые числа без знака со значениями от '01' до 'FE'. Значение '00' зарезервировано для особых целей. Значение 'FF' является RFU.
     
     Обращение посредством идентификатора записи должно приводить в действие управление указателя записи. Процедура восстановления карты, команда ВЫБРАТЬ ФАЙЛ и любая команда, несущая разрешенный короткий идентификатор EF, могут воздействовать на указатель записи. Обращение посредством номера записи не должно воздействовать на указатель записи.
     

а) Обращение посредством идентификатора записи
     
     Каждый идентификатор записи предоставляется приложением. Если запись представляет собой информационный объект SIMPLE-TLV в поле данных сообщения (см. 5.4.4), то идентификатором записи является первый байт этого информационного объекта. В пределах EF со структурой из записей записи могут иметь один и тот же идентификатор, тогда данные, содержащиеся в записях, могут использоваться для их различения.
     
     Всякий раз, когда обращение осуществляется с идентификатором записи, должна быть указана логическая позиция целевой записи: первое или последнее вхождение записи, следующее или предыдущее вхождение по отношению к указателю записи.
     
     В пределах каждого EF с линейной структурой логические позиции должны последовательно присваиваться при осуществлении операции записи или операции присоединения записи, т.е. в порядке создания. Поэтому первая созданная запись будет находиться в первой логической позиции.
     

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

б) Обращение посредством номера записи
     
     В пределах каждого EF со структурой из записей номера записей являются уникальными и последовательными.
     
     В пределах каждого EF с линейной структурой номера записей должны последовательно присваиваться при осуществлении операции записи или операции присоединения записи, т.е. в порядке создания. Поэтому первая запись (запись номер один, запись # 1) будет представлять собой первую созданную запись.
     
     В пределах каждого EF с циклической структурой номера записей должны последовательно присваиваться в обратном порядке, т.е. первая запись (запись номер один, запись # 1) будет представлять собой последнюю созданную запись.
     
     Как для линейных, так и для циклических структур установлено следующее дополнительное правило: значение '00' должно относиться к текущей записи, т.е. к записи, зафиксированной указателем записи.
     

5.1.4.2 Обращение к единице данных
     

В пределах каждого EF с прозрачной структурой обращение к любой единице данных может осуществляться при помощи смещения (например, в команде СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ, см. 6.1), представляющего собой целое число без знака, ограниченное восемью либо 15 битами, что определяется опцией в соответствующей команде. Для первой единицы данных файла EF смещению присваивают значение 0, для каждой последующей единицы данных смещение увеличивается на единицу.
     
     По умолчанию, т.е. в том случае, если карта не дает никакого указания, размер единицы данных составляет один байт.
     
     Примечания
     

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

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

5.1.4.3 Обращение к информационному объекту
     
     Каждый информационный объект, определяемый в 5.4.4, начинается с тега, который служит для обращения к информационному объекту. Теги установлены в настоящем стандарте и других стандартах серии ГОСТ Р ИСО/МЭК 7816 (ИСО/МЭК 7816).
     

5.1.5 Контрольная информация файла
     
     Контрольная информация файла (FCI) представляет собой строку байтов данных, содержащуюся в ответе на команду ВЫБРАТЬ ФАЙЛ. Контрольная информация может быть у любого файла.
     
     В таблице 1 приведены три шаблона, предназначаемые для передачи контрольной информации файла в том случае, когда она кодируется в виде информационных объектов BER-TLV.
     
     
Таблица 1 - Шаблоны для FCI
     

Тег	Значение
'62'	Контрольные параметры файла (шаблон FCP)
'64'	Данные управления файлом (шаблон FMD)
'6F'	Контрольная информация файла (шаблон FCI)

     
     Шаблон FCP предназначается для передачи контрольных параметров файла (FCP), т.е. любых информационных объектов BER-TLV, определяемых в таблице 2.
     
     
Таблица 2 - Контрольные параметры файла
     

Тег		Значение	Применимость
'80'	2	Число байтов данных в файле, исключая структурную информацию	Прозрачный EF
'81'	2	Число байтов данных в файле, включая структурную информацию, если она имеется	Любой файл
'82'	1 2 3 или 4	Байт описателя файла (см. таблицу 3)            Байт описателя файла, сопровождаемый байтом кодирования данных (см. таблицу 86)            Байт описателя файла, сопровождаемый байтом кодирования данных и максимальной длиной записи	Любой файл То же EF со структурой из записей
'83'	2	Идентификатор файла	Любой файл
'84'	От 1 до 16	Имя DF	DF
'85'	Переменная	Оригинальная информация	Любой файл
'86'	Переменная	Атрибуты секретности (кодирование за пределами компетенции настоящего стандарта)	Любой файл
'87'	2	Идентификатор файла EF, содержащего расширение FCI	Любой файл
От '88' до '9Е'		RFU
'9FXY'		RFU

     
Таблица 3 - Байт описателя файла
     

b8	b7	b6	b5	b4	b3	b2	b1	Смысловое содержание
0	х	-	-	-	-	-	-	Доступность файла:
0	0	-	-	-	-	-	-	- файл несовместного доступа
0	1	-	-	-	-	-	-	- файл совместного доступа
0	-	х	х	х	-	-	-	Тип файла:
0	-	0	0	0	-	-	-	- рабочий EF
0	-	0	0	1	-	-	-	- внутренний EF
0	-	0	1	0	-	-	-	- зарезервировано
0	-	0	1	1	-	-	-	для
0	-	1	0	0	-	-	-	оригинальных
0	-	1	0	1	-	-	-	типов
0	-	1	1	0	-	-	-	файлов EF
0	-	1	1	1	-	-	-	- DF
0	-	-	-	-	х	х	х	Структура EF:
0	-	-	-	-	0	0	0	- информация не предоставлена
0	-	-	-	-	0	0	1	- прозрачная
0	-	-	-	-	0	1	0	- линейная фиксированная; нет дополнительной информации
0	-	-	-	-	0	1	1	- линейная фиксированная; информационные объекты SIMPLE-TLV
0	-	-	-	-	1	0	0	- линейная переменная; нет дополнительной информации
0	-	-	-	-	1	0	1	- линейная переменная; информационные объекты SIMPLE-TLV
0	-	-	-	-	1	1	0	- циклическая; нет дополнительной информации
0	-	-	-	-	1	1	1	- циклическая; информационные объекты SIMPLE-TLV
1	х	х	х	х	х	х	х	RFU
Примечание - "Совместный доступ" означает, что файл поддерживает по меньшей мере одновременный доступ по разным логическим каналам.

     
     Шаблон FMD предназначается для передачи данных управления файлом (FMD), т.е. информационных объектов BER-TLV, указанных в других разделах настоящего стандарта или в других стандартах серии ГОСТ Р ИСО/МЭК 7816 (ИСО/МЭК 7816) (например, метки приложения по ИСО/МЭК 7816-5 и даты истечения срока действия приложения по ГОСТ Р ИСО/МЭК 7816-6).
     
     Шаблон FCI предназначается для передачи контрольных параметров файла и данных управления файлом.
     
     Извлечение этих трех шаблонов может осуществляться по опциям выбора команды ВЫБРАТЬ ФАЙЛ (см. таблицу 59). Если установлена опция FCP или FMD, то использование соответствующего шаблона является обязательным. Если установлена опция FCI, то использование шаблона FCI не является обязательным.
     
     Часть контрольной информации файла может быть дополнительно представлена в рабочем файле EF под управлением приложения, ссылка на который приводится под тегом '87'. В таком EF использование шаблона FCP или FCI для кодирования контрольной информации файла является обязательным.
     
     Контрольная информация файла, не закодированная в соответствии с настоящим стандартом, может вводиться следующим образом:
     
     тег, равный '00', или тег с любым значением выше чем '9F' - кодирование последующей строки байтов является оригинальным;
     
     тег, равный '53' - поле значения информационного объекта состоит из произвольных данных, не закодированных в структуре TLV;
     
     тег, равный '73' - поле значения информационного объекта состоит из произвольных информационных объектов BER-TLV.
     
     

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

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

5.2.1 Состояние защиты
     
     Состояние защиты представляет собой текущее состояние, которое может достигаться после завершения:
     
     - ответа на восстановление (ATR) и возможного выбора типа протокола (PTS) и/или
     
     - отдельной команды или последовательности команд, возможно выполняющих процедуры аутентификации.
     
     Состояние защиты может являться также результатом завершения процедуры защиты, связанной с идентификацией участвующих сторон, если таковая применяется, например посредством:
     
     - проверки знания пароля (например, с использованием команды ВЫПОЛНИТЬ ВЕРИФИКАЦИЮ),
     
     - проверки знания ключа (например, с использованием команды СОЗДАТЬ ЗАДАЧУ, сопровождаемой командой ВЫПОЛНИТЬ ВНЕШНЮЮ АУТЕНТИФИКАЦИЮ),
     
     - безопасного обмена сообщениями (например, на основе аутентификации сообщений).
     
     Рассматриваются следующие три состояния защиты.
     

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

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

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

5.2.2 Атрибуты секретности
     
     Атрибуты секретности, если они имеются, определяют разрешенные действия, а также процедуры, подлежащие выполнению для завершения таких действий.
     
     Атрибуты секретности могут быть связаны с каждым файлом и фиксируют условия секретности, которые необходимо соблюсти для осуществления операций на файле. Атрибуты секретности файла зависят от:
     
     - его категории (DF или EF),
     
     - возможных параметров в его контрольной информации и/или в контрольной информации его родительского(их) файла(ов).
     
     Примечание - Атрибуты секретности могут сопутствовать и другим объектам (например ключам).
     
     

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

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

б) Аутентификация участвующей стороны по ключу
     
     Участвующая сторона, подвергаемая аутентификации, должна доказать знание соответствующего ключа в ходе процедуры аутентификации (например, с использованием команды СОЗДАТЬ ЗАДАЧУ, сопровождаемой командой ВЫПОЛНИТЬ ВНЕШНЮЮ АУТЕНТИФИКАЦИЮ).
     

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

г) Шифрование данных
     
     Используя секретные внутренние данные, карта осуществляет дешифрование криптограммы, полученной в поле данных. В свою очередь, используя внутренние данные, секретные или открытые, карта вычисляет криптограмму и вставляет ее в поле данных, возможно вместе с другими данными. Данный механизм может использоваться для обеспечения услуги конфиденциальности, например для управления ключами и условного доступа. В дополнение к механизму с криптограммой, конфиденциальность данных может достигаться за счет сокрытия данных. В этом случае карта вычисляет строку скрывающих байтов и прибавляет ее при помощи операции сложения "исключающее ИЛИ" к байтам данных, полученным от внешнего окружения или посылаемым внешнему окружению. Данный механизм может использоваться для защиты личных секретных данных и для снижения возможностей фильтрации сообщений.
     
     Результат аутентификации может регистрироваться во внутреннем EF в соответствии с требованиями приложения.
     
     

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

     Шаг в прикладном протоколе состоит из посылки команды, обработки ее принимающей стороной и посылки ответа в обратном направлении. Таким образом, конкретный ответ соответствует конкретной команде; вместе они именуются парой команда-ответ.
     
     Блок данных прикладного протокола (APDU) содержит либо командное, либо ответное сообщение, посылаемое карте с устройства сопряжения, или наоборот.
     
     В паре команда-ответ командное и ответное сообщения могут содержать данные, следствием чего являются четыре случая, обобщенные в таблице 4.
     
     
Таблица 4 - Данные в паре команда-ответ
     

Случай	Данные команды	Ожидаемые данные ответа
1	Нет данных	Нет данных
2	То же	Данные
3	Данные	Нет данных
4	"	Данные

     

5.3.1 Командный APDU
     
     Представленный на рисунке 3 (см. также таблицу 6) командный APDU, определяемый в настоящем стандарте, состоит из:
     
     - обязательного заголовка из четырех байтов (CLA, INS, P1, P2),
     
     - условного тела переменной длины.
     

Рисунок 3 - Структура командного APDU

Рисунок 3 - Структура командного APDU

     
     Число байтов, представленных в поле данных командного APDU, обозначается .
     
     Максимальное число байтов, ожидаемых в поле данных ответного APDU, обозначается (длина ожидаемых данных). Если поле содержит только нули, то запрашивается максимальное число имеющихся байтов данных.
     
     На рисунке 4 представлены четыре структуры командных APDU, соответствующие четырем случаям из таблицы 4.
     

Рисунок 4 - Четыре структуры командных APDU

Рисунок 4 - Четыре структуры командных APDU

     
     В случае 1 длина данных является нулевой; следовательно поле и поле данных являются пустыми. Длина данных также является нулевой; следовательно и поле является пустым. В результате тело является пустым.
     
     В случае 2 длина данных является нулевой; следовательно поле   и поле данных являются пустыми. Длина данных не является нулевой; следовательно поле присутствует. В результате тело состоит из поля .
     
     В случае 3 длина данных не является нулевой; следовательно поле присутствует, а поле данных состоит из последующих байтов. Длина данных является нулевой; следовательно поле является пустым. В результате тело состоит из поля, сопровождаемого полем данных.
     
     В случае 4 длина данных не является нулевой; следовательно поле присутствует, а поле данных состоит из последующих байтов. Длина данных также не является нулевой; следовательно поле также присутствует. В результате тело состоит из поля , сопровождаемого полем д

анных и полем .
    

5.3.2 Соглашения по декодированию тела команды
     
     В случае 1 тело командного APDU является пустым. Такой командный APDU не несет поле длины.
     
     В случаях 2-4 тело командного APDU состоит из строки, образованной байтами, обозначаемыми символами , как показано на рисунке 5. Такое тело несет одно или два поля длины; байт представляет собой первое поле длины или его часть.
     

Рисунок 5 - Непустое тело

Рисунок 5 - Непустое тело

     
     В данных, представляющих функциональные возможности карты (см. 8.3.6), карта устанавливает, что в командном APDU поля и :
     
     - либо должны быть короткими (один байт по умолчанию),
     
     - либо могут быть расширенными (явное сообщение).
     
     Следовательно, случаи 2-4 являются либо короткими (один байт для каждого поля длины), либо расширенными (байту присваивается значение '00', а значение каждой длины кодируется в двух других байтах).
     
     В таблице 5 представлено декодирование командных APDU, соответствующих четырем случаям, приведенным в таблице 4 и на рисунке 4, и возможному расширению полей и . Любой другой командный APDU является недействительным.
     
     
Таблица 5 - Декодирование командных APDU
     

Условия			Случай
	-	-	1
	-	-	2, короткий (2К)
;	;	-	3, короткий (3К)
;	;	-	4, короткий (4К)
;	;		2, расширенный (2Р)
;	;		3, расширенный (3Р)
;	;		4, расширенный (4Р)

     
     Соглашения по декодированию поля следующие.
     
     Если значение закодировано в одном (двух) байте(ах), где не все биты являются нулевыми, то оно равно значению байта(ов), которое находится в диапазоне от 1 до 255 (от 1 до 65535); нулевые значения всех битов означают максимальное значение : 256 (65536).
     
     Следующие первые четыре случая относятся ко всем картам.
     
     Случай 1
     
      =0; тело является пустым. Для этого случая:
     
     - ни один байт не используется для (=0);
     
     - не представлен ни один байт данных;
     
     - ни один байт не используется для (=0).
     
     Случай 2К
     
     =1. Для этого случая:
     
     - ни один байт не используется для (=0);
     
     - не представлен ни один байт данных;
     
     - байт кодирует значение от 1 до 256.
     
     Случай 3К
     
     =1+() и ()0. Для этого случая:
     
     - байт кодирует значение (0) от 1 до 255;
     
     - байты от до представляют собой байтов поля данных;
     
     - ни один байт не используется для (=0).
     
     Случай 4К
     
     =2+() и ()0. Для этого случая:
     
     - байт кодирует значение (0) от 1 до 255;
     
     - байты от до представляют собой байтов поля данных;
     
     - байт кодирует значение от 1 до 256.
     
     Для карт, указывающих на расширение полей и (см. 8.3.6), применяются также следующие три случая.
     
     Случай 2Р
     
     =3 и ()=0. Для этого случая:
     
     - ни один байт не используется для (=0);
     
     - не представлен ни один байт данных;
     
     - поле состоит из трех байтов, где байты и кодируют значение от 1 до 65536.
     
     Случай 3Р
     
     =3+(||), ()=0 и (||)0. Для этого случая:
     
     - поле состоит из первых трех байтов, где байты и кодируют значение (0) от 1 до 65535;
     
     - байты от до представляют собой байтов поля данных;
     
     - ни один байт не используется для (=0).
     
     Случай 4Р
     
     =5+(||), ()=0 и (||)0. Для этого случая:
     
     - поле состоит из первых трех байтов, где байты и кодируют значение (0) от 1 до 65535;
     
     - байты от до представляют собой байтов поля данных;
     
     - поле состоит из последних двух байтов  и , кодирующих значение от 1 до 65536.
     
     Для каждого протокола передачи по ИСО/МЭК 7816-3 в настоящем стандарте предусмотрено приложение (см. приложения А и Б), определяющее транспортиро

вку блоков данных APDU пары команда-ответ в каждом из семи рассмотренных случаев.
     

5.3.3 Ответный APDU
     
     Представленный на рисунке 6 (см. также таблицу 7) ответный APDU, определяемый в настоящем стандарте, состоит из:
     
     - условного тела переменной длины,
     
     - обязательного завершителя из двух байтов (SW1, SW2).
     
     Число байтов, представленных в поле данных ответного APDU, обозначается через .
     

Рисунок 6 - Структура ответного APDU

Рисунок 6 - Структура ответного APDU

     
     Завершитель кодирует состояние принимающей стороны после обработки пары команда-ответ.
     
     Примечание - Если команда прерывается, то ответный APDU представляет завершитель, кодирующий состояние ошибки в двух байтах состояния.
     
     

5.4 Соглашения по кодированию заголовков команд, полей данных и завершителей ответа

     Таблица 6 представляет содержимое командного APDU.
     
     
Таблица 6 - Содержимое командного APDU
     

Код	Наименование	Длина	Описание
CLA	Класс	1	Класс команды
INS	Команда	1	Код команды
P1	Параметр 1	1	Параметр команды 1
Р2	Параметр 2	1	Параметр команды 2
Поле	Длина	Переменная: 1 или 3	Число байтов, представленных в поле данных команды
Поле данных	Данные	Переменная: равна	Строка байтов, посылаемая в поле данных команды
Поле	Длина	Переменная:	Максимальное число байтов, ожидаемых в поле данных ответа на команду