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

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

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

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

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

Часть 13

Команды для управления приложениями в мульти-прикладной среде

Identification cards. Integrated circuit cards. Part 13. Commands for application management in a multi-application environment

ОКС 35.240.15

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

Предисловие

Предисловие

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

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

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 7816-13:2007* "Карты идентификационные. Карты на интегральных схемах. Часть 13. Команды для управления приложениями в мульти-прикладной среде" (ISO/IEC 7816-13:2007 "Identification cards - Integrated circuit cards - Part 13: Commands for application management in a multi-application environment", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


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

5 ВВЕДЕН ВПЕРВЫЕ

6 ПЕРЕИЗДАНИЕ. Декабрь 2018 г.

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


Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Международный стандарт ИСО/МЭК 7816-13 подготовлен подкомитетом N 17 "Карты и идентификация личности" совместного технического комитета N 1 ИСО/МЭК "Информационные технологии".

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

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

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

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


ISO/IEC 7816-4:2005, Identification cards - Integrated circuit cards - Part 4: Organization, security and commands for interchange (Карты идентификационные. Карты на интегральных схемах. Часть 4. Организация, защита и команды для обмена)
________________
Заменен на ИСО/МЭК 7816-4:2013.


ISO/IEC 7816-9:2004, Identification cards - Integrated circuit cards - Part 9: Commands for card management (Карты идентификационные. Карты на интегральных схемах. Часть 9. Команды для управления картами)
________________
Заменен на ИСО/МЭК 7816-9:2017.


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

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

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

3.1

3.2

3.3 платформа карты (card platform): Элемент на карте, отвечающий за базовые функции карты.

3.4 приложение для управления картой (card manager application): Приложение карты, которое обеспечивает функционирование системы управления приложениями и контроль за распределением ресурсов карт.

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

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

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

APP - приложение (application);

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

DO - информационный объект (data object);

ICC - карта на интегральной схеме (integrated circuit card);

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

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

5 Мульти-прикладная среда и жизненный цикл приложения

5.1 Мульти-прикладная среда

Мульти-прикладная среда в контексте настоящего стандарта имеет следующие характеристики:

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

b) приложение может быть добавлено на карту до или после выдачи карты держателю;

c) на карту можно добавить более одного приложения;

d) платформа карты обеспечивает механизмы для управления ресурсами карты, например, памятью;

e) платформа карты обеспечивает механизмы создания границ зоны безопасности для каждого приложения для предотвращения несанкционированного взаимодействия и нарушения безопасности какого-либо другого приложения на карте;

f) провайдер приложения - это организация, которая предоставляет услуги держателю карты, используя приложение карты, и отвечает за работу этого приложения;

g) провайдер приложения на карте может не быть эмитентом карты;

h) жизненный цикл приложения не зависит от жизненного цикла какого-либо другого приложения на той же карте;

i) жизненный цикл приложения не зависит от жизненного цикла карты, за исключением случая, когда карта находится в состоянии завершения жизненного цикла по ИСО/МЭК 7816-9;

j) все приложения должны быть, как минимум, выбираемыми с использованием команды SELECT при указании их AID в качестве имени DF, как определено в ИСО/МЭК 7816-4;

k) приложение для управления картой должно присутствовать, быть уникальным и выбираемым, используя команду SELECT, при указании его AID в качестве имени DF. Остальные приложения на карте могут предлагать функциональные возможности по управлению приложениями;

l) значение AID по умолчанию для приложения для управления картой - "Е8 28 BD 08 0D".

На рисунке 1 показано концептуальное представление возможной структуры мульти-прикладной IC карты.

Рисунок 1 - Возможная структура мульти-прикладной карты

5.2 Жизненный цикл приложения

Состояние жизненного цикла должно быть связано с каждым приложением.

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

Следующие команды инициируют переходы между состояниями жизненного цикла:

- APPLICATION MANAGEMENT REQUEST;
________________
ЗАПРОС НА УПРАВЛЕНИЕ ПРИЛОЖЕНИЕМ.


- LOAD APPLICATION;
________________
УСТАНОВИТЬ ПРИЛОЖЕНИЕ.


- REMOVE APPLICATION.
________________
УДАЛИТЬ ПРИЛОЖЕНИЕ.


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

Рисунок 2 - Диаграмма жизненного цикла приложения

Примечание 1 - Диаграмма говорит о следующем: например, после выполнения команд APPLICATION MANAGEMENT REQUEST (P1='0E') и LOAD APPLICATION приложение находится в Рабочем Активированном Состоянии жизненного цикла, т.е. выполняемом и выбираемом.

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

