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

ГОСТ Р ИСО/МЭК 7816-8-2011

Группа Э46

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

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

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

Часть 8

Команды для операций по защите информации

Identification cards. Integrated circuit cards. Part 8. Commands for information security operations

ОКС 35.240.15
ОКП 40 8470

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

Предисловие

Предисловие

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

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

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

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


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

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

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

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


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

Введение

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

Пять стандартов относятся к картам с гальваническими контактами, три из них определяют электрический интерфейс:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИСО/МЭК 10536 определяет обмен данными при помощи поверхностного действия.

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

Международный стандарт ИСО/МЭК 7816-8 подготовлен подкомитетом 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.

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

В настоящем стандарте применены термины по ИСО/МЭК 7816-4:

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

Примечание - Две операции обладают таким свойством, что при наличии общедоступной операции невозможно произвести закрытую операцию.

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

Примечание - Организация, выдающая сертификат, также выступает в качестве органа распределения тега по отношению к элементам данных в сертификате.

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

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

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

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

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

ССТ - шаблон криптографической контрольной суммы (control reference template for cryptographic checksum);

CRT - шаблон контрольного управления (control reference template);

CT - шаблон конфиденциальности (control reference template for confidentiality);

DSA - алгоритм цифровой подписи (digital signature algorithm);

DST - шаблон цифровой подписи (control reference template for digital signature);

ECDSA - алгоритм цифровой подписи на базе математического аппарата эллиптических кривых (elliptic curve digital signature algorithm);

HT - шаблон хэш-кода (control reference template for hash-code);

MSE - команда УПРАВЛЕНИЕ СРЕДОЙ ЗАЩИТЫ (MANAGE SECURITY ENVIRONMENT command);

PK - открытый ключ (public key);

PSO - команда ВЫПОЛНИТЬ ОПЕРАЦИЮ ЗАЩИТЫ (PERFORM SECURITY OPERATION command);

GQ - Гийу и Кискатер (Guillou and Quisquater);

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

RSA - критосистема Райвеста-Шамира-Адлемана (Rivest, Shamir, Adleman);

SE - среда защиты (security environment);

SEID - идентификатор защитной среды (security environment identifier).

5 Межотраслевые команды для криптографических операций

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

5.1 Команда ГЕНЕРИРОВАТЬ ПАРУ АСИММЕТРИЧНЫХ КЛЮЧЕЙ (GENERATE ASYMMETRIC KEY PAIR)

Команда GENERATE ASYMMETRIC KEY PAIR либо запускает генерацию и хранение асимметричной пары ключей в карте, т.е. открытого ключа и секретного ключа, либо получает доступ к асимметричной паре ключей, созданной ранее в карте (см. таблицу 1).

Данная команда может предшествовать команде MANAGE SECURITY ENVIRONMENT с целью установить генерацию ключей связанных параметров (например, справочник по алгоритмам). Команда может быть выполнена в один или несколько этапов, возможно, с использованием цепочки команд (см. ИСО/МЭК 7816-4).


Таблица 1 - Пара команда-ответ GENERATE ASYMMETRIC KEY PAIR

Окончание таблицы 1

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


Таблица 2 - Управление генерацией в Р1

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

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

В зависимости от четности кода INS (см. ИСО/МЭК 7816-4) открытый ключ в поле данных ответа представляет собой либо последовательность элементов данных ("46"), либо последовательность объектов данных ("47").

Если расширенный список заголовков описывает поле данных ответа, то он неявно известен до подачи команды. Он охватывает открытый ключ объектов данных и другие запрашиваемые объекты данных.

Когда бит 1 устанавливается как единица в INS, т.е. INS устанавливается в значение "47", и открытый ключ возвращается в поле данных ответа, тогда межотраслевой шаблон используется для вложения одного соответствующего набора открытых ключей объектов данных в соответствии с таблицей 3. Если алгоритм не указан в команде, то он известен до подачи команды. В шаблоне открытого ключа контекстно-зависимый класс (первый байт от "80" до "BF") предназначен для открытого ключа объектов данных.


Таблица 3 - Открытый ключ объектов данных

