ГОСТ Р ИСО/МЭК 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 - Пример логической организации файлов

     
     
     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

     
     
     5.1.4 Методы обращения к данным
     
     Обращение к данным может осуществляться как к записям, единицам данных или информационным объектам. Предполагается, что данные должны храниться в виде одной непрерывной последовательности записей (в пределах EF со структурой из записей) или единиц данных (в пределах EF с прозрачной структурой). Обращение к записи или единице данных вне EF является ошибкой.
     
     Метод обращения к данным, метод нумерации записей и размер единиц данных являются характеристиками, зависящими от EF. Карта может давать соответствующие указания в ATR, файле ATR и контрольной информации любого файла. Если карта дает указания в нескольких местах, то действительным для данного EF является ближайшее к нему указание в пределах пути от MF до этого EF.
     
     5.1.4.1 Обращение к записи
     
     В пределах каждого EF со структурой из записей обращение к каждой записи может осуществляться при помощи идентификатора записи и/или номера записи. Идентификаторы и номера записей представляют собой целые восьмибитовые числа без знака со значениями от '01' до 'FЕ'. Значение '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
     

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

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

     
     
     Шаблон 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 - Данные в паре команда-ответ
     

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

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

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

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

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

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

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

     
     
     Соглашения по декодированию поля  следующие.
     
     Если значение  закодировано в одном (двух) байте(ах), где не все биты являются нулевыми, то оно равно значению байта(ов), которое находится в диапазоне от 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

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

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

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

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

     
     
     Последующие пункты устанавливают соглашения по кодированию байта класса, командного байта, байтов параметров, байтов поля данных и байтов состояния.
     
     Если не указано иначе, то в этих байтах биты RFU кодируются нулем, а байты RFU кодируются значением '00'.
     
     5.4.1 Байт класса
     
     В соответствии с таблицами 8 и 9 байт класса CLA команды применяется для указания:
     
     - степени соответствия команды и ответа настоящему стандарту;
     
     - формата безопасного обмена сообщениями и номера логического канала (в случае применимости, см. таблицу 9).
     
     
Таблица 8 - Кодирование и смысловое содержание CLA
     

     
     
Таблица 9 - Кодирование и смысловое содержание полубайта 'X' в байте CLA, равном '0Х', '8Х', '9Х' или 'АХ'
     

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

     
     
     В таблице 11 представлены коды INS, определяемые в настоящем стандарте. Если значение CLA находится в диапазоне от '00' до '7F', другие значения кодов INS должны назначаться подкомитетом N 17 совместного технического комитета N 1 ИСО/МЭК (ПК 17 СТК 1 ИСО/МЭК).
     
     
Таблица 11 - Коды INS, определяемые в настоящем стандарте

     
     
     5.4.3 Байты параметров
     
     Байты параметров P1, P2 команды могут иметь любое значение. Если байт параметра не обеспечивает никакого дальнейшего уточнения, то он должен быть установлен в состояние '00'.
     
     5.4.4 Байты поля данных
     
     Каждое поле данных должно иметь одну из следующих трех структур:
     
     - каждое закодированное в структуре TLV поле данных должно состоять из одного или большего числа закодированных в структуре TLV информационных объектов;
     
     - каждое не закодированное в структуре TLV поле данных должно состоять из одного или большего числа элементов данных, отвечающих требованиям соответствующей команды;
     
     - структуру полей данных с оригинальным кодированием настоящий стандарт и стандарты серии ИСО/МЭК 7816 не устанавливают.
     
     Настоящий стандарт поддерживает следующие два типа закодированных в структуре TLV информационных объектов в полях данных:
     
     - информационный объект BER-TLV;
     
     - информационный объект SIMPLE-TLV.
     
     Настоящий стандарт не использует ни '00', ни 'FF' в качестве значения тега.
     
     Каждый информационный объект BER-TLV должен состоять из двух или трех последовательных полей (см. ГОСТ Р ИСО/МЭК 8825 и приложение Г):
     
     - поля тега , состоящего из одного или большего числа последовательных байтов. Оно кодирует класс, тип конструкции и номер;
     
     - поля длины, состоящего из одного или большего числа последовательных байтов. Оно кодирует целое число ;
     
     - поля значения (если 0), состоящего из  последовательных байтов. Если =0, то информационный объект является пустым: поле значения отсутствует.
     
     Каждый информационный объект SIMPLE-TLV должен состоять из двух или трех последовательных полей:
     
     - поля тега , состоящего из одиночного байта, кодирующего только номер от 1 до 254 (например, идентификатор записи). Оно не кодирует ни класс, ни тип конструкции;
     
     - поля длины, состоящего из одного или трех последовательных байтов. Если значение начального байта поля длины находится в диапазоне от '00' до 'FE', то поле длины состоит из одиночного байта, кодирующего значение целого числа  от 0 до 254. Если начальный байт равен 'FF', то поле длины продолжается на два последующих байта, кодирующих значение целого числа  от 0 до 65535;
     
     - поля значения V (если 0), состоящего из  последовательных байтов. Если =0, то информационный объект является пустым: поле значения отсутствует.
     
     Поля данных некоторых команд (например, команды ВЫБРАТЬ ФАЙЛ), поля значений информационных объектов SIMPLE-TLV и поля значений некоторых простых информационных объектов BER-TLV предназначаются для кодирования одного или большего числа элементов данных.
     
     Поля данных некоторых других команд (например, команд, ориентированных на запись) и поля значений других простых информационных объектов BER-TLV предназначаются для кодирования одного или большего числа информационных объектов SIMPLE-TLV.
     
     Поля данных прочих команд (например команд, ориентированных на объект) и поля значений составных информационных объектов BER-TLV предназначаются для кодирования одного или большего числа информационных объектов BER-TLV.
     
     Примечание - Перед и между закодированными в структуре TLV информационными объектами или после них могут возникать байты со значениями '00' или 'FF' без какого-либо смыслового содержания (например, как следствие удаленных или измененных TLV-закодированных информационных объектов).
     
     
     5.4.5 Байты состояния
     
     Байты состояния SW1, SW2 ответа обозначают состояние обработки команды в карте. На рисунке 7 представлена структурная схема их значений, определяемых в настоящем стандарте.     
         

 Примечание - Если SW1='63' (или '65'), состояние энергонезависимой памяти изменено. Если SW1='6X' (за исключением '63' и '65'), состояние энергонезависимой памяти не изменено.

Рисунок 7 - Структурная схема байтов состояния

     
     
     Благодаря описанию байтов состояния, данному в ИСО/МЭК 7816-3, настоящий стандарт не определяет следующих значений последовательности байтов SW1-SW2:
     
     - '60ХХ';
     
     - '67ХХ', '6ВХХ', '6DXX', '6ЕХХ', '6FXX' в каждом случае, если 'XX''00';
     
     - '9ХХХ', если 'XXX''000'.
     
     Следующие значения байтов SW1, SW2 определены для любого протокола (см. примеры в приложении А):
     
     - если выполнение команды прерывается с ответом, где SW1='6С', то SW2 указывает значение (точную длину запрашиваемых данных), которое должно быть дано короткому полю  при повторной подаче той же команды до подачи любой другой команды;
     
     - если команда (которая может относиться к случаю 2 или 4, см. таблицу 4 и рисунок 4) обрабатывается с ответом, где SW1='61', то SW2 указывает максимальное значение (длину дополнительных еще имеющихся данных), которое должно быть дано короткому полю  в команде ИЗВЛЕЧЬ ОТВЕТ, подаваемой перед подачей любой другой команды.
     
     Примечание - Функциональные возможности, аналогичные тем, которые предлагаются при помощи значения '61ХХ', могут быть предложены на уровне приложения при помощи значения '9FXX'. Вместе с тем приложения могут использовать значение '9FXX' для иных целей.
     
     
     В таблице 12, дополняемой таблицами 13-18, представлено общее смысловое содержание значений последовательности байтов SW1-SW2, определяемых в настоящем стандарте. Для каждой команды в соответствующем разделе представлено их более детальное содержание.
          
     