Примечание 3 - Команды ACTIVATE FILE и DEACTIVATE FILE определены в ИСО/МЭК 7816-9.


Состояния жизненного цикла приложения определены в таблице 1.

Кодирование состояний жизненного цикла должно соответствовать кодированию байта состояний жизненного цикла (байт LCS) по ИСО/МЭК 7816-4.


Таблица 1 - Состояния жизненного цикла приложения

5.3 Информационный объект "распределение ресурсов памяти" для операционной совместимости

Шаблон "распределение ресурсов памяти" (тег "7F65"), описывающий распределение ресурсов памяти в приложении, может быть связан с каждым приложением.

В таблице 2 определены информационные объекты "распределение ресурсов памяти" для каждого типа памяти: постоянное запоминающее устройство и энергозависимая память, где:

- резервная память - это объем памяти, отведенный исключительно для приложения;

- квота памяти - это максимальный объем памяти, который приложение может запросить.

Информационный объект "распределение ресурсов памяти" представляет собой объем ресурсов памяти, отсчитываемый в байтах и кодированный как целое число, см. ИСО/МЭК 8825-1.


Таблица 2 - Информационный объект "распределение ресурсов памяти"

При использовании значений информационного объекта "распределение ресурсов памяти" следует применять следующие правила:

- распределение резервной памяти приложению уменьшает ресурсы памяти, доступные для других приложений на карте;

- распределение квоты памяти приложению не уменьшает ресурсы памяти, доступные для других приложений на карте;

- значение квоты памяти больше или равно значению резервной памяти;

- во время успешного создания приложения (например, при переходе из состояния "Не существует" в Рабочее Активированное состояние) объем памяти, выделенный этому приложению, загружается в первую очередь за счет резервной памяти, предназначенной для этого приложения, до тех пор, пока она не будет полностью исчерпана. Когда резервная память приложения будет исчерпана, объем выделенной памяти будет уменьшать ресурсы памяти, доступные для других приложений на карте, до тех пор, пока он не превысит квоту памяти этого приложения. Когда квота памяти будет превышена или ресурсы памяти, доступные на карте в данный момент, будут исчерпаны, то при создании приложения будет сбой;

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

6 Классификация системы управления картой

6.1 Шаблон системы управления картой

Шаблон системы управления картой (тег '7F64') должен присутствовать. В таблице 3 определено содержание шаблона системы управления картой.


Таблица 3 - Шаблон системы управления картой

Таблица 4 - Функциональные возможности управления картой: Первый байт

Таблица 5 - Функциональные возможности управления картой: Второй байт

6.2 Извлечение шаблона системы управления картой

Извлечение шаблона системы управления картой использует услуги карты, не зависимые от приложения, по ИСО/МЭК 7816-4.

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

Можно применить две процедуры для извлечения шаблона системы управления картой, когда выбран MF или неявно выбираемый DF приложения:

- чтение EF.ATR, где DO '7F64' может присутствовать;

- использование команды GET DATA с P1-P2, установленными в '7F64', которая может вернуть шаблон системы управления картой в поле данных ответа.

Другие процедуры могут применяться и состоять из выбора приложения с AID 'Е8 28 BD 08 0D', за которым следует команда GET DATA с P1-P2, установленными в '7F64', которая может вернуть шаблон системы управления картой в поле данных ответа.

7 Команды для управления приложением

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

- команды APPLICATION MANAGEMENT REQUEST;

- команды LOAD APPLICATION;

- команды REMOVE APPLICATION.

Приложение для управления картой должно поддерживать, как минимум, первые две команды.

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

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

7.1 Команда APPLICATION MANAGEMENT REQUEST

Команда APPLICATION MANAGEMENT REQUEST запускает методику управления приложением. Приложение для управления картой проверяет информацию о запросе на управление приложением, присутствующую в поле данных команды. Данная команда может следовать за командой LOAD APPLICATION, описанной в 7.2. Если поддерживается управление ресурсами памяти, то распределение ресурсов памяти для приложения, как описано в шаблоне распределения ресурсов памяти (тег '7F65') должно соответствовать правилам, определенным в 5.3.


Таблица 6 - Пара команда-ответ APPLICATION MANAGEMENT REQUEST

Таблица 7 - Контроль искомого состояния жизненного цикла приложения в P1

Таблица 8 - Контроль управления приложением в P2

7.2 Команда LOAD APPLICATION

Команда LOAD APPLICATION пересылает приложение карте. Приложение может быть разделено на несколько компонентов, а каждый компонент может быть разделен на несколько блоков для передачи в карту. Каждая команда LOAD APPLICATION пересылает в карту один блок. Данная команда может предшествовать команде APPLICATION MANAGEMENT REQUEST, см. 7.1.

