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

Формат DSI в соответствии с PKCS №1 V 2.1 имеет следующую структуру:

Рисунок 29 - Пример для 2048 бит DSI в соответствии с PKCS # 1 V 2.x

[8xKey. ModulusByteLength - (Key. ModulusBitLength-1)] левые биты вывода функции MGF1 очищаются до нуля, чтобы обеспечить, чтобы вход DSI был арифметически меньше, чем модуль N. Функция MGF1 описана в [8], фактическая операция кодирования в главе 9.9.1 PKCS # 1 v2.1 [8].

Рисунок 30 - Пример для функции генерации маски MGF1

Хеширующая функция, используемая в MGF-1, такая же, как и для хеш-входных данных, как на рисунке 29. Длина соли идентична длине дайджеста H алгоритма хеширования. Длина DB вычисляется из

Length (DB) = N — H — 1 = maskLen.                                                                 (13-1)

Где N - длина байта модуля

H - длина дайджеста хэш-алгоритма.

Длина mgfseed идентична H, длина C составляет 4 байта, как указано в [8]. Начальное значение C равно нулю. Конкатенация [mgfseed || C] правые усечены по длине maskLen.

Наконец, ввод цифровой подписи.

Таблица 74 - Вход цифровой подписи (DSI) - Формат в соотв. к PKCS # 1 V 2.x