5.2 Команда ВЫПОЛНИТЬ ОПЕРАЦИЮ ЗАЩИТЫ (PERFORM SECURITY OPERATION)

Команда PERFORM SECURITY OPERATION запускает следующие операции защиты в соответствии с объектами данных, определенных в Р1-Р2 (см. таблицу 4):

- вычисление криптографической контрольной суммы;

- вычисление цифровой подписи;

- вычисление хэш-кода;

- верификация криптографической контрольной суммы;

- верификация цифровой подписи;

- верификация хэш-кода;

- шифровка;

- расшифровка.

Если операция защиты требует выполнить несколько команд, то необходимо применять цепочку команд (см. ИСО/МЭК 7816-4).

Команда PERFORM SECURITY OPERATION может предшествовать команде MANAGE SECURITY ENVIRONMENT.

Например, ссылочный ключ, а также ссылочный алгоритм должны быть либо неявно известны, либо заданы в шаблоне CRT в команде MANAGE SECURITY ENVIRONMENT.

Такая команда может быть выполнена, только если защитный статус удовлетворяет атрибутам секретности операции. Успешное выполнение команды может зависеть от успешного завершения предыдущей команды (например, VERIFY (ПРОВЕРИТЬ) перед вычислением цифровой подписи).

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


Таблица 4 - Пара команда-ответ PERFORM SECURITY OPERATION

Команда PERFORM SECURITY OPERATION использует шаблоны входа, перечисленные в таблице 5. Эти шаблоны являются основными объектами данных для безопасного обмена сообщениями (см. ИСО/МЭК 7816-4).


Таблица 5 - Входные шаблоны

Входные шаблоны, контекстно-зависимый класс (первый байт в диапазоне от "80" до "BF") зарезервированы для входных объектов данных. В таблице 6 перечислены объекты данных во входных шаблонах.


Таблица 6 - Входные объекты данных

5.3 Операция ВЫЧИСЛЕНИЕ КРИПТОГРАФИЧЕСКОЙ КОНТРОЛЬНОЙ СУММЫ (COMPUTE CRYPTOGRAPHIC CHECKSUM)

Операция COMPUTE CRYPTOGRAPHIC CHECKSUM запускает вычисление криптографической контрольной суммы (см. таблицу 7).


Таблица 7 - Параметры и поля данных для операции COMPUTE CRYPTOGRAPHIC CHECKSUM

5.4 Операция ВЫЧИСЛЕНИЕ ЦИФРОВОЙ ПОДПИСИ (COMPUTE DIGITAL SIGNATURE)

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

Для вычисления цифровой подписи данные, которые должны быть подписаны или интегрированы в процесс подписания, передаются в командное поле данных или отправляются в предыдущую команду, например PSO: HASH. В Р2 цифровая подпись определяется тегами "9А", "АС" или "ВС" в соответствии со структурой на входе (см. ИСО/МЭК 7816-4).

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

Значение, подлежащее возврату картой, является цифровой подписью (Р1 ="9Е").


Таблица 8 - Параметры и поля данных для операции COMPUTE DIGITAL SIGNATURE

Примечание - Теги "АС" и "ВС" не интегрированы во ввод цифровой подписи.

5.5 Операция ХЭШИРОВАТЬ (HASH)

Операция HASH запускает вычисление хэш-кода двумя способами (см. таблицу 9):

- полное вычисление внутри карты или

- частичное вычисление внутри карты (например, последний цикл хэширования).

Шаблон хэш-кода НТ ("АА", "АВ") указывает ссылочный алгоритм для вычисления хэш-кода (см. ИСО/МЭК 7816-4).

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

Для последующей обработки вычисленного хэш-кода следует различать следующие два случая:

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

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


Таблица 9 - Параметры и поле данных для операции HASH

5.6 Операция ПРОВЕРИТЬ КРИПТОГРАФИЧЕСКУЮ КОНТРОЛЬНУЮ СУММУ (VERIFY CRYPTOGRAPHIC CHECKSUM)

Операция VERIFY CRYPTOGRAPHIC CHECKSUM запускает проверку криптографической контрольной суммы (см. таблицу 10).


Таблица 10 - Параметры и поле данных для операции VERIFY CRYPTOGRAPHIC CHECKSUM

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