Таблица 12 - Кодирование последовательности байтов SW1-SW2

     
Таблицы 13-18 определяют значения байта SW2 для случаев, когда у байта SW1 значения составляют соответственно '62', '63', '65', '68', '69' и '6А'. Значения байта SW2, не определяемые в таблицах 13-18, являются RFU, за исключением значений от 'F0' до 'FF', которые настоящий стандарт не определяет.

     
 Таблица 13 - Кодирование байта SW2, если SW1='62'

Таблица 14 - Кодирование байта SW2, если SW1='63'

     
     
Таблица 15 - Кодирование байта SW2, если SW1='65'
     

     
     
Таблица 16 - Кодирование байта SW2, если SW1='68'

Таблица 17 - Кодирование байта SW2, если SW1='69'

     
     
Таблица 18 - Кодирование байта SW2, если SW1='6А'
     

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

     
     5.5.1 Общая концепция
     
     Логический канал, прослеживаемый на стыке между картой и устройством сопряжения, работает как логическая линия связи, ведущая к DF.
     
     Функционирование одного логического канала должно осуществляться независимо от функционирования другого логического канала. То есть взаимосвязи команд на одном логическом канале не должны зависеть от взаимосвязей команд на другом логическом канале. Тем не менее логические каналы могут совместно использовать зависимое от приложения состояние защиты и, следовательно, для всех логических каналов могут иметь место взаимозависимости в части команд, связанных с защитными функциями (например, верификацией по паролю).
     
     Команды, относящиеся к конкретному логическому каналу, несут соответствующий номер логического канала в байте CLA (см. таблицы 8 и 9). Логические каналы нумеруются от 0 до 3. Если карта поддерживает механизм логических каналов, то максимальное число имеющихся логических каналов указывается в данных о функциональных возможностях карты (см. 8.3.6).
     
     Пары команда-ответ работают в соответствии со следующим описанием. Настоящий стандарт поддерживает только те пары команда-ответ, которые должны полностью завершаться до инициирования следующей пары команда-ответ. Не должно происходить разбиения команд и ответов на них по логическим каналам; между получением команды и посылкой ответа на эту команду активным должен быть только один логический канал. Если логический канал открывается, то он остается открытым до тех пор, пока не будет закрыт явным образом командой ВВЕСТИ УПРАВЛЕНИЕ КАНАЛОМ.
     
     Примечания
     
     1 Может быть открыто более одного логического канала к одному и тому же DF, если это не исключается (о доступности файла см. в 5.1.5).
     
     2 Более чем один логический канал может выбирать один и тот же EF, если это не исключается (о доступности файла см. в 5.1.5).
     
     3 Команда ВЫБРАТЬ ФАЙЛ на любом логическом канале откроет текущий DF и, возможно, текущий EF. Следовательно на один логический канал приходится один текущий DF и, возможно, один текущий EF вследствие действия команды ВЫБРАТЬ ФАЙЛ и команд, использующих для достижения файла короткий идентификатор EF.
     
     
     5.5.2 Основной логический канал
     
     Основной логический канал постоянно доступен. Если ему присваивается номер, то это номер 0. Если байт класса кодируется по таблицам 8 и 9, то его биты b1 и b2 кодируют номер логического канала.
     
     5.5.3 Открытие логического канала
     
     Логический канал открывается в результате успешного завершения:
     
     - либо команды ВЫБРАТЬ ФАЙЛ, обращающейся к DF путем назначения номера логического канала, отличного от 0, в байте класса;
     
     - либо функции открытия команды ВВЕСТИ УПРАВЛЕНИЕ КАНАЛОМ, которая или назначает номер логического канала, отличный от 0, в командном APDU, или запрашивает его назначение. Тогда он должен быть назначен картой и выдан в ответе.
     
     5.5.4 3акрытие логического канала
     
     Функция закрытия команды ВВЕСТИ УПРАВЛЕНИЕ КАНАЛОМ может применяться для явного закрытия логического канала, использующего номер логического канала. После закрытия номер логического канала будет доступен для повторного использования. Основной логический канал не должен закрываться.
     
     

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

     
     Безопасный обмен сообщениями (SM) предназначается для защиты передаваемых на карту и с карты сообщений (или их части) посредством обеспечения двух основных защитных функций: аутентификации данных и конфиденциальности данных.
     
     Безопасный обмен сообщениями достигается путем применения одного или большего числа механизмов защиты. Каждый такой механизм включает в себя алгоритм, ключ, аргумент и, зачастую, исходные данные.
     
     Передача и прием полей данных могут прерываться исполнением механизмов защиты. Настоящее описание не препятствуют определению посредством последовательного анализа, какие механизмы и элементы защиты должны использоваться для обработки оставшейся части поля данных.
     
     Два или большее число механизмов защиты могут использовать один и тот же алгоритм вместе с разными режимами работы (см. ГОСТ Р ИСО/МЭК 10116). Представленные описания правил заполнения блоков данных незначащей информацией не препятствуют такой возможности.
     
     Настоящий подраздел определяет три типа информационных объектов, связанных с SM:
     
     - информационные объекты с незашифрованным значением, предназначаемые для переноса незашифрованных данных;
     
     - информационные объекты механизмов защиты, предназначаемые для переноса вычисленных результатов механизмов защиты;
     
     - информационные объекты вспомогательной функции защиты, предназначаемые для переноса управляющих ссылок и описателей ответа.
     
     5.6.1 Концепция формата SM
     
     В каждом сообщении, вовлекающем механизмы защиты, основанные на криптографии, поле данных должно подчиняться базовым правилам кодирования АСН.1 (см. ГОСТ Р ИСО/МЭК 8825 и приложение Г), если в байте класса не указано иначе (см. 5.4.1).
     
     Представленный в поле данных формат SM может быть выбранным:
     
     - неявно, т.е. быть известным до подачи команды;
     
     - явно, т.е. быть зафиксированным при помощи байта класса (см. таблицу 9).
     
     Формат SM, определяемый в настоящем стандарте, кодируется с использованием информационных объектов BER-TLV, при этом:
     
     - для SM зарезервирован контекстно-зависимый класс тегов (диапазон от '80' до 'BF');
     
     - могут быть представлены информационные объекты других классов (например, информационные объекты прикладного класса);
     
     - некоторые информационные объекты, связанные с SM, являются рекурсивными: их поле незашифрованного значения также кодируется информационными объектами BER-TLV, и там для SM также зарезервирован контекстно-зависимый класс.
     
     В контекстно-зависимом классе бит b1 тега указывает, подлежит (b1=1) или не подлежит (b1=0) информационный объект, связанный с SM, объединению при вычислении информационного объекта для аутентификации. Если представлены информационные объекты других классов, то они подлежат объединению при таком вычислении.
     
     5.6.2 Информационные объекты с незашифрованным значением
     
     Для данных, не закодированных в информационных объектах BER-TLV, и для информационных объектов BER-TLV, включающих в себя объекты, связанные с SM, обязательной является инкапсуляция. Она не является обязательной для информационных объектов BER-TLV, не включающих в себя объекты, связанные с SM. В таблице 19 представлены незашифрованные информационные объекты для инкапсуляции.
     
     