T	L	V
—	—	замаскированный DB = DB xor MGF1 (Hash (M '), teLength - H - 1) Хэш (М ') «BC» = заполнение в соответствии с ISO 9796 (вариант 1)

12.4.6 DSA с параметрами ключа DH

DSI состоит из хеш-кода, рассчитанного с использованием одного из хэш-алгоритмов, перечисленных в таблице 60.

12.4.7 Алгоритм цифровой подписи EllipticCurve - ECDSA

Для ECDSA рекомендуется использовать алгоритм, описанный в [13], глава 4.2, который соответствует [18] и [32]. Для вычисления значения хеширования следует использовать один из хэш-алгоритмов, перечисленных в EN 419212-1, таблица B.2.

В этом документе рекомендуется использовать только простые поля для ECDSA. Обратите внимание, что в [13] рассматриваются только эллиптические кривые только для простых полей.

Рекомендуется использовать параметры домена, стандартизированные в [18] или рабочей группой ECC Brainpool [21].

13 Файлов

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

Данные, необходимые для выполнения приложения ESIGN, хранятся в файлах. Фактическое местоположение этих файлов описано в соответствующих объектах данных в DF. CIA.

13.2 Структура файла

Организация файлов в ICC предназначена для совместимости с ISO / IEC 7816 4. Файловая структура ICC показана на следующем рисунке. Характеристики отдельных файлов описаны в следующих главах.

Рисунок 31 - Пример файловой структуры приложения ESIGN

ПРИМЕЧАНИЕ. На рис. 31 показан пример. В частности, расположение DF_ESIGN может отличаться от предложения на рисунке. Фактическое местоположение определяется определением в DF. CIA (ESIGN).

В примере на рисунке 31 файлы для аутентификации устройства помещаются под MF, поскольку аутентификация устройства считается механизмом, специфичным для устройства. Для карт JAVA по соображениям совместимости файлы для аутентификации устройства должны находиться в выбранном по умолчанию приложении. Любой файл, связанный с приложением подписи, помещается под DF. ESIGN.

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

13.3 Идентификаторы файлов

Идентификаторы файлов находятся на усмотрении поставщика приложений, если они не указаны в следующих главах. Идентификаторы файлов могут либо быть определены неявно (то есть приложение в IFD знает идентификатор файла априори), либо оно может быть прочитано из DF. CIA, если оно присутствует. Для получения дополнительной информации о объектах криптографических данных см. 14 «Криптографическое информационное приложение».

13.4 EF. DIR

EF. DIR указывает список приложений, поддерживаемых ICC. Он содержит набор шаблонов приложений и/или объектов данных идентификатора приложения в любом порядке. Он определяет, какие команды должны выполняться для выбора указанных приложений.

Согласно ISO/IEC 7816-4, путь «3F002F00» ссылается на EF. DIR. На уровне MF короткий идентификатор 30 EF, то есть 11110 в двоичном формате, ссылается на EF. DIR, если он присутствует.

Справка

EF. DIR описывается в ISO/IEC 7816-4, 12.2.1.

Присутствие

EF. DIR является необязательным файлом. Он может использоваться для указания наличия и имен приложений в ICC. Если нет, имена приложений (AID) должны быть известны IFD.

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

Читайте: Всегда. Если присутствует, EF. DIR должен быть доступен для чтения до успешной аутентификации устройства, так как он может содержать информацию о том, как найти DF. CIA (ESIGN).

Запись. Как правило, у эмитента карт есть доступ на запись для обновления EF. DIR. Это может варьироваться в зависимости от реальной среды приложения. Обновление EF. DIR не входит в объем этой спецификации.

13.5 EF. SN. ICC

EF. SN. ICC содержит серийный номер SN. ICC ICC. Для некоторых протоколов проверки подлинности устройства для выполнения идентификационной информации ICC требуется серийный номер SN. ICC. Поскольку некоторые ICC хранят только часть SN. ICC в своем сертификате (обычно 8 байтов), полный SN. ICC может быть получен из EF. SN. ICC. Эта информация может потребоваться фактическим приложением для уникальной идентификации МУС.

Ответ на READ BINARY APDU содержит SN. ICC как DO '5A'.

Таблица 75 - Содержание данных EF. SN. ICC

Метка	L	Значение
'5A'	'xx'	SN. ICC

ПРИМЕЧАНИЕ. Поскольку EF. SN. ICC содержит уникальный объект данных, он может быть альтернативно извлечен с использованием GET DATA.

Присутствие

Существование EF. SN. ICC является условным и зависит от реализованного протокола аутентификации устройства. «Аутентификация устройства с защитой конфиденциальности» (EN 419212-3, раздел 3.6) явно запрещает чтение EF. SN. ICC до успешной аутентификации устройства, поскольку содержимое EF. SN. ICC показывает личность (конфиденциальность) карты (держатель).

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

Чтение: зависит от типа протокола проверки подлинности устройства. Обычно EF. SN. ICC можно читать всегда. Если используется «Аутентификация устройства с защитой конфиденциальности», EF. SN. ICC не разрешается читать до тех пор, пока IFD не будет успешно аутентифицирован. Это требование безопасности, чтобы сохранить личность тайны ICC до тех пор, пока IFD не будет доверено.

Запись: Никогда. SN. ICC должен быть постоянным в течение всего жизненного цикла карты ICC

13.6 EF. DH

EF. DH содержит параметры открытого ключа для протокола обмена ключами Diffie-Hellman, если используется при аутентификации устройства. Если IFD знает эти параметры неявно, ему не нужно читать информацию из EF. DH.

Ответ на команду READ BINARY содержит объекты данных для параметров обмена ключами ICC

Таблица 76 - Содержание данных EF. DH

Метка	L	Значение
'7F49'	'xx'	DO1	DO2	...	...	DOn

Кодирование соответствующих объектов данных в части значений описано в 11.

ПРИМЕЧАНИЕ. Поскольку EF. DH содержит уникальный объект данных, он может быть альтернативно получен GET DATA.

Присутствие

EF. DH является необязательным и условным, в зависимости от типа аутентификации устройства. Это требуется только в том случае, если для аутентификации устройства реализовано ключевое соглашение Диффи-Хеллмана. Тогда это необходимо только в том случае, если публичные количества для ключевого соглашения Диффи-Хеллмана лишь частично доступны на IFD. Кодирование всех необходимых количеств в EF. DH является выбором максимальной совместимости.

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

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

Запись. Как правило, количество ключей ключа Диффи-Хеллмана не подлежит изменению и не подвергается угрозе безопасности. Если, однако, возникает необходимость изменить эти параметры (например, для миграции системы), то только для того, чтобы обновить эту информацию, должно получиться право на доступ к карте.

13.7 EF. ELC

EF. ELC содержит параметры открытого ключа для «Аутентификация устройства с защитой конфиденциальности» (EN 419212-3, раздел 3.6) и «Протокол с ограниченным доступом по модулю EAC (mEAC) с функцией не отслеживания» (EN 419212-3, раздел 3.7 ), если используется при аутентификации устройства. Если IFD знает эти параметры неявно, ему не нужно читать информацию из EF. ELC

Ответ на команду READ BINARY содержит объекты данных для параметров обмена ключами ICC.

Таблица 77 - Содержание данных EF. ELC

Значение
DO1	DO2	...	...	DOn

Кодирование соответствующих объектов данных в части значений описано в 11.8 «Общие параметры обмена ключами ELC».

Присутствие

EF. ELC является необязательным и условным, в зависимости от типа аутентификации устройства. Это требуется только в том случае, если для аутентификации устройства реализовано соглашение о ключах Диффи-Хеллмана на основе эллиптических кривых. Затем это необходимо только в том случае, если общедоступные количества для аутентификации с несслеживаемостью частично доступны только на IFD.

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

Читайте: Всегда Запись. Как правило, количество ключей ключа Диффи-Хеллмана не подлежит изменению и не подвергается угрозе безопасности. Если, однако, возникает необходимость изменить эти параметры (например, для миграции системы), то только для того, чтобы обновить эту информацию, должно получиться право на доступ к карте.