Если команда LOAD APPLICATION предшествует команде APPLICATION MANAGEMENT REQUEST, то распределение ресурсов памяти обеспечивается непосредственно предшествующей командой APPLICATION MANAGEMENT REQUEST. Успешное выполнение данной последовательности команд совершает переход жизненного цикла, указанного в непосредственно предшествующей команде APPLICATION MANAGEMENT REQUEST.

Если команда LOAD APPLICATION не предшествует команде APPLICATION MANAGEMENT REQUEST, то распределение ресурсов памяти и установление состояния жизненного цикла приложения в соответствующее значение осуществляется на основе информации, предоставленной последовательностью команд LOAD APPLICATION.

Если поддерживается распределение ресурсов памяти, то объем памяти, выделенный на успешно созданное приложение, должен соответствовать правилам, определенным в 5.3.


Таблица 9 - Пара команда-ответ LOAD APPLICATION

Таблица 10 - Порядковый номер или смещение в P1 и P2

7.3 Команда REMOVE APPLICATION

Команда REMOVE APPLICATION (см. таблицу 11) удаляет приложение и возможно восстанавливает ресурсы памяти, которые были выделены для этого приложения.

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

Если поддерживается управление ресурсами памяти, то успешное удаление приложения должно увеличить ресурсы памяти, доступные для приложений на карте, в соответствии с правилами, определенными в 5.3.


Таблица 11 - Пара команда-ответ REMOVE APPLICATION

Таблица 12 - Контроль состояния удаления в P1

7.4 Принципы управления приложением

Схема управления картой и/или установки эмитентов карт определяют требуемые тип и число подписей:

- подпись эмитента карты;

- подпись провайдера приложения;

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

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

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

Приложение A (справочное). Пример управления приложением карты для модели независимых эмитента карты и провайдера приложения

Приложение A
(справочное)

A.1 Введение

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

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

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

Примечание - Следующее поколение IC Card System Study Group (NICSS) использует данную модель.
________________
Рабочая группа системы идентификационных карт

Рисунок A.1 - Модель независимых эмитента карты и провайдера приложения

A.2 Примеры процедур управления приложением

A.2.1 Случай APR, независимого от CI (удаленный CI): проверка сертификата до установки приложения

a) SELECT приложения с AID 'E8 28 BD 08 0D'.

b) GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) SELECT приложения для управления картой с AID (тег '4F'), указанным в шаблоне системы управления картой.

d) Взаимная аутентификация.

e) Получение сертификата создания приложения от эмитента карты (онлайн/оффлайн). Сертификат может содержать AID, хэш-значение приложения, подтверждение ID, ID карты и цифровую подпись эмитента карты.

f) APPLICATION MANAGEMENT REQUEST с сертификатом.

g) Установка приложения с помощью LOAD APPLICATION.

A.2.2 Случай удаленного CI: проверка сертификата после установки приложения

a) SELECT приложения с AID 'E8 28 BD 08 0D'.

b) GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) SELECT приложения для управления картой с AID (тег '4F'), указанным в шаблоне системы управления картой.

d) Взаимная аутентификация.

e) Получение сертификата создания приложения от эмитента карты.

f) APPLICATION MANAGEMENT REQUEST без сертификата для выделения памяти.

g) Установка приложения с помощью LOAD APPLICATION.

h) APPLICATION MANAGEMENT REQUEST с сертификатом.

A.3 Примеры процедур удаления

A.3.1 Случай удаленного CI: проверка сертификата во время удаления приложения

a) SELECT приложения с AID 'Е8 28 BD 08 0D'.

b) GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) SELECT приложения для управления картой с AID (тег '4F'), указанным в шаблоне системы управления картой.

d) Взаимная аутентификация.

e) Получение сертификата удаления приложения от эмитента карты (онлайн/оффлайн). Сертификат может содержать AID, подтверждение ID, ID карты и цифровую подпись эмитента карты.

f) REMOVE APPLICATION с сертификатом.

A.3.2 Случай удаленного CI: проверка сертификата до удаления приложения

a) SELECT приложения с AID 'Е8 28 BD 08 0D'.

b) GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) SELECT приложения для управления картой с AID (тег '4F'), указанным в шаблоне системы управления картой.

d) Взаимная аутентификация.

e) Получение сертификата удаления приложения от эмитента карты.

f) APPLICATION MANAGEMENT REQUEST с сертификатом.

g) REMOVE APPLICATION без сертификата.

Приложение B (справочное). Пример практического осуществления управления приложением карты

Приложение B
(справочное)

B.1 Введение

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