Таблица 19 - Информационные объекты с незашифрованным значением
     

     
     
     5.6.3 Информационные объекты для аутентификации
     
     5.6.3.1 Информационный объект "криптографическая контрольная сумма"
     
     Вычисление криптографических контрольных сумм (см. ИСО/МЭК 9797) предполагает наличие исходного контрольного блока, секретного ключа и алгоритма блочного шифрования, который не может быть обратимым. Алгоритм под управлением связанного с ним ключа, по существу, преобразует блок текущего ввода из  байтов (обычно восемь или 16) в блок текущего вывода той же длины.
     
     Вычисление криптографической контрольной суммы выполняется последовательно по этапам.
     
     а) Начальный этап
     
     Начальный этап задает исходный контрольный блок, которым должен быть один из следующих блоков:
     
     - нулевой блок, т.е.  байтов со значением '00';
     
     - связующий блок, т.е. результат предыдущих вычислений, а именно: для команды - результирующий контрольный блок предшествующей команды, для ответа - результирующий контрольный блок предшествующего ответа;
     
     - блок с начальным значением, предоставленный, например, внешним окружением;
     
     - вспомогательный блок, являющийся результатом преобразования вспомогательных данных по соответствующему ключу. Если вспомогательные данные составляют менее  байтов, то они озаглавливаются битами, установленными в ноль, до достижения длины блока.
     
     б) Промежуточный этап
     
     Если таблица 9 применима (СLА='0Х', '8Х', '9Х' или 'АХ') и биты b4 и b3 байта класса установлены в единицу, то первый блок данных состоит из заголовка командного APDU (CLA, INS, P1, P2), за которым следуют один байт со значением '80' и  - 5 байтов со значением '00'.
     
     Криптографическая контрольная сумма должна объединять любой информационный объект, связанный с SM и имеющий тег с битом b1=1, и любой информационный объект с тегом, имеющим значение вне диапазона '80'-'BF'. Эти информационные объекты должны объединяться в блок данных за блоком данных в текущем контрольном блоке. Разбивка на блоки данных должна осуществляться по следующим правилам:
     
     - объединение в блоки должно быть непрерывным на границе между смежными информационными объектами, подлежащими объединению;
     
     - заполнение незначащей информацией должно применяться в конце каждого подлежащего объединению информационного объекта, за которым либо следует информационный объект, не подлежащий объединению, либо отсутствует дальнейший информационный объект.
     
     Незначащая информация состоит из одного обязательного байта со значением '80', за которым, если требуется, должны следовать от 0 до  -1 байтов, установленных в '00', пока соответствующий блок данных не будет заполнен  байтами. Заполнение незначащей информацией для аутентификации не оказывает влияния на передачу, поскольку заполняющие байты не должны передаваться.
     
     Режимом работы является "последовательное блочное шифрование" (см. ГОСТ Р ИСО/МЭК 10116). Первый ввод представляет собой операцию сложения "Исключающее ИЛИ" над исходным контрольным блоком и первым блоком данных. Первый вывод является результатом первого ввода. Текущий ввод представляет собой операцию сложения "Исключающее ИЛИ" над предыдущим выводом и текущим блоком данных. Текущий вывод является результатом текущего ввода. Результирующий контрольный блок является последним выводом.
     
     в) Заключительный этап
     
     Заключительный этап выделяет криптографическую контрольную сумму (первые  байтов, но не менее четырех) из результирующего контрольного блока.
     
     В таблице 20 представлен информационный объект "криптографическая контрольная сумма".
     
     
Таблица 20 - Информационный объект "криптографическая контрольная сумма"

     
     
     5.6.3.2 Информационный объект "электронная цифровая подпись"
     
     Вычисление электронной цифровой подписи, как правило, основывается на асимметричных криптографических методах. Существуют два типа электронных цифровых подписей:
     
     - электронная цифровая подпись с присоединением,
     
     - электронная цифровая подпись, обеспечивающая восстановление сообщения.
     
     Вычисление электронной цифровой подписи с присоединением предполагает использование хэш-функции (см. ИСО/МЭК 10118-1 и ИСО/МЭК 10118-2). Ввод данных либо состоит из значения информационного объекта с данными ввода для выработки электронной цифровой подписи (см. таблицу 21), либо вычисляется согласно механизму, определяемому в 5.6.3.1.
     
     Вычисление электронной цифровой подписи, обеспечивающей восстановление сообщения (см. ИСО/МЭК 9796), не предусматривает использование хэш-функции. Тем не менее в соответствии с потребностями приложения хэш-код может присутствовать как часть восстановленного сообщения, которое само может быть закодировано в структуре BER-TLV.
     
     В таблице 21 представлены информационные объекты, относящиеся к электронной цифровой подписи.
     
     
Таблица 21 - Информационные объекты, относящиеся к электронной цифровой подписи

     
     
     5.6.4 Информационные объекты для конфиденциальности
     
     Информационные объекты, используемые для конфиденциальности, предназначаются для переноса криптограммы, незашифрованное значение которой должно быть представлено одним из следующих трех случаев:
     
     - информационными объектами BER-TLV, включающими в себя объекты, связанные с SM;
     
     - информационными объектами BER-TLV, не включающими в себя объекты, связанные с SM;
     
     - данными, не закодированными информационными объектами BER-TLV.
     
     Если незашифрованное значение состоит из данных, не закодированных информационными объектами BER-TLV, заполнение незначащей информацией должно иметь индикацию. Если оно применяется, но индикации нет, то для него действуют правила, определяемые в 5.6.3.1.
     
     В таблице 22 представлены информационные объекты для конфиденциальности.
     
     Каждый такой информационный объект может использовать любой криптографический алгоритм и любой режим работы благодаря соответствующей ссылке на алгоритм (см. 5.6.5.1). При отсутствии такой ссылки и выбранного в неявной форме механизма для конфиденциальности должен применяться механизм, устанавливаемый по умолчанию.
     
     
Таблица 22 - Информационные объекты для конфиденциальности
     

     
     
     Для вычисления криптограммы, которой предшествует индикатор заполнения незначащей информацией, механизм по умолчанию представляет собой блочное шифрование в режиме "электронный кодовый справочник" (см. ГОСТ Р ИСО/МЭК 10116). Использование блочного шифрования может включать в себя заполнение блоков данных незначащей информацией. Заполнение незначащей информацией для конфиденциальности оказывает влияние на передачу, криптограмма (один или большее число блоков) получается длиннее незашифрованного текста.
     
     В таблице 23 представлен байт индикатора заполнения незначащей информацией.
     
     Для вычисления криптограммы, которой не предшествует байт индикатора заполнения незначащей информацией, механизм по умолчанию представляет собой поточное шифрование вместе с операцией сложения "Исключающее ИЛИ". В этом случае криптограмма является результатом операции сложения "Исключающее ИЛИ", выполняемой над строкой байтов данных, подлежащих сокрытию, и скрывающей строкой той же длины. Сокрытие, таким образом, не требует заполнения незначащей информацией, а информационные объекты, скрытые в поле значения, восстанавливаются при помощи той же операции.
     
     
