Интерфейс приложения для защищенных элементов для электронной идентификации, аутентификации и доверенные службы — часть (стр. 18 )

Таблица A.8 - Структура и содержание CCT_2

‘B4’	LB4	CRT Криптографическая контрольная сумма (CCT)
‘95’	‘01’	'20' - UQB: SM в поле данных ответа
‘83’	L83	ссылка на ключ сеанса связи K (MAC)
... другие DO, если требуется

A.2.4 CRT для цифровой подписи (DST)

UQB является необязательным, а также идентификатором алгоритма. Ключевая ссылка обязательна.

Требуется следующий шаблон DST:

- DST_1 для цифровой подписи с использованием PrK. CH. DS

- DST_2 для проверки сертификата (в контексте аутентификации устройства) с использованием корневого ключа CA PuK. RCA. AUT

- DST_3 для проверки сертификата (в контексте аутентификации устройства) с использованием открытого ключа цепочки сертификатов

Эти шаблоны кодируются следующим образом:

DST_1

Таблица A.9 - Структура и содержание DST_1

‘B6’	LB6	CRT Цифровая подпись (DST)
‘95’	‘01’	'40' = UQB: вычисление (DST)
‘84’	L84	ссылки на PrK. CH. DS
‘80’	‘01’	ссылка на алгоритм (необязательно)
... другие DO, если требуется

DST_2

Таблица A.10 - Структура и содержание DST_2

‘B6’	LB6	CRT Цифровая подпись (DST)
‘95’	‘01’	'80' = UQB: Верификация(DST)
‘83’	L83	ссылка на PuK. RCA. AUT
‘80’	‘01’	ссылка на алгоритм (необязательно)
... другие DO, если требуется

DST_3

Таблица A.11 - Структура и содержание DST_2

‘B6’	LB6	CRT Цифровая подпись (DST)
‘95’	‘01’	'80' = UQB: Верификация(DST)
‘83’	L83	Ссылка на открытый ключ в цепочке сертификатов
‘80’	‘01’	ссылка на алгоритм (необязательно)
... другие DO, если требуется

A.2.5 CRT для конфиденциальности (CT)

UQB является необязательным, а также идентификатором алгоритма. В данном примере ключевой идентификатор является обязательным.

Требуется следующий шаблон CT:

- CT_1 для безопасного обмена сообщениями в поля данных команды и CT_2 для SM в полях данных ответа (может быть объединен)

- CT_3 для дешифрования ключа

Эти шаблоны кодируются следующим образом:

CT_1

Таблица A.12 - Структура и содержание CT_1

‘B8’	LB8	CRT Конфиденциальность (CT)
‘95’	‘01’	‘10’ = UQB: SM в поле данных команд
‘83’	L83	ссылка на ключ сеанса шифрования K (ENC)
... другие DO, если требуется

CT_2

Таблица A.13 - Структура и содержание CT_2

‘B8’	LB8	CRT Конфиденциальность (CT)
‘95’	‘01’	‘20’ = UQB: SM в поле данных команд
‘83’	L83	ссылка на ключ сеанса шифрования K (ENC)
... другие DO, если требуется

ПРИМЕЧАНИЕ. CT_1 и CT_2 могут быть объединены в общий CT_12 в поле данных команды и ответных данных, которые должны быть защищены одним и тем же ключом. CT_3

Таблица A.14 - Структура и содержание CT_3

‘B8’	LB8	CRT Конфиденциальность (CT)
‘95’	‘40’	'40' = UQB: ключевые параметры для дешифрования сообщений
‘84’	L84	ссылка на дешифрование PrK. CH. KE
... другие DO, если требуется
a        Это дешифрование является дополнительным к возможному шифрованию в слое SM.

A.3 Среды безопасности (пример)

А.3.1 Общие положения

