ГОСТ Р ИСО/МЭК 7816-8-2011. Национальный стандарт Российской Федерации. Карты идентификационные. Карты на интегральных схемах. Часть 8. Команды для операций по защите информации
Актуально на 02.11.2026.
Как цитировать: "ГОСТ Р ИСО/МЭК 7816-8-2011. Национальный стандарт Российской Федерации. Карты идентификационные. Карты на интегральных схемах. Часть 8. Команды для операций по защите информации". ГОСТ Р ИСО/МЭК 7816-8-2011. https://bukva.ai/docs/gost-r-isomek-7816-8-2011
(утв. и введен в действие Приказом Росстандарта от 13.12.2011 № 1009-ст)
Примечание
Документ введен в действие с 1 января 2013 года.
Приказом Федерального
агентства по техническому
регулированию и метрологии
от 13 декабря 2011 г. № 1009-ст
КОМАНДЫ ДЛЯ ОПЕРАЦИЙ ПО ЗАЩИТЕ ИНФОРМАЦИИ
Identification cards. Integrated circuit cards. Part 8. Commands for security operations
ISO/IEC 7816-8:2004 Identification cards — Integrated circuit cards — Part 8: Commands for security operations (IDT)
Дата введения
1 января 2013 года
Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. № 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизация в Российской Федерации. Основные положения».
1. Подготовлен Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации и сертификации в машиностроении» (ВНИИНМАШ) и Техническим комитетом по стандартизации ТК 22 «Информационные технологии» на основе собственного аутентичного перевода на русский язык стандарта, указанного в пункте 4.
2. Внесен Техническим комитетом по стандартизации ТК 22 «Информационные технологии».
3. Утвержден и введен в действие Приказом Федерального агентства по техническому регулированию и метрологии от 13 декабря 2011 г. № 1009-ст.
4. Настоящий стандарт идентичен международному стандарту ИСО/МЭК 7816-8:2004 «Карты идентификационные. Карты на интегральных схемах. Часть 8. Команды для операций по защите информации» (ISO/IEC 7816-8:2004 «Identification cards — Integrated circuit cards — Part 8: Commands for security operations»).
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном Приложении ДА.
6. Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектами патентных прав. Международная организация по стандартизации не несет ответственность за идентификацию подобных патентных прав.
Информация об изменениях к настоящему стандарту публикуется в ежегодно издаваемом информационном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячно издаваемых информационных указателях «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячно издаваемом информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет.
Серия стандартов ИСО/МЭК 7816 определяет требования к параметрам карт на интегральных схемах и способы их использования в рамках международного обмена информацией. Данные идентификационные карты предназначены для обмена информацией, основанного на согласованиях между внешним источником и интегральной схемой карты. В результате информационного обмена карта выдает информацию (результат вычислений, хранимые данные) и/или изменяет свое содержимое (память данных, память событий).
Пять стандартов относятся к картам с гальваническими контактами, три из них определяют электрический интерфейс:
ИСО/МЭК 7816-1 — определяет физические характеристики карт с контактами;
ИСО/МЭК 7816-2 — определяет размеры и расположение контактов;
ИСО/МЭК 7816-3 — определяет электрический интерфейс и протоколы передачи для асинхронных карт;
ИСО/МЭК 7816-10 — определяет электрический интерфейс и ответ на восстановление для синхронных карт;
ИСО/МЭК 7816-12 — определяет электрический интерфейс и рабочие процедуры для USB-карт.
Все остальные стандарты не зависят от технологии физического интерфейса. Они применяются к картам, подключаемым при помощи контактов и/или радиочастоты:
ИСО/МЭК 7816-4 — определяет организацию, защиту и команды для обмена информацией;
ИСО/МЭК 7816-6 — определяет элементы данных для межотраслевого обмена;
ИСО/МЭК 7816-7 — определяет команды для языка структурированных запросов для карты;
ИСО/МЭК 7816-8 — определяет команды, обеспечивающие операции по защите информации;
ИСО/МЭК 7816-9 — определяет команды для управления картами;
ИСО/МЭК 7816-11 — определяет удостоверение личности биометрическими методами;
ИСО/МЭК 7816-15 — определяет приложение с криптографической информацией;
ИСО/МЭК 10536 — определяет обмен данными при помощи поверхностного действия. ИСО/МЭК 14443 и 15693 определяют радиочастотный доступ. Такие карты известны как бесконтактные карты.
Международный стандарт ИСО/МЭК 7816-8 подготовлен подкомитетом № 17 «Карты и идентификация личности» совместного технического комитета № 1 ИСО/МЭК «Информационные технологии».
Настоящий стандарт определяет межотраслевые команды для карты, которые могут быть использованы для операций криптографии.
Выбор и условия использования механизмов криптографии могут влиять на экспортные возможности карты.
Настоящий стандарт не устанавливает требования к оценке приемлемости алгоритмов и протоков.
Настоящий стандарт не распространяется на реализацию обмена данными внутри карты и/или внешнего окружения.
В настоящем стандарте использована нормативная ссылка на следующий международный стандарт:
ИСО/МЭК 7816-4:2005 Идентификационные карты. Карты на интегральных схемах. Организация, защита и команды для обмена информацией (ISO/IEC 7816-4:2005, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange)
В настоящем стандарте применены термины по ИСО/МЭК 7816-4:
3.1. Метод асимметричного криптографического алгоритма (asymmetric cryptographic technique): криптографический метод, который использует две связанные между собой операции: общедоступную операцию, определенную общедоступным набором чисел или открытым ключом, и закрытую операцию, определенную закрытым набором чисел или секретным ключом.
Примечание. Две операции обладают таким свойством, что при наличии общедоступной операции невозможно произвести закрытую операцию.
3.2. Сертификат (certificate): цифровая подпись, связывающая определенный субъект или объект с его связанным открытым ключом.
Примечание. Организация, выдающая сертификат, также выступает в качестве органа распределения тега по отношению к элементам данных в сертификате.
3.3. Цифровая подпись (digital signature): присоединенные данные или криптографическое преобразование строковых данных, которые доказывают подлинность и целостность строковых данных и защиту от подделок, например, получателем строковых данных.
3.4. Ключ (key): последовательность символов управления криптографической операцией (например, шифровка, расшифровка, закрытая или общедоступная операция в динамической аутентификации, подписи производства, верификация подписи).
3.5. Безопасный обмен сообщениями (secure messaging): совокупность средств для криптографической защиты пары (частей пары) команда-ответ.
CCT — шаблон криптографической контрольной суммы (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).
Пара команда-ответ GENERATE ASYMMETRIC KEY PAIR
| CLA | Как определено в ИСО/МЭК 7816-4 |
|---|---|
| INS | «46» или «47» |
| P1 | Управление генерацией в соответствии с таблицей 2 |
| P2 | «00» (информация не предоставлена) или ссылка на ключ будет сгенерирована |
| Поле L_{c} | Отсутствует для кодирования Nc = 0, присутствует для кодирования Nc > 0 |
| Поле данных | Отсутствует или представляет собой закрытые данные, если P1 — P2 установлено как «0000», или один или более шаблонов СРТ, связанных с генерацией ключа, если значение P1 — P2 отлично от «0000» (см. примечание) |
| Поле L_{e} | Отсутствует для кодирования Ne = 0, присутствует для кодирования Ne > 0 |
Примечание. Если пара ключей сгенерирована для нескольких пользователей, то имеется несколько шаблонов CRT. В поле данных шаблон CRT может иметь нулевую длину.
Данная команда может предшествовать команде MANAGE SECURITY ENVIRONMENT с целью установить генерацию ключей связанных параметров (например, справочник по алгоритмам). Команда может быть выполнена в один или несколько этапов, возможно, с использованием цепочки команд (см. ИСО/МЭК 7816-4).
Для генерации пары ключей при отсутствии поля L_{e} пара ключей хранится в карте, возможно, в файле EF, ссылка на который известна до подачи команды.
Для организации доступа к паре ключей (без генерации) поле данных команды может быть пустым.
В зависимости от четности кода INS (см. ИСО/МЭК 7816-4) открытый ключ в поле данных ответа представляет собой либо последовательность элементов данных («46»), либо последовательность объектов данных («47»).
Если расширенный список заголовков описывает поле данных ответа, то он неявно известен до подачи команды. Он охватывает открытый ключ объектов данных и другие запрашиваемые объекты данных.
Когда бит 1 устанавливается как единица в INS, т.е. INS устанавливается в значение «47», и открытый ключ возвращается в поле данных ответа, тогда межотраслевой шаблон используется для вложения одного соответствующего набора открытых ключей объектов данных в соответствии с таблицей 3. Если алгоритм не указан в команде, то он известен до подачи команды. В шаблоне открытого ключа контекстно-зависимый класс (первый байт от «80» до «BF») предназначен для открытого ключа объектов данных.
5.2 Команда ВЫПОЛНИТЬ ОПЕРАЦИЮ ЗАЩИТЫ (PERFORM SECURITY OPERATION)
Команда PERFORM SECURITY OPERATION запускает следующие операции защиты в соответствии с объектами данных, определенных в P1 — P2 (см. таблицу 4):
- вычисление криптографической контрольной суммы;
- вычисление цифровой подписи;
- вычисление хэш-кода;
- верификация криптографической контрольной суммы;
- верификация цифровой подписи;
- верификация хэш-кода;
Пара команда-ответ PERFORM SECURITY OPERATION
| Поле данных | Отсутствует или имеет значение объектов данных, заданных в P1 |
|---|---|
| SW1-SW2 | См. ИСО/МЭК 7816-4, таблицы 5 и 6, где соответствие, например 6985 |
Если операция защиты требует выполнить несколько команд, то необходимо применять цепочку команд (см. ИСО/МЭК 7816-4).
Команда PERFORM SECURITY OPERATION может предшествовать команде MANAGE SECURITY ENVIRONMENT.
Например, ссылочный ключ, а также ссылочный алгоритм должны быть либо неявно известны, либо заданы в шаблоне CRT в команде MANAGE SECURITY ENVIRONMENT.
Такая команда может быть выполнена, только если защитный статус удовлетворяет атрибутам секретности операции. Успешное выполнение команды может зависеть от успешного завершения предыдущей команды (например, VERIFY (ПРОВЕРИТЬ) перед вычислением цифровой подписи).
Список заголовков или расширенный список заголовков определяет порядок и пункты данных, которые формируют вход для операций защиты.
Команда PERFORM SECURITY OPERATION использует шаблоны входа, перечисленные в таблице 5. Эти шаблоны являются основными объектами данных для безопасного обмена сообщениями (см. ИСО/МЭК 7816-4).
Входные шаблоны, контекстно-зависимый класс (первый байт в диапазоне от «80» до «BF») зарезервированы для входных объектов данных. В таблице 6 перечислены объекты данных во входных шаблонах.
5.3 Операция ВЫЧИСЛЕНИЕ КРИПТОГРАФИЧЕСКОЙ КОНТРОЛЬНОЙ СУММЫ (COMPUTE CRYPTOGRAPHIC CHECKSUM)
Операция COMPUTE CRYPTOGRAPHIC CHECKSUM запускает вычисление криптографической контрольной суммы (см. таблицу 7).
Параметры и поля данных для операции COMPUTE CRYPTOGRAPHIC CHECKSUM
| P1 | «8E» |
|---|---|
| P2 | «80» |
| Командное поле данных | Данные, для которых должна быть вычислена криптографическая контрольная сумма |
| Ответное поле данных | Криптографическая контрольная сумма |
|---|
5.4 Операция ВЫЧИСЛЕНИЕ ЦИФРОВОЙ ПОДПИСИ (COMPUTE DIGITAL SIGNATURE)
Операция COMPUTE DIGITAL SIGNATURE запускает вычисление цифровой подписи (см. таблицу 8). Алгоритм может представлять собой либо алгоритм цифровой подписи, либо комбинацию хэш-алгоритма и алгоритма цифровой подписи. В Приложении A приведены примеры операций цифровой подписи.
| Ответное поле данных | Цифровая подпись |
|---|
Примечание. Теги «AC» и «BC» не интегрированы во ввод цифровой подписи.
Для вычисления цифровой подписи данные, которые должны быть подписаны или интегрированы в процесс подписания, передаются в командное поле данных или отправляются в предыдущую команду, например PSO: HASH. В P2 цифровая подпись определяется тегами «9A», «AC» или «BC» в соответствии со структурой на входе (см. ИСО/МЭК 7816-4).
Если вспомогательные данные должны быть включены во ввод цифровой подписи, то ссылка должна быть представлена в шаблоне CRT (см. ИСО/МЭК 7816-4). Если имеется пустая ссылка на объект данных для вспомогательных данных, то тогда вспомогательные данные должны быть вставлены картой. Вспомогательные данные, которые присутствуют или к которым обращаются в поле данных, имеют приоритет над любым списком заголовка.
Значение, подлежащее возврату картой, является цифровой подписью (P1 = «9E»).
5.5 Операция ХЭШИРОВАТЬ (HASH)
Операция HASH запускает вычисление хэш-кода двумя способами (см. таблицу 9):
- полное вычисление внутри карты или
- частичное вычисление внутри карты (например, последний цикл хэширования).
Параметры и поле данных для операции HASH
| Ответное поле данных | Хэш-код или отсутствует |
|---|
Шаблон хэш-кода HT («AA», «AB») указывает ссылочный алгоритм для вычисления хэш-кода (см. ИСО/МЭК 7816-4).
Входные данные должны быть представлены карте в виде последовательных блоков (один или более одновременно). В зависимости от алгоритма хэширования последние входные данные имеют длину, равную или меньшую длины блока. Заполняющий алгоритм, если это целесообразно, является частью определения алгоритма хэширования.
Для последующей обработки вычисленного хэш-кода следует различать следующие два случая:
- вычисленный хэш-код хранится в карте и доступен для использования в более поздней команде; тогда поле L_{e} отсутствует либо
- хэш-код доставляется картой в ответе; тогда поле L_{e} должно быть установлено на соответствующую длину.
5.6 Операция ПРОВЕРИТЬ КРИПТОГРАФИЧЕСКУЮ КОНТРОЛЬНУЮ СУММУ (VERIFY CRYPTOGRAPHIC CHECKSUM)
Операция VERIFY CRYPTOGRAPHIC CHECKSUM запускает проверку криптографической контрольной суммы (см. таблицу 10).
Параметры и поле данных для операции VERIFY CRYPTOGRAPHIC CHECKSUM
| P1 | «00» |
|---|---|
| P2 | «A2» |
| Командное поле данных | Объекты данных, имеющие отношение к операции (например, «80», «8E») |
| Ответное поле данных | Отсутствует |
|---|
Примечание. Поле значений простого значения объекта данных (тег «80») содержит данные (элементы данных или объекты данных), защищенные криптографической контрольной суммой.
5.7 Операция ПРОВЕРИТЬ ЦИФРОВУЮ ПОДПИСЬ (VERIFY DIGITAL SIGNATURE)
Операция VERIFY DIGITAL SIGNATURE запускает проверку цифровой подписи, которая передается как объект данных в поле данных команды (см. таблицу 11). Другие данные, имеющие отношение к проверке, либо передаются в процессе формирования цепочки команд, либо присутствуют в карте. Алгоритм может представлять собой либо только алгоритм цифровой подписи, либо комбинацию хэш-алгоритма и алгоритма цифровой подписи. В Приложении A приведены примеры операций цифровой подписи.
| P1 | «00» |
|---|---|
| P2 | «A8» |
| Командное поле данных | Объекты данных, имеющие отношение к операции (например, либо «9A», «AC», либо «BC» и «9E») |
| Ответное поле данных | Отсутствует |
|---|
Открытый ключ, а также алгоритм могут быть:
- или неявно известны,
- или к ним обращаются в шаблоне DST («B6») команды MANAGE SECURITY ENVIRONMENT,
- или доступны как результат предшествующей операции VERIFY CERTIFICATE (ПРОВЕРИТЬ СЕРТИФИКАТ).
Если ссылочный алгоритм в карте объявляет только алгоритм подписи, то данные состоят из хэш-кода или подпись представляет собой сообщение типа восстановление (см. ИСО/МЭК 9796). В противном случае вычисление хэш-кода осуществляется в карте и ссылочный алгоритм дополнительно содержит ссылку на алгоритм хэширования.
Если поле данных команды содержит пустой объект данных, то предполагается, что карта знает его значения для использования в проверке.
5.8 Операция ПРОВЕРИТЬ СЕРТИФИКАТ (VERIFY CERTIFICATE)
Для проверки сертификата в карте (см. Приложение B) цифровая подпись сертификата, подлежащая проверке, передается как объект данных в поле данных команды. Открытый ключ органа по сертификации, который применяется при проверке, либо находится в карте, либо выбирается неявно, либо к нему можно обратиться в шаблоне DST, используя команду MANAGE SECURITY ENVIRONMENT (см. таблицу 12). Алгоритм, который должен применяться, неявно известен или к нему можно обратиться в шаблоне DST. Если есть другие объекты данных, которые должны использоваться в процессе проверки (например, хэш-код), то они должны находиться в карте или передаваться, используя процесс формирования цепочки команд.
Параметры и поле данных для операции VERIFY CERTIFICATE
| P1 | «00» |
|---|---|
| P2 | «92», «AE» или «BE» |
| Командное поле данных | Элементы данных или объекты данных, имеющих отношение к операции |
| Ответное поле данных | Отсутствует |
|---|
Примечание. Если используется схема частичного восстановления сообщения и часть информации уже записана в карте, то объект данных для вспомогательных данных должен посылаться пустым, а данные должны быть вставлены картой позднее.
Необходимо различать следующие два случая:
- если сертификат не требует дополнительного описания (P2 = «BE»), то карта извлекает открытый ключ, установленный по его тегу, в (восстановленном) содержании сертификата;
- если сертификат требует дополнительного описания (P2 = «AE»), то карта извлекает открытый ключ в сертификате неявно или явно, используя тег открытого ключа в списке заголовка, описывающего содержание сертификата.
Если открытый ключ хранится в памяти, то он будет ключом по умолчанию для последующей операции VERIFY DIGITAL SIGNATURE.
5.9 Операция ШИФРОВКА (ENCIPHER)
Операция ENCIPHER шифрует данные, переданные в поле данных команды (см. таблицу 13).
Примечание. Эта операция может использоваться для генерации различных ключей.
Параметры и поле данных для операции ENCIPHER
| P1 | «82», «84», «86» (криптограмма) |
|---|---|
| P2 | «80» (простое значение) |
| Командное поле данных | Отсутствует (данные уже в карте) или данные, подлежащие шифровке |
| Ответное поле данных | Зашифрованные данные |
|---|
5.10 Операция РАСШИФРОВКА (DECIPHER)
Операция DECIPHER расшифровывает данные, переданные в поле данных команды (см. таблицу 14).
Параметры и поле данных для операции DECIPHER
| P1 | «80» (простое значение) |
|---|---|
| P2 | «82», «84», «86» (криптограмма) |
| Командное поле данных | Данные, подлежащие расшифровке |
| Ответное поле данных | Отсутствует (расшифрованные данные остаются в карте) или зашифрованные данные |
|---|
ПРИМЕРЫ ОПЕРАЦИЙ, СВЯЗАННЫХ С ЦИФРОВОЙ ПОДПИСЬЮ
В таблице A.1 представлена последовательность команд MANAGE SECURITY ENVIRONMENT для компонентов SET DST, CCT, CT текущей среды защиты и для STORE (ХРАНЕНИЕ) с идентификатором защитной среды SEID, указанным в P2.
Установка компонентов среды защиты
Операция SET DST обращается к открытому ключу при использовании вычисления подписи и определяет интегрирование случайного числа во вход цифровой подписи. Операция SET CCT обращается к закрытому ключу и начальному значению при использовании вычисления криптографической контрольной суммы. Операция SET CT обращается к сессии закрытого ключа при использовании конфиденциальности.
A.2. Последовательность команд для вычисления цифровой подписи
В таблице A.2 показан синтаксис для создания цифровой подписи при использовании схемы подписи с приложением. Вводом является хэш-код с заполняющими байтами. Этот пример иллюстрирует вычисление цифровой подписи с объединенным алгоритмом, включая операцию хэширования. В данном случае хэш-вход поступает на карту.
| Команда | Операция | P1 — P2 | Поле данных команды | Поле данных ответа |
|---|---|---|---|---|
| MSE | RESTORE <1> | «F3» — «01» | - | - |
| PSO | COMPUTE DIGITAL SIGNATURE | «9E» — «9A» | Хэш-код с заполняющими байтами | Цифровая подпись |
Примечание. Этот пример является чисто иллюстративным, и его применение ограничено с точки зрения реализации экспортных возможностей, которые могут применяться, и по причинам общей безопасности (в некоторых обстоятельствах желательно избегать повтора подписей).
В таблице A.3 показан синтаксис для создания цифровой подписи с приложением. Ввод цифровой подписи состоит из хэш-кода без заполняющих байтов.
Второй пример схемы цифровой подписи с приложением
| Команда | Операция | P1 — P2 | Поле данных команды | Поле данных ответа |
|---|---|---|---|---|
| MSE | RESTORE | «F3» — «01» | - | - |
| PSO | COMPUTE DIGITAL SIGNATURE | «9E» — «9A» | Хэш-код без заполняющих байтов | Цифровая подпись |
Примечание 1. Для того чтобы избежать ограничений на экспорт, можно использовать объединение подписи и хэш-алгоритма.
Примечание 2. В некоторых случаях избежать повторение подписей не удается.
В таблице A.4 показана схема подписи с приложением. Ввод цифровой подписи содержит хэш-код без заполняющих байтов, который передается в карту, и карта запрашивается для того, чтобы сгенерировать случайное число, как указано в расширенном списке заголовков шаблона цифровой подписи DST в поле данных команды для команды MSE.
| Команда | Операция | P1 — P2 | Поле данных команды | Поле данных ответа |
|---|---|---|---|---|
| MSE | SET <1> | «41» — «B6» | {«4D» — L - («90» — L - «91» — L = 0)} — - {«84» — L - Ссылочный ключ} | - |
| PSO | COMPUTE DIGITAL SIGNATURE | «9E» — «BC» | {«90» — L - Хэш-код} | Цифровая подпись |
В таблице 5 показан синтаксис для цифровой подписи с ограниченным восстановлением сообщения. Данные для подписи сконфигурированы в соответствии со схемой подписи, задающей ограниченное восстановление сообщения, используя объекты данных, представленные в поле данных команды, в результате чего счетчик цифровой подписи используется как внутреннее сообщение, предоставляемое картой.
| Команда | Операция | P1 — P2 | Поле данных команды | Поле данных ответа |
|---|---|---|---|---|
| MSE | RESTORE | «F3» — «02» | - | - |
| PSO | COMPUTE DIGITAL SIGNATURE | «9E» — «AC» | {«90» — L - Хэш-код} | Цифровая подпись |
Примечание. Заполнение для вычисления хэш-кода, а также цифровой подписи осуществляется в соответствии с ИСО/МЭК 9796-2.
В таблице A.6 показано, как карта выполняет хэширование (или последний цикл вычислений с хэшированием). Ввод цифровой подписи остается пустым в операции COMPUTE DIGITAL SIGNATURE, т.к. все входные данные присутствуют в карте.
Пятый пример схемы цифровой подписи с приложением
| Команда | Операция | P1 — P2 | Поле данных команды | Поле данных ответа |
|---|---|---|---|---|
| MSE | RESTORE | «F3» — «01» | - | - |
| PSO | HASH | «90» — «80» | Данные для хэширования | - |
| PSO | COMPUTE DIGITAL SIGNATURE | «9E» — «9A» | - | Цифровая подпись |
В таблице A.7 показано, как расширенный список заголовков определяет структуру сертификата, требующего дополнительного описания (см. Приложение B): ввод цифровой подписи состоит из элементов данных. Операция VERIFY CERTIFICATE выполняется, используя цепочку команд.
Первый пример проверки цифровой подписи
На первом этапе предоставляется объект данных содержания сертификата (сцепление элементов данных: идентификационный номер эмитента (тег «42»), имя держателя карты (тег «5F20») и открытый ключ держателя карты («5F49»)). Карта выполняет хэширование, используя содержание сертификата в качестве хэшированных входных данных.
На втором этапе цифровая подпись, принадлежащая сертификату, возвращается в прежнее состояние, и результат сравнивается с хэш-кодом, вычисленным ранее. Затем выполняется операция HASH. Для проверки цифровой подписи открытый ключ должен быть уже извлечен и проверен предыдущей командой VERIFY CERTIFICATE. Ввод хэшированных данных зависит от алгоритма хэширования, либо от простого значения, возможно, представленного цепочкой команд, либо от предварительно обработанного хэш-кода, если карта выполняет только последний цикл вычислений с хэшированием.
В таблице A.8 показана проверка сертификата, не требующего дополнительного описания (см. Приложение B): ввод цифровой подписи состоит из объектов данных. Операция VERIFY CERTIFICATE использует цепочку команд. На первом этапе представляются объекты данных, интегрированные в сертификат (например, обращение к органу по сертификации, имя держателя карты и открытый ключ держателя карты). Карта использует это объединение в качестве хэшированных входных данных. Дальнейшие этапы идентичны тем, что описаны в предыдущем примере.
В таблице A.9 показано использование открытого ключа, установленного в карте.
Третий пример проверки цифровой подписи
B.1. Объекты данных для сертификатов, верифицируемых картой
В таблице B.1 показаны объекты данных, имеющих отношение к сертификатам, верифицируемым картой.
верифицируемых картой
Эмитент может определять дальнейшие объекты данных, такие как серийный номер сертификата, номер версии, дата истечения срока действия и т.д.
Следует различать две структуры сертификатов, верифицируемых картой:
- сертификат, верифицируемый картой и не требующий дополнительного описания, состоит из объединения BER-TLV объектов данных;
- сертификат, верифицируемый картой и требующий дополнительного описания, состоит из объединения элементов данных.
B.2. Сертификаты, верифицируемые картой и не требующие дополнительного описания
Для подписания сертификата может использоваться схема цифровой подписи с или без восстановления сообщения. В таблице B.2 показан пример сертификата, верифицируемого картой и не требующего дополнительного описания, со схемой цифровой подписи с восстановлением сообщения.
Сертификат держателя карты, верифицируемый картой и не требующий дополнительного описания(примеры)
Примечание 1. Идентификационные данные органа по сертификации могут ссылаться на свой открытый ключ.
Примечание 2. Идентификационные данные держателя карты могут быть использованы для управления правами доступа к данным, хранящимся в карте.
Примечание 3. Открытый ключ владельца карты может быть использован в последующей операции VERIFY DIGITAL SIGNATURE.
B.3. Сертификаты, верифицируемые картой и требующие дополнительного описания
Объект данных расширенного списка заголовков может находиться в карте для того, чтобы проверить этот тип сертификата; с другой стороны, он должен быть защищен при передаче его в карту. Объект данных расширенного списка заголовков (тег «4D», см. ИСО/МЭК 7816-4) описывает объединение элементов данных по парам тег/длина в том же порядке, что и в цифровой подписи (см. таблицу B.3).
Сертификат держателя карты, верифицируемый картой и требующий дополнительного описания (примеры)
C.1. Использование команды GET DATA (ИЗВЛЕЧЬ ДАННЫЕ) для экспорта открытого ключа
Предполагается, что объекты данных, описывающие открытый ключ (PK), находятся в карте и закодированы в форме, показанной в таблице C.1.
находящегося в карте
С помощью команды MSE выбирается открытый ключ PK, который должен быть восстановлен. Далее команда GET DATA (нечетный INS, P1 — P2 = «3FFF») используется в 3 этапа, в соответствии с которыми поля данных, показанные в таблицах C.2 - C.7, осуществляются в интерфейсе карты.
Поле данных ответа GET DATA, этап 1 из 3
| «A8» | L | |||||
| «B6» | L | DST | ||||
| «83» | L | Ссылочный ключ PK.CH.DS | ||||
| «7F49» | L | Открытый ключ | ||||
| «81» | L | Модуль | ||||
Поле данных команды GET DATA, этап 2 из 3
Поле данных ответа GET DATA, этап 2 из 3
| «A8» | L | |||||
| «7F49» | L | Открытый ключ | ||||
| «82» | L | Открытая экспонента | ||||
Поле данных команды GET DATA, этап 3 из 3
| «4D» | 04 | Расширенный список заголовков | ||||
| «A8» | 02 | Пара T — L для указания шаблона для проверки цифровой подписи | ||||
| «9E» | 00 | Пара T — L, которая указывает объект данных цифровой подписи | ||||
Поле данных ответа GET DATA, этап 3 из 3
| «A8» | L | |||
|---|---|---|---|---|
| «9E» | L | Цифровая подпись |
C.2. Использование команды PUT DATA (ПОМЕСТИТЬ ДАННЫЕ) для импорта закрытого ключа
Первоначально команда MSE должна отправить ссылку на соответствующий закрытый ключ (т.е. ссылочный ключ уже известен карте) (см. таблицу C.8). Далее используют команду PUT DATA (нечетный INS, P1 — P2 = «3FFF») с полем данных команды, как показано в таблице C.9.
Расширенный список заголовков, описывающий объект закрытого ключа
СВЕДЕНИЯ
О СООТВЕТСТВИИ ССЫЛОЧНЫХ МЕЖДУНАРОДНЫХ СТАНДАРТОВ ССЫЛОЧНЫМ
НАЦИОНАЛЬНЫМ СТАНДАРТАМ РОССИЙСКОЙ ФЕДЕРАЦИИ