Таблица 23 - Байт индикатора заполнения незначащей информацией

     
     
     5.6.5 Информационные объекты вспомогательной функции защиты
     
     Алгоритм, ключ и, возможно, исходные данные могут выбираться для каждого механизма защиты следующим образом:
     
     - неявно, т.е. быть известными до подачи команды;
     
     - явно, при помощи управляющих ссылок, вложенных в шаблон управляющих ссылок.
     
     Каждое командное сообщение может нести шаблон описателя ответа, задающий информационные объекты, требуемые в ответе. Внутри описателя ответа механизмы защиты еще не применяются; принимающая сторона должна применить их для составления ответа.
     
     5.6.5.1 Управляющие ссылки
     
     В таблице 24 представлены шаблоны управляющих ссылок.
     
     
Таблица 24 - Шаблоны управляющих ссылок
     

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

     
     
     Ссылка на алгоритм указывает алгоритм и режим его работы (см. ИСО/МЭК 9979 и ГОСТ Р ИСО/МЭК 10116). Структуру и кодирование этой ссылки настоящий стандарт не определяет.
     
     Ссылка на файл обозначает тот файл, в котором действительна ссылка на ключ. Если ссылка на файл не представлена, тогда ссылка на ключ действительна в текущем DF.
     
     Ссылка на ключ идентифицирует ключ, подлежащий использованию.
     
     Ссылка на исходные данные, будучи примененной для криптографических контрольных сумм, определяет исходный контрольный блок. Если ссылка на исходные данные не представлена и не выбран неявным образом исходный контрольный блок, то должен использоваться нулевой блок. Кроме того, перед передачей первого информационного объекта для конфиденциальности, использующего поточное шифрование, шаблон для конфиденциальности должен предоставить вспомогательные данные для инициализации вычисления строки скрывающих байтов.
     
     Ссылка на содержимое криптограммы указывает содержание криптограммы (например, секретные ключи, исходный пароль, управляющие слова). Первый байт поля значения представляющего ее информационного объекта называется байтом описателя криптограммы и является обязательным. Диапазон его значений от '00' до '7F' является RFU, а диапазон от '80' до 'FF' отведен для собственного использования.
     
     5.6.5.2 Описатель ответа
     
     Шаблон описателя ответа, если он представлен в поле данных командного APDU, должен задавать структуру соответствующего ответа. Пустые информационные объекты должны перечислять все данные, необходимые для выработки ответа.
     
     Элементы защиты (алгоритмы, ключи и исходные данные), используемые для обработки поля данных командного сообщения, могут отличаться от элементов защиты, используемых для выработки поля данных последующего ответного сообщения.
     
     Должны применяться следующие правила:
     
     - карта должна заполнять каждый пустой простой информационный объект;
     
     - каждый шаблон управляющих ссылок, присутствующий в описателе ответа, должен быть представлен в ответе на том же месте с теми же управляющими ссылками для алгоритма, файла и ключа. Если описатель ответа предоставляет вспомогательные данные, тогда соответствующий информационный объект в ответе должен быть пустым. Если в описателе ответа присутствует пустой информационный объект для вспомогательных данных, то в ответе он должен быть заполнен;
     
     - применяя соответствующие механизмы защиты вместе с выбранными элементами защиты, карта должна осуществлять вывод всех запрашиваемых информационных объектов механизмов защиты.
     
     В таблице 26 представлен шаблон описателя ответа.
     
     
Таблица 26 - Шаблон описателя ответа

     
     
     5.6.6 Состояния после обработки, связанные с SM
     
     При любой команде, использующей безопасный обмен сообщениями, могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='69', а байт SW2 равен:
     
     '87' - пропадание ожидаемых информационных объектов, связанных с SM;
     
     '88' - информационные объекты, связанные с SM, некорректны.
     
     

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

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

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

     
     
     Раздел 6 устанавливает APDU-команды и APDU-ответы для основных межотраслевых команд. Раздел 7 устанавливает APDU-команды и APDU-ответы для межотраслевых команд, ориентированных на передачу данных. Разделы 6 и 7 не описывают влияние безопасного обмена сообщениями (см. 5.6) на структуры APDU-сообщений. Поэтому семантические значения полей длины и полей данных в разделах 6 и 7 кажутся противоречащими их синтаксическим значениям в 5.3.
     
     Настоящий подраздел определяет влияние безопасного обмена сообщениями, установленного в 5.6, на структуры APDU-сообщений, установленные в 5.3, с тем чтобы избежать вышеупомянутого возможного неправильного понимания.
     
     Для обеспечения защиты APDU-команды, где байт CLA имеет определенное значение, соответствующее таблице 9, а именно '0Х', '8Х', '9Х' или 'АХ', бит b4 в байте CLA должен быть установлен в единицу, что обозначено CLA* на рисунке 9 и в приложении Е; если тело команды присутствует, оно должно быть декодируемым в соответствии с 5.3.2 и инкапсулировано следующим образом.
     
     При наличии поля данных перенос  байтов данных должен осуществляться:
     
     - либо посредством информационного объекта с незашифрованным значением (тег равен '80', '81', 'В2', 'ВЗ', см. таблицу 19);
     
     - либо посредством информационного объекта для конфиденциальности (тег со значением от '84' до '87', см. таблицу 22).
     
     При наличии поля  перенос значения  должен осуществляться посредством информационного объекта, представляющего  (тег равен '96' или '97', см. таблицу 19); его поле значения кодирует положительное целое число без знака в одном или двух байтах; нулевое значение и пустой информационный объект означают максимум.
     
     Аналогично ответный APDU должен быть инкапсулирован следующим образом.
     
     При наличии поля данных перенос  байтов данных должен осуществляться:
     
     - либо посредством информационного объекта с незашифрованным значением (тег равен '80', '81', 'В2', 'В3', см. таблицу 19);
     
     - либо посредством информационного объекта для конфиденциальности (тег со значением от '84' до '87', см. таблицу 22).
     
     При необходимости перенос завершителя ответа должен осуществляться посредством информационного объекта, представляющего информацию о состоянии (тег равен '99', см. таблицу 19); пустой информационный объект означает, что последовательность байтов SW1-SW2='9000'.
     
     На рисунке 9 представлены структуры защищенных APDU-сообщений, при этом:
     
     - каждое новое поле данных может нести дополнительные информационные объекты, связанные с SM, например в конце - криптографическую контрольную сумму (тег равен '8Е'). В приложении Е приведены примеры для иллюстрации;
     
     - новое поле дает длину нового поля данных защищенного командного APDU;
     
     - новое поле  должно быть пустым, если не ожидается поле данных в защищенном ответном APDU; в противном случае оно должно содержать только нули;
     
     - новый завершитель ответа кодирует состояние принимающей стороны после обработки защищенной команды. Для защиты он может быть инкапсулирован.
          

 Примечания
     
     1 Длина от 1 до 127 кодируется в поле длины информационных объектов BER-TLV также как в полях длины APDU-сообщений. Для длины 128 и более способы кодирования различаются.
     
     2 Как указано выше, в новых полях данных могут быть представлены дополнительные (дальнейшие) или другие информационные объекты, связанные с SM.
     
     3 При безопасном обмене сообщениями не всегда выявляется, имеют ли данные, подлежащие защите, структуру BER-TLV. В таких случаях рекомендуются теги '80', '81', '86' и '87'.