Примечание - Данную модель использует GlobalPlatform (GP).


Приложение составляет код приложения и данные приложения. Код приложения (но не данные приложения) устанавливается в карту с помощью объекта "Load". При инсталляции приложения создается экземпляр объекта "Load" и, возможно, некоторые данные приложения.

В данном примере создание и активация приложения требуют дополнительно:

- предыдущую аутентификацию системы управления приложением для карт (CAMS);

- защиту команд и запросов с помощью безопасного обмена сообщениями;

- проверку сертификатов эмитентов карт.

B.2 Команды для управления приложением

B.2.1 Команда APPLICATION MANAGEMENT REQUEST

Команда APPLICATION MANAGEMENT REQUEST выдается для того, чтобы запустить и выполнить различные шаги для установки объекта "Load" и инициализации и активации экземпляра приложения.


Таблица B.1 - Пара команда-ответ APPLICATION MANAGEMENT REQUEST

Параметр P1 в команде APPLICATION MANAGEMENT REQUEST описывает назначение команды и закодирован в соответствии с таблицей B.2.


Таблица B.2 - Контроль целевого состояния жизненного цикла приложения в P1

Таблица B.3 - Контроль управления приложением в P2

В данном примере команда APPLICATION MANAGEMENT REQUEST вызывается дважды:

- С b2=1 в параметре P1 и P2, установленном на '01', для того, чтобы запустить установку кода приложения (объект "Load"). Поле данных команды содержит идентификационную информацию объекта "Load", идентификационную информацию провайдера приложения, информацию распределения ресурсов памяти объекта "Load", хэш-информацию объекта "Load" и сертификат создания приложения, выпускаемый эмитентом карты. Поле данных ответа не возвращается в ответном сообщении. Следует одна или несколько команд LOAD APPLICATION. При успешном выполнении последней команды LOAD APPLICATION создание запроса на управления приложением неявно фиксируется и состояние жизненного цикла приложения устанавливается в состояние "Создание".

- С комбинацией b4=1 и b3=1 в параметре P1 и P2, установленном в '03' для того, чтобы синхронизированно установить и активировать экземпляр приложения. Поле данных команды содержит идентификационную информацию об уже установленном объекте "Load", идентификационную информацию экземпляра приложения, информацию распределения ресурсов памяти на экземпляр приложения и сертификат инициализации и активации приложения, выданный эмитентом карты. При успешном выполнении команда состояние жизненного цикла приложения меняется с состояния "Создание" на "Рабочее Активированное". Поле данных ответа может быть возвращено в ответное сообщение. Если имеется, информационное наполнение поля данных ответа содержит длину (кодированную в соответствии с правилами ACH.1, определенными в ИСО/МЭК 8825-1) и значение подтверждения инициализации и активации приложения.

B.2.2 Команда LOAD APPLICATION

Объект "Load" делится на множество блоков: блоки "Load" для передачи в карту. Команда LOAD APPLICATION запускает передачу блока Load в карту. Для передачи объекта "Load" в карту может потребоваться множество команд LOAD APPLICATION.


Таблица В.4 - Пара команда-ответ LOAD APPLICATION

Параметры P1 и P2 команды LOAD APPLICATION описывают последовательность блоков Load и кодированы в соответствии с таблицами B.5 и B.6.


Таблица B.5 - Порядковый номер самого старшего байта в P1

Таблица B.6 - Порядковый номер самого младшего байта в P2

Первая команда LOAD APPLICATION предшествует APPLICATION MANAGEMENT REQUEST для команды создания (b2 в P1 установлен на 1).

Порядковый номер блока Load (младше четырнадцати бит P1-P2) начинается с нуля. Нумерация блока Load строго последовательная и увеличивается на единицу. Карте передаются данные о последнем блоке объекта "Load" (b8 в P1 команды LOAD APPLICATION устанавливается на 1).

Поле данных ответа может быть возвращено в ответном сообщении. Если имеется, информационное наполнение поля данных ответа содержит длину (кодированную в соответствии с правилами ACH.1 по ИСО/МЭК 8825-1) и значение подтверждения создания приложения. Оно присутствует только в поле данных ответа команды LOAD APPLICATION, передающей последний блок Load (b8 в P1 установлен на 1).

Для команд LOAD APPLICATION, отличных от последней команды LOAD APPLICATION, передающей последний блок Load (b8 в P1 установлен на 1), поля данных ответа нет.

B.3 Порядок управления приложением

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

a) SELECT приложение с AID 'E8 28 BD 08 0D'.

b) GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) SELECT приложения для управления картой с AID (тег '4F'), указанным в шаблоне системы управления картой.