Предусмотрены следующие среды безопасности (SE # 10 относится к этой части 2, SE # 11 относится к части 1).

Таблица A.15 - Условия безопасности

SE#	Значение
SE#1	Стандартная среда безопасности
SE#10	Проверка пользователя с помощью глобальных справочных данных (PIN PIN. CH. ADMIN) и проверки подлинности клиента / сервера
SE#11	Взаимная аутентификация устройства, безопасный обмен сообщениями, проверка пользователя (PIN. CH. DS) и / или биометрия) и цифровая подпись
SE#10 и SE #11 может быть усилена до ключевой дешифровки.

A.3.2 Среда безопасности #10

Среда безопасности № 10 используется в контексте аутентификации клиентского сервера

Таблица A.16 - Среда безопасности 10

‘7B’	L7B	Безопасность окружающей среды
‘80’	‘01’	‘0A’ = SE #10
AT_1
DST_2

A.3.3 Безопасность среды #11

Среда безопасности № 11 используется в контексте генерации подписи в ненадежной среде.

Таблица A.17 - Среда безопасности #119)

‘7B’	L7B	Безопасность окружающей среды
‘80’	‘01’	‘0B’ = SE #11
AT_2:        аутентификация пользователя, знание (PIN. CH. DS)
AT_3:        внешняя аутентификация
AT_4:        внутренняя аутентификация
CT_1:        SM в поле данных команды
CT_2:        SM в поле данных команды
CCT_1:        SM в поле данных команды
CCT_2:        SM в поле данных команды
DST_1:        цифровая подпись с PrK. CH. DS

ПРИМЕЧАНИЕ. Можно использовать комбинированный подход асимметричной / симметричной аутентификации устройства, если ключи сеанса после аутентификации асимметричного устройства сохраняются постоянно. В следующих сеансах доступные (сохраненные) сеансовые ключи могут использоваться с симметричной схемой аутентификации, как описано в EN 419212-3, раздел 3.8, чтобы получить новые ключи сеанса.

Если этот подход используется, CRT SE #11 подходят для использования.

A.4 Кодирование условий доступа (пример)

А.4.1 Общие положения

В этой главе описывается кодирование условий доступа, расположенных в FCI файлов в соответствии с ISO/IEC 7816-4. Приложение ESIGN может возвращать шаблон в соответствии с этой спецификацией в ответ на команду SELECT для каждого файла.

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

- шаблон параметра управления файлами (FCP), обозначенный тегом '62'

- Файл данных управления файлами (FMD), обозначенный тегом '64'

- Файл управления информацией (FCI), обозначенный тегом '6F'

Условия доступа возвращаются как часть информации управления файлами (FCI) команды SELECT.

ПРИМЕЧАНИЕ. Приведенные ниже примеры используют расширенный формат в соответствии с ISO / IEC 7816 4, 9.3.3. Допускается использование компактного формата. Однако в компактном формате выражение команды PSO требует спецификации проприетарных битов, которые не входят в объем этой спецификации. Поэтому ниже приводится только расширенный формат.

A.4.2 Условия доступа

В следующей таблице приведен пример для AC-ов спецификации E Sign K:

Таблица A.18 - Условия доступа к EF

Имя файла	Состояние доступа
EF. DIR	Читать: всегда, обновление: никогда
EF. SN. ICCa	Читать: всегда, обновление: никогда
EF. C.ICC. AUT	Читать: всегда, обновление: никогда
EF. C.CAICC. CS-AUT	Читать: всегда, обновление: никогда
EF. C.CH. DS	Читать: всегда, обновление: никогда
EF. C.CA. DS	Читать: всегда, обновление: никогда
EF. DM (Ссылаться на 13.11 “EF. DM”)	Читайте: успешная аутентификация устройства с использованием SM Обновление: после успешной презентации PIN. CH. ADMIN или Обновление: успешная аутентификация устройства (с использованием SM) b
a Для протокола аутентификации устройства конфиденциальности этот файл не может быть прочитан до тех пор, пока ИФД не будет успешно завершена. b Если используется только с аутентификацией устройства, возможна атака отказа в обслуживании, позволяющая злоумышленнику изменять отображаемое сообщение с использованием терминала аутентификации.

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