Рисунок 9 - Структуры защищенных APDU-сообщений

     6 Основные межотраслевые команды

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

     6.1 Команда СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     6.1.1 Определение и область применения
     
     Ответное сообщение команды СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ передает содержимое (его часть) файла EF с прозрачной структурой.
     
     6.1.2 Условия использования и защиты
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в качестве текущего EF.
     
     Обработка команды осуществляется в выбранном в текущий момент EF. Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности, определенным для данного EF для функции считывания.
     
     Команда должна прерываться в том случае, если она применяется к EF без прозрачной структуры.
     
     6.1.3 Командное сообщение
     
     Командный APDU команды СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 27.
     
     
Таблица 27 - Командный APDU команды СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ
     

     
     
     Если бит b8=1 в байте Р1, то биты b7 и b6 байта Р1 устанавливаются в ноль (биты RFU), биты b5-b1 байта Р1 являются коротким идентификатором EF, а байт Р2 представляет собой смещение первого байта, подлежащего считыванию, в единицах данных от начала файла.
     
     Если бит b8=0 в байте Р1, то сцепление байтов P1 || P2 представляет собой смещение первого байта, подлежащего считыванию, в единицах данных от начала файла.
     
     6.1.4 Ответное сообщение (номинальный случай)
     
     Если поле  содержит только нули, то в пределах максимума 256 (для короткого поля) или 65536 (для расширенного поля) все байты до конца файла должны быть считаны.
     
     Ответный APDU команды СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 28.
     
     
Таблица 28 - Ответный APDU команды СЧИТАТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ
     

     
     
     6.1.5 Состояния после обработки
     
     Могут возникать следующие специфические состояния предупреждения.
     
     Если байт SW1='62', а байт SW2 равен:
     
     '81' - часть выдаваемых данных может быть искажена;
     
     '82' - конец файла достигнут до считывания  байтов.
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1 = '67', а байт SW2 равен:
     
     '00' - неверно указанная длина (несоответствующее поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден.
     
     Если байт SW1='6В', а байт SW2 равен:
     
     '00' - неверно указанные параметры (смещение выходит за пределы EF).
     
     Если байт SW1='6С', а байт SW2 равен:
     
     'XX' - неверно указанная длина (несоответствующее поле ; 'XX' указывает точную длину).
          

     6.2 Команда ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     6.2.1 Определение и область применения
     
     Командное сообщение команды ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ инициирует запись двоичных значений в EF.
     
     В зависимости от атрибутов файла команда должна выполнять одну из следующих операций:
     
     - логического сложения "ИЛИ" над битами, уже присутствующими в карте, и битами, передаваемыми в командном APDU (логическое состояние битов файла после стирания представлено нулем);
     
     - логического умножения "И" над битами, уже присутствующими в карте, и битами, передаваемыми в командном APDU (логическое состояние битов файла после стирания представлено единицей);
     
     - однократную запись в карту битов, передаваемых в командном APDU.
     
     Если индикация не дается в байте кодирования данных (см. таблицу 86), должен применяться режим логического сложения "ИЛИ".
     
     6.2.2 Условия использования и защиты
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF.
     
     Обработка команды осуществляется в выбранном в текущий момент EF. Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности для функций записи.
     
     Если команда ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ однажды уже была применена к единице данных файла EF, допускающего только однократную запись, то любая последующая операция записи, обращающаяся к этой же единице данных, прерывается, если содержание этой единицы данных или присоединенный к ней индикатор логического состояния после стирания (если он применяется) отличается от самого логического состояния после стирания.
     
     Команда должна прерываться в том случае, если она применяется к EF без прозрачной структуры.
     
     6.2.3 Командное сообщение
     
     Командный APDU команды ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 29.
     
     
Таблица 29 - Командный APDU команды ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ
     

     
     
     Если бит b8=1 в байте Р1, то биты b7 и b6 байта Р1 устанавливаются в ноль (биты RFU), биты b5-b1 байта Р1 являются коротким идентификатором EF, а байт P2 представляет собой смещение первого байта, подлежащего записи, в единицах данных от начала файла.
     
     Если бит b8=0 в байте Р1, то сцепление байтов Р1 || P2 представляет собой смещение первого байта, подлежащего записи, в единицах данных от начала файла.
     
     6.2.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 30.
     
     
Таблица 30 - Ответный APDU команды ВВЕСТИ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     
     6.2.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешная запись, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешная запись).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (несоответствующее поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден.
     
     Если байт SW1='6В', а байт SW2 равен:
     
     '00' - неверно указанные параметры (смещение выходит за пределы EF).
     

     6.3 Команда ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     6.3.1 Определение и область применения
     
     Командное сообщение команды ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ инициирует обновление битов, уже присутствующих в карте, битами, передаваемыми в командном APDU.
     
     6.3.2 Условия использования и защиты
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF.
     
     Обработка команды осуществляется в выбранном в текущий момент EF. Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности для функции обновления.
     
     Команда должна прерываться в том случае, если она применяется к EF без прозрачной структуры.
     
     6.3.3 Командное сообщение
     
     Командный APDU команды ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 31.
     
     
Таблица 31 - Командный APDU команды ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ
     

     
     
     Если бит b8=1 в байте Р1, то биты b7 и b6 байта Р1 устанавливаются в ноль (биты RFU), биты b5-b1 байта Р1 являются коротким идентификатором EF, а байт Р2 представляет собой смещение первого байта, подлежащего обновлению, в единицах данных от начала файла.
     
     Если бит b8=0 в байте Р1, то сцепление байтов Р1 || Р2 представляет собой смещение первого байта, подлежащего обновлению, в единицах данных от начала файла.
     
     6.3.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 32.
     
     
Таблица 32 - Ответный APDU команды ОБНОВИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ
     

     
     
     6.3.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешное обновление, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешное обновление).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (несоответствующее поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден.
     
     Если байт SW1='6В', а байт SW2 равен:
     
     '00' - неверно указанные параметры (смещение выходит за пределы EF).
     
     

     6.4 Команда ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     6.4.1 Определение и область применения
     
     Командное сообщение команды ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ устанавливает содержимое (его часть) файла EF в его логическое состояние после стирания последовательно, начиная с заданного смещения.
     
     6.4.2 Условия использования и защиты
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF.
     
     Обработка команды осуществляется в выбранном в текущий момент EF. Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности для функции стирания.
     
     Команда должна прерываться в том случае, если она применяется к EF без прозрачной структуры.
     
     6.4.3 Командное сообщение
     
     Командный APDU команды ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 33.
     
     
 Таблица 33 - Командный APDU команды ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     
     Если бит b8=1 в байте Р1, то биты b7 и b6 байта Р1 устанавливаются в ноль (биты RFU), биты b5-b1 байта Р1 являются коротким идентификатором EF, а байт P2 представляет собой смещение первого байта, подлежащего стиранию, в единицах данных от начала файла.
     
     Если бит b8=0 в байте Р1, то сцепление байтов P1 || P2 представляет собой смещение первого байта, подлежащего стиранию, в единицах данных от начала файла.
     
     Если поле данных представлено, оно кодирует смещение первой единицы данных, не подлежащей стиранию. Это смещение должно превышать смещение, закодированное в байтах Р1, P2. Если поле данных является пустым, команда стирает файл до конца.
     
     6.4.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ представлен в таблице 34.
     
     
Таблица 34 - Ответный APDU команды ИСКЛЮЧИТЬ ДВОИЧНОЕ ЗНАЧЕНИЕ

     
     
     6.4.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешное стирание, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешное стирание).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (несоответствующее поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 paвен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден.
     
     Если байт SW1='6В', а байт SW2 равен:
     
     '00' - неверно указанные параметры (смещение выходит за пределы EF).
     
     

     6.5 Команда СЧИТАТЬ ЗАПИСЬ(И)

     
     6.5.1 Определение и область применения
     
     Ответное сообщение команды СЧИТАТЬ ЗАПИСЬ(И) передает содержимое указанной(ых) записи(ей) (или начальной части одной записи) файла EF.
     
     6.5.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности данного EF для функции считывания.
     
     Если выбор EF осуществляется одновременно с подачей команды, то эта команда может обрабатываться без идентификации данного файла.
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF, а указатель текущей записи - в исходное положение.
     
     Команда должна прерываться в том случае, если она применяется к EF без структуры из записей.
     
     6.5.3 Командное сообщение
     
     Командный APDU команды СЧИТАТЬ ЗАПИСЬ(И) представлен в таблице 35.
     
     
Таблица 35 - Командный APDU команды СЧИТАТЬ ЗАПИСЬ(И)

     
     
Таблица 36 - Кодирование байта управления ссылками Р2
     

     
     
     6.5.4 Ответное сообщение (номинальный случай)
     
     Если поле  содержит только нули, то в зависимости от последовательности битов b3b2b1 в байте Р2 и в пределах максимума 256 (для короткого поля) или 65536 (для расширенного поля) команда должна обеспечивать полное считывание:
     
     - либо одной запрашиваемой записи;
     
     - либо запрашиваемой последовательности записей.
     
     Ответный APDU команды СЧИТАТЬ ЗАПИСЬ(И) представлен в таблице 37.
     
     
Таблица 37 - Ответный APDU команды СЧИТАТЬ ЗАПИСЬ(И)

     
     
     Если записи являются информационными объектами SIMPLE-TLV (см. 5.4.4), то для этого случая в таблицах 38-1 и 38-2 для наглядности представлен формат поля данных ответного сообщения.
     

Таблица 38 -1 - Поле данных ответа в случае считывания одной записи

Случай а). Частичное считывание одной записи

     Этот случай применим, когда поле  содержит не только нули.