5.7 Операция ПРОВЕРИТЬ ЦИФРОВУЮ ПОДПИСЬ (VERIFY DIGITAL SIGNATURE)

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

Открытый ключ, а также алгоритм могут быть:

- или неявно известны,

- или к ним обращаются в шаблоне DST ("B6") команды MANAGE SECURITY ENVIRONMENT,

- или доступны как результат предшествующей операции VERIFY CERTIFICATE (ПРОВЕРИТЬ СЕРТИФИКАТ).

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


Таблица 11 - Параметры и поле данных для операции VERIFY DIGITAL SIGNATURE

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

5.8 Операция ПРОВЕРИТЬ СЕРТИФИКАТ (VERIFY CERTIFICATE)

Для проверки сертификата в карте (см. приложение В) цифровая подпись сертификата, подлежащая проверке, передается как объект данных в поле данных команды. Открытый ключ органа по сертификации, который применяется при проверке, либо находится в карте, либо выбирается неявно, либо к нему можно обратиться в шаблоне DST, используя команду MANAGE SECURITY ENVIRONMENT (см. таблицу 12). Алгоритм, который должен применяться, неявно известен или к нему можно обратиться в шаблоне DST. Если есть другие объекты данных, которые должны использоваться в процессе проверки (например, хэш-код), то они должны находиться в карте или передаваться, используя процесс формирования цепочки команд.

Необходимо различать следующие два случая:

- если сертификат не требует дополнительного описания (Р2 ="BE"), то карта извлекает открытый ключ, установленный по его тегу, в (восстановленном) содержании сертификата;

- если сертификат требует дополнительного описания (Р2 ="АЕ"), то карта извлекает открытый ключ в сертификате неявно или явно, используя тег открытого ключа в списке заголовка, описывающего содержание сертификата.

Если открытый ключ хранится в памяти, то он будет ключом по умолчанию для последующей операции VERIFY DIGITAL SIGNATURE.


Таблица 12 - Параметры и поле данных для операции VERIFY CERTIFICATE

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

5.9 Операция ШИФРОВКА (ENCIPHER)

Операция ENCIPHER шифрует данные, переданные в поле данных команды (см. таблицу 13).

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


Таблица 13 - Параметры и поле данных для операции ENCIPHER

5.10 Операция РАСШИФРОВКА (DECIPHER)

Операция DECIPHER расшифровывает данные, переданные в поле данных команды (см. таблицу 14).


Таблица 14 - Параметры и поле данных для операции DECIPHER

Приложение А (справочное). Примеры операций, связанных с цифровой подписью

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

А.1 Последовательность команд для управления средой защиты

В таблице А.1 представлена последовательность команд MANAGE SECURITY ENVIRONMENT для компонентов SET DST, ССТ, СТ текущей среды защиты и для STORE (ХРАНЕНИЕ) с идентификатором защитной среды SEID, указанным в Р2.


Таблица А.1 - Установка компонентов среды защиты

Операция SET DST обращается к открытому ключу при использовании вычисления подписи и определяет интегрирование случайного числа во вход цифровой подписи. Операция SET CCT обращается к закрытому ключу и начальному значению при использовании вычисления криптографической контрольной суммы. Операция SET CT обращается к сессии закрытого ключа при использовании конфиденциальности.

А.2 Последовательность команд для вычисления цифровой подписи

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


Таблица А.2 - Первый пример схемы цифровой подписи с приложением

_______________
ВОССТАНОВЛЕНИЕ.


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


В таблице А.3 показан синтаксис для создания цифровой подписи с приложением. Ввод цифровой подписи состоит из хэш-кода без заполняющих байтов.


Таблица А.3 - Второй пример схемы цифровой подписи с приложением

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

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


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


Таблица А.4 - Третий пример схемы цифровой подписи с приложением

_______________
УСТАНОВИТЬ.


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


Таблица А.5 - Четвертый пример схемы цифровой подписи с приложением

Примечание - Заполнение для вычисления хэш-кода, а также цифровой подписи осуществляется в соответствии с ИСО/МЭК 9796-2.


