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

13.8 EF. C.ICC. AUT

EF. C.ICC. AUT содержит сертификат (ы) для открытого ключа аутентификации ICC PuK. ICC. AUT. Для разных приложений могут существовать разные сертификаты одного и того же PuK. Это докажет приложению, что представленный открытый ключ является аутентичным и может использоваться в рамках его области. EF. C.ICC. AUT обычно находится под MF. В DF. CIA должен быть CIO, описывающий идентификатор файла (или путь) и условия доступа. Поле данных EF. C.ICC. AUT содержит один или несколько сертификатов для одного и того же открытого ключа ICC.

Таблица 78 - Содержание данных EF. C.ICC. AUT

Метка	L	Значение
'7F21'	'xx'	инкапсулирует сертификат 1 поверх PuK. ICC. AUT (выдается CA 1)
'7F21'	'yy'	инкапсулирует сертификат 2 поверх PuK. ICC. AUT (выдается CA 2)
'7F 21'	'zz'	...
...	...	...

Кодирование сертификата описано в «C. ICC. AUT» (EN 419212-3, п. 5.15).

13.9 EF. C.CAICC. CS-AUT

EF. C.CAICC. CS-AUT содержит сертификат CA (ов), который сгенерировал сертификат для открытого ключа ICC. Если для сертификации открытого ключа используются разные ЦС, соответствующие сертификаты ЦС хранятся вместе в этом файле.

Поле данных EF. C.CAICC. CS-AUT содержит один или несколько сертификатов.

Присутствие

Наличие EF. C.CAICC. CS-AUT условно. Если ICC используется в системе, в которой уже имеется PuK. CAICC. CS-AUT или где этот открытый ключ может быть получен через другие каналы (например, подключение к Интернету), EF. C.CAICC. CS-AUT не требуется существовать. Однако во многих приложениях это может быть не так. Затем должен присутствовать EF. C.CAICC. CS-AUT, чтобы позволить IFD проверить сертификат аутентификации ICC.

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

Читайте: Всегда

Обновление: как правило, содержание сертификатов не подлежит изменению. В качестве исключения запись в этот файл может быть разрешена для целей администрирования для обновления сертификата. Обновление сертификатов считается зависимым от приложения и не описано в этой спецификации.

13.10 EF. C_X509.CH. DS

EF. C_X509.CA. DS содержит DS-сертификат (ы) владельца карты. Этот сертификат содержит открытый ключ для ключа подписи владельца карты [20].

Присутствие

Наличие этого файла является необязательным. Если для приложения требуется формат, отличный от X.509 [20], то содержимое этого файла может быть заменено соответствующим сертификатом.

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

Чтение: зависит от типа протокола проверки подлинности устройства. Обычно EF. C_X509.CA. DS можно читать всегда.

Если используется «Аутентификация устройства с защитой конфиденциальности» (EN 419212-3, раздел 3.6), EF. C_X509.CA. DS не разрешается читать до тех пор, пока ИФД не будет успешно аутентифицирована. Это требование безопасности, чтобы сохранить личность тайны ICC до тех пор, пока IFD не будет доверено.

Обновление: как правило, содержание сертификатов не подлежит изменению. В качестве исключения запись в этот файл может быть разрешена для целей администрирования для обновления сертификата. Обновление сертификатов считается зависимым от приложения и не описано в этой спецификации.

13.11 EF. C_X509.CA. CS (DF. ESIGN)

EF. C_X509.CA. CS содержит сертификат X.509 ЦС [20], который выдал сертификаты держателя карты для службы цифровой подписи. Формат этого сертификата описан в других стандартах и ​​выходит за рамки настоящего стандарта.

Присутствие

Наличие EF. C_X509.CA. CS-DS условно. Если ICC используется в системе, в которой уже имеется PuK. CAICC. CS-DS или где этот открытый ключ может быть получен через другие каналы (например, подключение к Интернету), EF. C_X509.CA. CS-DS не требуется существовать. Однако во многих приложениях это может быть не так. Затем должен присутствовать EF. C_X509.CA. CS-DS, чтобы позволить ИФД проверять сертификат подписи держателя карты.

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

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

13.12 EF. DM

EF. DM содержит отображаемое сообщение для использования во время аутентификации устройства, как описано в «Чтение отображаемого сообщения» (EN 419212-3, раздел 3.14).

Присутствие

обязательное

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

Чтение: только зашифровано под защищенным сообщением. Тот факт, что EF. DM считывается, используется в качестве доказательства доказательств для активного сеанса безопасных сообщений.

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

Обновление: обновление разрешено только после представления соответствующего пароля. Ссылка на соответствующий пароль указывается в соответствующем CIO в DF. CIA.