Случай б). Полное считывание одной записи

     Этот случай применим, когда поле  содержит одни нули.
     
     
Таблица 38-2 - Поле данных ответа в случае считывания нескольких записей
     

Случай в). Частичное считывание последовательности записей

     Этот случай применим, когда поле  содержит не только нули.
     

Случай г). Считывание многочисленных записей до конца файла

     
     
     Этот случай применим, когда поле  содержит одни нули.
     
     Сравнение длины поля данных с его структурой TLV показывает характер данных: единственная (считывание одной записи) или последняя (считывание всех записей) запись является неполной, полной или дополненной незначащей информацией.
     
     Примечание - Если не используется кодирование в структуре TLV, то результатом функции считывания всех записей будет получение нескольких записей без их стандартного разграничения.
     
     
     6.5.5 Состояния после обработки
     
     Могут возникать следующие специфические состояния предупреждения.
     
     Если байт SW1='62', а байт SW2 равен:
     
     '81' - часть выдаваемых данных может быть искажена;
     
     '82' - конец записи достигнут до считывания  байтов.
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (пустое поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное.
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден;
     
     '83' - запись не найдена.
     
     Если байт SW1='6С', а байт SW2 равен:
     
     'XX' - неверно указанная длина (несоответствующее поле ; 'XX' указывает точную длину).
     
     

     6.6 Команда ВВЕСТИ ЗАПИСЬ

     
     6.6.1 Определение и область применения
     
     Командное сообщение команды ВВЕСТИ ЗАПИСЬ инициирует одну из следующих операций:
     
     - однократную запись передаваемых данных (в виде записи);
     
     - операцию логического сложения "ИЛИ" над байтами данных записи, уже присутствующей в карте, и байтами данных записи, передаваемой в командном APDU;
     
     - операцию логического умножения "И" над байтами данных записи, уже присутствующей в карте, и байтами данных записи, передаваемой в командном APDU.
     
     Если индикация не дается в байте кодирования данных (см. таблицу 86), должна применяться операция логического сложения "ИЛИ".
     
     При использовании адресации текущей записи команда должна устанавливать указатель записи на успешно записанную запись.
     
     6.6.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности данного EF для функций записи.
     
     Если выбор EF осуществляется одновременно с подачей команды, то эта команда может обрабатываться без идентификации данного файла.
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF, а указатель текущей записи - в исходное положение.
     
     Команда должна прерываться в том случае, если она применяется к EF без структуры из записей.
     
     Опция команды "предыдущая" (Р2=ххххх011), примененная к циклическому файлу, ведет себя так же, как команда ПРИСОЕДИНИТЬ ЗАПИСЬ.
     
     6.6.3 Командное сообщение
     
     Командный APDU команды ВВЕСТИ ЗАПИСЬ представлен в таблице 39.
     
     
Таблица 39 - Командный APDU команды ВВЕСТИ ЗАПИСЬ

     
     
 Таблица 40 - Кодирование байта управления ссылками Р2
     

     
     
     Если записи являются информационными объектами SIMPLE-TLV (см. 5.4.4), то для этого случая в таблице 41 для наглядности представлен формат поля данных командного сообщения.
     
     
Таблица 41 - Поле данных команды
     

Полная запись одной записи

     
     
     6.6.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ВВЕСТИ ЗАПИСЬ представлен в таблице 42.
     
     
Таблица 42 - Ответный APDU команды ВВЕСТИ ЗАПИСЬ
     

     
     
     6.6.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешная запись, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешная запись).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (пустое поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден;
     
     '83' - запись не найдена;
     
     '84' - область памяти в файле недостаточна;
     
     '85' -  не согласуется со структурой TLV.
     
     

     6.7 Команда ПРИСОЕДИНИТЬ ЗАПИСЬ

     
     6.7.1 Определение и область применения
     
     Командное сообщение команды ПРИСОЕДИНИТЬ ЗАПИСЬ инициирует либо присоединение записи в конце EF с линейной структурой, либо запись данных (в виде записи с номером 1) в EF с циклической структурой (см. 5.1.4).
     
     Команда должна устанавливать указатель записи на успешно присоединенную запись.
     
     6.7.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности данного EF для функции присоединения.
     
     Если выбор EF осуществляется одновременно с подачей команды, то эта команда может обрабатываться без идентификации данного файла.
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF, а указатель текущей записи - в исходное положение.
     
     Команда должна прерываться в том случае, если она применяется к EF без структуры из записей.
     
     Примечание - Если данная команда применяется к файлу EF с циклической структурой, заполненному записями, то запись с наибольшим номером заменяется и становится записью номер 1.
     
     
     6.7.3 Командное сообщение
     
     Командный APDU команды присоединить ЗАПИСЬ представлен в таблице 43.
     
     
Таблица 43 - Командный APDU команды ПРИСОЕДИНИТЬ ЗАПИСЬ
     

Таблица 44 - Кодирование байта управления ссылками Р2

     
     
     Если записи являются информационными объектами SIMPLE-TLV (см. 5.4.4), то для этого случая в таблице 45 для наглядности представлен формат поля данных командного сообщения.
     
     
Таблица 45 - Поле данных команды
     

Полное присоединение одной записи

     
     
     6.7.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ПРИСОЕДИНИТЬ ЗАПИСЬ представлен в таблице 46.
     
     
Таблица 46 - Ответный APDU команды ПРИСОЕДИНИТЬ ЗАПИСЬ

     
     
     6.7.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешное присоединение записи, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешное присоединение записи).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (пустое поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден;
     
     '84' - область памяти в файле недостаточна;
     
     '85' -   не согласуется со структурой TLV.
     
     

     6.8 Команда ОБНОВИТЬ ЗАПИСЬ

     
     6.8.1 Определение и область применения
     
     Командное сообщение команды ОБНОВИТЬ ЗАПИСЬ инициирует обновление конкретной записи битами, передаваемыми в командном APDU.
     
     При использовании адресации текущей записи команда должна устанавливать указатель записи на успешно обновленную запись.
     
     6.8.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет атрибутам секретности данного EF для функции обновления.
     
     Если выбор EF осуществляется одновременно с подачей команды, то эта команда может обрабатываться без идентификации данного файла.
     
     Если команда содержит разрешенный короткий идентификатор EF, она устанавливает указываемый файл в состояние текущего EF, а указатель текущей записи - в исходное положение.
     
     Команда должна прерываться в том случае, если она применяется к EF без структуры из записей.
     
     Если команда применяется к EF с линейной фиксированной или циклической структурой, то она должна прерываться в том случае, если длина передаваемой записи отличается от длины существующей записи.
     
     Если команда применяется к EF с линейной переменной структурой, то она может быть выполнена, когда длина передаваемой записи отличается от длины существующей записи.
     
     Опция команды "предыдущая" (Р2=ххххх011), примененная к циклическому файлу, ведет себя так же, как команда ПРИСОЕДИНИТЬ ЗАПИСЬ.
     
     6.8.3 Командное сообщение
     
     Командный APDU команды ОБНОВИТЬ ЗАПИСЬ представлен в таблице 47.
     
     
Таблица 47 - Командный APDU команды ОБНОВИТЬ ЗАПИСЬ

     
     
Таблица 48 - Кодирование байта управления ссылками Р2
     

     
     
     Если записи являются информационными объектами SIMPLE-TLV (см. 5.4.4), то для этого случая в таблице 49 для наглядности представлен формат поля данных командного сообщения.
     
     
Таблица 49 - Поле данных команды
     

Полное обновление одной записи

     
     
     6.8.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ОБНОВИТЬ ЗАПИСЬ представлен в таблице 50.
     
     
Таблица 50 - Ответный APDU команды ОБНОВИТЬ ЗАПИСЬ
     

     
     
     6.8.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешное обновление, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешное обновление).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (пустое поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '81' - команда несовместима со структурой файла;
     
     '82' - состояние защиты неудовлетворительное;
     
     '86' - команда невозможна (нет текущего EF).
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден;
     
     '83' - запись не найдена;
     
     '84' - область памяти в файле недостаточна;
     
     '85' -  не согласуется со структурой TLV.
     
     

     6.9 Команда ИЗВЛЕЧЬ ДАННЫЕ

     
     6.9.1 Определение и область применения
     
     Команда ИЗВЛЕЧЬ ДАННЫЕ применяется для поиска одного простого информационного объекта либо одного или большего числа информационных объектов, входящих в составной информационный объект, в пределах текущего контекста (например, среды, связанной с конкретным приложением, или текущего DF).
     
     6.9.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет условиям секретности, определяемым приложением в пределах контекста для функции.
     
     6.9.3 Командное сообщение
     
     Командный APDU команды ИЗВЛЕЧЬ ДАННЫЕ представлен в таблице 51.
     
     
Таблица 51 - Командный APDU команды ИЗВЛЕЧЬ ДАННЫЕ
     

     
     
Таблица 52 - Кодирование последовательности параметров Р1-Р2

     
     
     а) Извлечение данных приложения
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '0100' до '01FF', то оно должно являться идентификатором, зарезервированным для внутренних проверок, осуществляемых картой, и оригинальных услуг, значимых в пределах данного контекста приложения.
     
     б) Извлечение информационных объектов
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '0040' до '00FF', то значение байта Р2 должно являться тегом информационного объекта BER-TLV, состоящим из одного байта. Значение '00FF' зарезервировано для получения всех общих информационных объектов BER-TLV, читаемых в контексте.
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '0200' до '02FF', то значение байта Р2 должно являться тегом информационного объекта SIMPLE-TLV. Значение '0200' является RFU. Значение '02FF' зарезервировано для получения всех общих информационных объектов SIMPLE-TLV, читаемых в контексте.
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '4000' до 'FFFF', то оно должно являться тегом информационного объекта BER-TLV, состоящим из двух байтов. Значения '4000' и 'FFFF' являются RFU.
     
     Если запрашивается простой информационный объект, поле данных ответного сообщения должно содержать значение соответствующего простого информационного объекта.
     
     Если запрашивается составной информационный объект, поле данных ответного сообщения должно содержать значение составного информационного объекта, т.е. информационные объекты, включая их тег, длину и значение.
     
     6.9.4 Ответное сообщение (номинальный случай)
     
     Если поле  содержит только нули, то в пределах максимума 256 (для короткого поля) или 65536 (для расширенного поля) вся запрашиваемая информация должна быть выдана.
     
     Ответный APDU команды ИЗВЛЕЧЬ ДАННЫЕ представлен в таблице 53.
     
     
