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

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 г.

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

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

Пять стандартов из серии ИСО/МЭК 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 ИСО/МЭК "Информационные технологии".

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

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

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

--------------------------------

<1> Заменен на ИСО/МЭК 7816-4:2013.

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

--------------------------------

<2> Заменен на ИСО/МЭК 7816-9:2017.

ISO/IEC 8825-1:2002 <3>, 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) правил кодирования)

--------------------------------

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

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

3.1

3.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- APPLICATION MANAGEMENT REQUEST <1>;

--------------------------------

<1> ЗАПРОС НА УПРАВЛЕНИЕ ПРИЛОЖЕНИЕМ.

- LOAD APPLICATION <2>;

--------------------------------

<2> УСТАНОВИТЬ ПРИЛОЖЕНИЕ.

- REMOVE APPLICATION <3>.

--------------------------------

<3> УДАЛИТЬ ПРИЛОЖЕНИЕ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- команды LOAD APPLICATION;

- команды REMOVE APPLICATION.

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

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

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

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

Команда 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.

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

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

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

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

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

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

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

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

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

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

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

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

Примечание - Следующее поколение IC Card System Study Group <1> (NICSS) использует данную модель.

--------------------------------

<1> Рабочая группа системы идентификационных карт.

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) 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) SELECT приложения с AID 'E8 28 BD 08 0D'.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 = 'Cx' и P2 = 'yz', где 'xyz' - порядковый номер последнего блока Load (предполагается, что 'xyz' меньше, чем 4095).

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

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

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

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

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

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

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

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

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

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

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

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

a) Команда SELECT для выбора приложения с AID 'E8 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'.

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

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

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