d) APPLICATION MANAGEMENT REQUEST для создания с параметрами P1='02' и P2='01'.

e) Первая команда LOAD APPLICATION с параметрами P1='40' и P2='00'.

f) Множество команд LOAD APPLICATION с последовательно возрастающими параметрами P1-P2.

g) Последняя команда LOAD APPLICATION с P1='Сх' и P2='yz', где 'xyz' - порядковый номер последнего блока Load (предполагается, что 'xyz' меньше, чем 4095).

h) APPLICATION MANAGEMENT REQUEST для инициализации и активации с P1='0C' и P2='03'.

Приложение C (справочное). Дополнительные практические примеры управления приложением карты

Приложение C
(справочное)

C.1 Введение

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

Примечание - Данную модель использует MULTOS.


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

C.2 Команды для управления приложением

C.2.1 Команда APPLICATION MANAGEMENT REQUEST

Команду APPLICATION MANAGEMENT REQUEST вызывают для инициализации и завершения процессов установки приложения.


Таблица C.1 - Пара команда-ответ APPLICATION MANAGEMENT REQUEST

Параметр P1 команды APPLICATION MANAGEMENT REQUEST описывает назначение команды и кодирован в соответствии с таблицей C.2.


Таблица C.2 - Кодирование P1 в команде APPLICATION MANAGEMENT REQUEST

Параметр P2 команды APPLICATION MANAGEMENT REQUEST описывает назначение команды и кодирован в соответствии с таблицей C.3.


Таблица C.3 - Кодирование P2 в команде APPLICATION MANAGEMENT REQUEST

C.2.2 Команда LOAD APPLICATION

Модуль Установки Приложения делится для передачи в карту на меньшие Компоненты. Команда LOAD APPLICATION запускает передачу Компонента в карту. Для передачи Модуля Установки Приложения в карту может быть использовано множество команд LOAD APPLICATION.


Таблица C.4 - Пара команда-ответ LOAD APPLICATION

Параметры P1 и P2 команды LOAD APPLICATION описывают порядковый номер Компонентов и кодированы в соответствии с таблицами C.5 и C.6.


Таблица С.5 - Кодирование P1 в команде LOAD APPLICATION

Таблица C.6 - Кодирование Р2 в команде LOAD APPLICATION

Первая команда LOAD APPLICATION предшествует команде APPLICATION MANAGEMENT REQUEST.

Порядковый номер блока Load (младшие четырнадцать бит P1-P2) начинается с нуля. Нумерация блока Load строго последовательна и возрастает на единицу. Карте передаются данные последнего блока объекта Load (b8 в P1 установлен на 1).

C.3 Порядок управления приложением

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

a) Команда SELECT для выбора приложения с AID 'Е8 28 BD 08 0D'.

b) Команда GET DATA для извлечения шаблона системы управления картой (тег '7F64').

c) Команда SELECT для выбора приложения для управления картой.

d) Команда APPLICATION MANAGEMENT REQUEST для проверки запроса на рабочую активацию P1='0E' и P2='01'.

e) Первая команда LOAD APPLICATION с параметрами P1='40' и P2='00'.

f) Множество команд LOAD APPLICATION с последовательно возрастающими параметрами P1-P2.

g) Последняя команда LOAD APPLICATION с P1='Cx' и P2='yz', где 'xyz' - порядковый номер последнего блока Load.

h) Команда APPLICATION MANAGEMENT REQUEST для рабочей активации с P1='0E' и P2='03'.

Приложение D (справочное). Дополнительные практические примеры управления приложением карты

Приложение D
(справочное)

Следующий пример показывает использование команды LOAD APPLICATION в качестве оболочки команд для инсталляции приложения. Это позволяет контролировать весь цикл установки, используя правило однократного доступа для команды LOAD APPLICATION, например, внешнюю аутентификацию с необходимым согласованием ключей для безопасного обмена сообщениями. Такая процедура аутентификации может быть выполнена системой управления приложением для карт (CAMS).

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

Примечание 2 - Команда-на-выполнение в поле данных команды кодируется без использования безопасного обмена сообщениями.


Таблица D.1 - Пара команда-ответ LOAD APPLICATION

Таблица D.2 - Пара команда-ответ LOAD APPLICATION

Таблица D.3 - Пара команда-ответ LOAD APPLICATION

Таблица D.4 - Пара команда-ответ LOAD APPLICATION

Приложение ДА (справочное). Сведения о соответствии ссылочных международных стандартов национальным стандартам

Приложение ДА
(справочное)

Таблица ДА.1

Библиография

Электронный текст документа
и сверен по:
официальное издание
М.: Стандартинформ, 2019