Таблица 53 - Ответный APDU команды ИЗВЛЕЧЬ ДАННЫЕ
     

     
     
     6.9.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='62', а байт SW2 равен:
     
     '81' - часть выдаваемых данных может быть искажена.
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (пустое поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '82' - состояние защиты неудовлетворительное;
     
     '85' - условия использования не удовлетворены.
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '88' - ссылочные данные (информационные объекты) не найдены.
     
     Если байт SW1='6С', а байт SW2 равен:
     
     'XX' - неверно указанная длина (несоответствующее поле ; 'XX' указывает точную длину).
     
     

     6.10 Команда ПОМЕСТИТЬ ДАННЫЕ

     
     6.10.1 Определение и область применения
     
     Команда ПОМЕСТИТЬ ДАННЫЕ применяется для сохранения одного простого информационного объекта либо одного или большего числа информационных объектов, входящих в составной информационный объект, в пределах текущего контекста (например среды, связанной с конкретным приложением, или текущего DF). Нужные функции сохранения (однократной записи и/или обновления и/или присоединения) должны вызываться по определению или в зависимости от характера информационных объектов.
     
     Примечание - Эта команда могла бы использоваться, например, для обновления информационных объектов.
     
     
     6.10.2 Условия использования и защиты
     
     Команда может быть выполнена только в том случае, если состояние защиты удовлетворяет условиям секретности, определяемым приложением в пределах контекста для функции (й).
     
     6.10.3 Командное сообщение
     
     Ответный APDU команды ПОМЕСТИТЬ ДАННЫЕ представлен в таблице 54.
     
     
Таблица 54 - Командный APDU команды ПОМЕСТИТЬ ДАННЫЕ
     

     
     
Таблица 55 - Кодирование последовательности параметров Р1-Р2
     

     
     
     а) Сохранение данных приложения
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '0100' до '01FF', то оно должно являться идентификатором, зарезервированным для внутренних проверок, осуществляемых картой, и оригинальных услуг, значимых в пределах данного контекста приложения.
     
     б) Сохранение информационных объектов
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '0040' до '00FF', то значение байта P2 должно являться тегом информационного объекта BER-TLV, состоящим из одного байта. Значение '00FF' зарезервировано для указания, что поле данных несет информационные объекты BER-TLV.
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне oт '0200' до '02FF', то значение байта P2 должно являться тегом информационного объекта SIMPLE-TLV. Значение '0200' является RFU. Значение '02FF' зарезервировано для указания, что поле данных несет информационные объекты SIMPLE-TLV.
     
     Если значение последовательности байтов Р1-Р2 находится в диапазоне от '4000' до 'FFFF', то оно должно являться тегом информационного объекта BER-TLV, состоящим их двух байтов. Значения '4000' и 'FFFF' являются RFU.
     
     Если предоставляется простой информационный объект, поле данных командного сообщения должно содержать значение соответствующего простого информационного объекта.
     
     Если предоставляется составной информационный объект, поле данных командного сообщения должно содержать значение составного информационного объекта, т.е. информационные объекты, включая их тег, длину и значение.
     
     6.10.4 Ответное сообщение (номинальный случай)
     
     Ответный APDU команды ПОМЕСТИТЬ ДАННЫЕ представлен в таблице 56.
     
     