В таблице А.6 показано, как карта выполняет хэширование (или последний цикл вычислений с хэшированием). Ввод цифровой подписи остается пустым в операции COMPUTE DIGITAL SIGNATURE, т.к. все входные данные присутствуют в карте.


Таблица А.6 - Пятый пример схемы цифровой подписи с приложением

А.3 Последовательность команд для проверки цифровой подписи

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


Таблица А.7 - Первый пример проверки цифровой подписи

На первом этапе предоставляется объект данных содержания сертификата (сцепление элементов данных: идентификационный номер эмитента (тег "42"), имя держателя карты (тег "5F20") и открытый ключ держателя карты ("5F49")). Карта выполняет хэширование, используя содержание сертификата в качестве хэшированных входных данных.

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

На последнем этапе выполняется операция VERIFY DIGITAL SIGNATURE.

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


Таблица А.8 - Второй пример проверки цифровой подписи

В таблице А.9 показано использование открытого ключа, установленного в карте.


Таблица А.9 - Третий пример проверки цифровой подписи

Приложение В (справочное). Примеры сертификатов, интерпретированных картой

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

В.1 Объекты данных для сертификатов, верифицируемых картой

В таблице В.1 показаны объекты данных, имеющих отношение к сертификатам, верифицируемым картой.


Таблица В.1 - Межотраслевые объекты данных (примеры) для сертификатов, верифицируемых картой

Эмитент может определять дальнейшие объекты данных, такие как серийный номер сертификата, номер версии, дата истечения срока действия и т.д.

Следует различать две структуры сертификатов, верифицируемых картой:

- сертификат, верифицируемый картой и не требующий дополнительного описания, состоит из объединения BER-TLV объектов данных;

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

В.2 Сертификаты, верифицируемые картой и не требующие дополнительного описания

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


Таблица В.2 - Сертификат держателя карты, верифицируемый картой и не требующий дополнительного описания (примеры)

Примечание 1 - Идентификационные данные органа по сертификации могут ссылаться на свой открытый ключ.

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

Примечание 3 - Открытый ключ владельца карты может быть использован в последующей операции VERIFY DIGITAL SIGNATURE.

В.3 Сертификаты, верифицируемые картой и требующие дополнительного описания

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


Таблица В.3 - Сертификат держателя карты, верифицируемый картой и требующий дополнительного описания (примеры)

Приложение С (справочное). Примеры импорта/экспорта асимметричного ключа

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

С.1 Использование команды GET DATA (ИЗВЛЕЧЬ ДАННЫЕ) для экспорта открытого ключа

Предполагается, что объекты данных, описывающие открытый ключ (РК), находятся в карте и закодированы в форме, показанной в таблице С.1.


Таблица С.1 - Кодирование для объекта данных открытого ключа (РК), находящегося в карте

С помощью команды MSE выбирается открытый ключ РК, который должен быть восстановлен. Далее команда GET DATA (нечетный INS, P1-P2 ="3FFF") используется в 3 этапа, в соответствии с которыми поля данных, показанные в таблицах С.2-С.7, осуществляются в интерфейсе карты.


Таблица С.2 - Поле данных команды GET DATA, этап 1 из 3

Таблица С.3 - Поле данных ответа GET DATA, этап 1 из 3

Таблица С.4 - Поле данных команды GET DATA, этап 2 из 3

Таблица С.5 - Поле данных ответа GET DATA, этап 2 из 3

Таблица С.6 - Поле данных команды GET DATA, этап 3 из 3

Таблица С.7 - Поле данных ответа GET DATA, этап 3 из 3

С.2 Использование команды PUT DATA (ПОМЕСТИТЬ ДАННЫЕ) для импорта закрытого ключа

Первоначально команда MSE должна отправить ссылку на соответствующий закрытый ключ (т.е. ссылочный ключ уже известен карте) (см. таблицу С.8). Далее используют команду PUT DATA (нечетный INS, P1-P2 ="3FFF") c полем данных команды, как показано в таблице С.9.


Таблица С.8 - Расширенный список заголовков, описывающий объект закрытого ключа

Таблица С.9 - Поле данных команды PUT DATA

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

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

Таблица ДА.1

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

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