Эта функция описана в разделе «Обновление отображаемого сообщения» (EN 419212-3, п. 3.15).

ПРИМЕЧАНИЕ. Если DM находится под MF, как в примере Error! Исходный источник не найден. Можно использовать только глобальный пароль. Если предполагается использовать местный пароль («ПИН-код подписи»), тогда необходимо соблюдать общие национальные правила.

14 Применение криптографической информации

14.1 Общие положения

В этой главе описывается приложение криптографической информации.

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

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

Минимальная файловая система для приложения ESIGN в соответствии с ISO / IEC 7816 15 имеет следующую структуру:

Рисунок 32 - Связывание файлов в DF. CIA

Mandatory обязательный

Certicate сертификат

Password  пароль

Private - частный

DF. CIA - это структура каталогов с файлами описательной информации. Ни один из этих файлов не требуется для работы ICC, однако информация, хранящаяся в этих файлах, помогает IFD узнать, где и под каким именем могут быть адресованы ресурсы (например, файлы) в ICC.

DF. CIA кодируется в ASN.1 и только интерпретируется IFD. ICC не затрагивает и не использует информацию, хранящуюся в DF. CIA.

На рисунке 33 показан пример расположения файла дескриптора DF. CIA

signature services - услуги подписки

klient server auth - сервер klient

confidentliality services – служба конфиденциальности

serteficate information – справочнаяинформация

Рисунок 33 - Структура файла CIA (пример)

Обязательно, чтобы каждый DF. CIA содержал один EF. OD и один EF. CIAInfo6.

14.2 Пример компоновки криптографической информации ESIGN

14.2.1 Общие положения

В следующих главах приведен пример кодирования ASN.1 приложения криптографической информации, которое принадлежит к приложению ESIGN. В этом примере приложение ESIGN использует следующие службы:

- Служба проверки подлинности устройства (транспортный протокол ключа, см. «Транспортный протокол ключа на основе RSA»

- EN 419212-3, п. 3.9)

- Служба цифровой подписи

- Служба проверки пользователя (глобальный пароль и пароль подписи) Приложение использует две среды безопасности:

_________________________

6 EF. PuKD является необязательным, например. если доступны другие сертификаты, такие как X.509.

- Среда безопасности SE#1 используется в надежной среде. В SE#1 всегда может применяться служба проверки пользователя для пароля подписи, и услуга цифровой подписи может быть применена после успешной проверки пароля подписи.

- Среда безопасности SE#2 используется в ненадежной среде. В SE#2 сначала доверенный канал должен быть установлен с помощью службы аутентификации устройства. Во-вторых, служба проверки пользователя для пароля подписи и службы цифровой подписи применяется с защищенным сообщением. Опять же, перед использованием ключа частной подписи требуется успешная проверка пароля подписи.

14.2.2 EF. CIAInfo

Файл EF. CIAInfo предоставляет список поддерживаемых криптографических алгоритмов. Атрибут ссылки используется для связывания ключей, описанных в EF. PrKD, с этими алгоритмами. С помощью соответствующего ObjId IFD может идентифицировать алгоритм и использовать значение AlgRef в соответствующей команде MSE: SET для выбора этого алгоритма.

- EF. CIAInfo

en14890-1-EFCIAInfo CIAInfo :: =

{

       версия v2,

serialNumber '159752222515401240'H,

ярлык «Квалифицированная подписная заявка»,

cardflags {authRequired, prnGeneration},

seInfo

{

{

se 1,

помощь "A000000167455349474E'H

},  - AID приложения EN 14890-1

{

se 2,

помощь "A000000167455349474E'H

}

}, - AID приложения EN 14890-1

supportedAlgorithms

{

- Хэш-алгоритм

- AlgID: 0x40, SHA-256

{

ссылка 1, - уникальная ссылка а

Алгоритм 592, - тип механизма PKCS#11 CKM_SHA256 = 0x250

параметры NULL: NULL, - тип параметров - NULL, а значение - NULL

supportedOperations {hash},

objId {2 16 840 1 101 3 4 2 1},

AlgRef 64 - эквивалентно 0x40, см. EN 419212-1, таблица A.1.

- Алгоритм подписи

- RSA с DSI в соответствии с PKCS # 1 и SHA-256

{

ссылка 2, - уникальная ссылка, перекрестная ссылка от EF. PrKD

алгоритм 64, - тип механизма PKCS # 11 CKM_SHA256_RSA_PKCS = 0x40

параметры NULL: NULL, - тип параметров - NULL, а значение - NULL

supportedOperations {compute-signature},

objId {1 2 840 113549 1 1 11},

AlgRef 66 - эквивалентно 0x42, см. EN 419212-1, таблица A.1

},

- Алгоритм аутентификации устройства