Таблица 56 - Ответный APDU команды ПОМЕСТИТЬ ДАННЫЕ

     
     
     6.10.5 Состояния после обработки
     
     Может возникать следующее специфическое состояние предупреждения.
     
     Если байт SW1='63', а байт SW2 равен:
     
     'СХ' - счетчик (успешное сохранение, но после использования внутренней программы повторений; 'X''0' указывает число повторных попыток; 'X'='0' означает, что счетчик не предусмотрен).
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='65', а байт SW2 равен:
     
     '81' - отказ памяти (безуспешное сохранение).
     
     Если байт SW1='67', а байт SW2 равен:
     
     '00' - неверно указанная длина (несоответствующее поле ).
     
     Если байт SW1='69', а байт SW2 равен:
     
     '82' - состояние защиты неудовлетворительное;
     
     '85' - условия использования не удовлетворены.
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '80' - некорректные параметры в поле данных;
     
     '81' - функция не поддерживается;
     
     '84' - область памяти в файле недостаточна;
     
     '85' -  не согласуется со структурой TLV.
     
     

     6.11 Команда ВЫБРАТЬ ФАЙЛ

     
     6.11.1 Определение и область применения
     
     Успешно завершенная команда ВЫБРАТЬ ФАЙЛ устанавливает текущий файл внутри логического канала (см. 5.5). Последующие команды могут в неявной форме обращаться к текущему файлу через этот логический канал.
     
     Выбор DF (который может быть файлом MF) устанавливает его в состояние текущего DF. После такого выбора обращение к неявному текущему EF может осуществляться через этот  логический канал.
     
     Выбор EF устанавливает пару текущих файлов: EF и его родительский файл.
     
     После ответа на восстановление осуществляется неявный выбор файла MF через основной логический канал (см. 5.5.2), если отсутствуют другие указания в байтах предыстории (см. раздел 8) или строке начальных данных (см. раздел 9).
     
     Примечание - Прямой выбор по имени DF может использоваться для выбора приложений, зарегистрированных в соответствии с ИСО/МЭК 7816-5.
     
     
     6.11.2 Условия использования и защиты
     
     Следующие условия должны соблюдаться для каждого открытого логического канала.
     
     Если не дается иных указаний, то правильное выполнение команды изменяет состояние защиты (см. 5.2.1) по следующим правилам.
     
     Если заменяется текущий EF, или текущего EF больше нет, состояние защиты, если оно применялось, ориентированное на предшествующий текущий EF, утрачивается.
     
     Если текущий DF является потомком предшествующего текущего DF или ему идентичен, состояние защиты, ориентированное на предшествующий текущий DF, сохраняется.
     
     Если текущий DF не является потомком предшествующего текущего DF и не идентичен ему, состояние защиты, ориентированное на предшествующий текущий DF, утрачивается. Состояние защиты, общее для всех общих предков предшествующего и нового текущего DF, сохраняется.
     
     6.11.3 Командное сообщение
     
     Командный APDU команды ВЫБРАТЬ ФАЙЛ представлен в таблице 57.
     
     
Таблица 57 - Командный APDU команды ВЫБРАТЬ ФАЙЛ
     

     
     
Таблица 58 - Кодирование байта управления выбором Р1
     

     

Таблица 59 - Кодирование байта опций выбора Р2
     

     
     
     Если байт Р1='00', то карта распознает либо благодаря особому кодированию идентификатора файла, либо из-за контекста выполнения команды, является ли выбираемый файл файлом MF, DF или EF.
     
     Если последовательность байтов Р1-Р2='0000' и предоставляется идентификатор файла, то он должен быть уникальным в следующих средах:
     
     - непосредственные потомки текущего DF,
     
     - родительский DF,
     
     - непосредственные потомки родительского DF.
     
     Если последовательность байтов Р1-Р2='0000' и поле данных пустое или равно '3F00', то осуществляется выбор MF.
     
     Если байт Р1='04', то поле данных представляет собой имя DF, возможно укороченное справа. Если выбор по укороченному имени DF поддерживается, то следующие одна за другой такие команды с одним и тем же полем данных должны выбирать файлы DF, чьи имена совпадают с их полем данных, т.е. с него начинаются. Если карта принимает команду ВЫБРАТЬ ФАЙЛ с пустым полем данных, то может осуществляться последовательный выбор всех файлов DF или их подмножества.
     
     Примечание - О методах выбора, поддерживаемых картой, см. 8.3.6.
     
     
     6.11.4 Ответное сообщение (номинальный случай)
     
     Если поле  содержит только нули, то в пределах максимума 256 (для короткого noля) или 65536 (для расширенного поля) все байты, соответствующие опции выбора, должны быть выданы.
     
     Ответный APDU команды ВЫБРАТЬ ФАЙЛ представлен в таблице 60.
     
     
Таблица 60 - Ответный APDU команды ВЫБРАТЬ ФАЙЛ

     
     
     6.11.5 Состояния после обработки
     
     Могут возникать следующие специфические состояния предупреждения.
     
     Если байт SW1='62', а байт SW2 равен:
     
     '83' - выбранный файл недействителен;
          
     '84' - FCI не форматирована по 5.1.5.
     
     Могут возникать следующие специфические состояния ошибки.
     
     Если байт SW1='6А', а байт SW2 равен:
     
     '81' - функция не поддерживается;
     
     '82' - файл не найден;
     
     '86' - некорректные параметры P1, P2;
     
     '87' -  не согласуется с Р1, Р2.
     
     

     6.12 Команда ВЫПОЛНИТЬ ВЕРИФИКАЦИЮ

     
     6.12.1 Определение и область применения
     
     Команда ВЫПОЛНИТЬ ВЕРИФИКАЦИЮ инициирует сравнение в карте верификационных данных, посылаемых с устройства сопряжения, с контрольными данными, хранимыми в карте (например паролем).
     
     6.12.2 Условия использования и защиты
     
     В результате сравнения состояние защиты может изменяться. Безуспешные операции сравнения могут регистрироваться в карте (например, с целью ограничения числа дальнейших попыток использования контрольных данных).
     
     6.12.3 Командное сообщение
     
     Командный APDU команды ВЫПОЛНИТЬ ВЕРИФИКАЦИЮ представлен в таблице 61.
     
     
Таблица 61 - Командный APDU команды ВЫПОЛНИТЬ ВЕРИФИКАЦИЮ
     

     
     
Таблица 62 - Кодирование байта управления ссылками Р2