Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

2004 г.

4.6.4. Смарт-карты EMV

Семёнов Ю.А. (ГНЦ ИТЭФ), book.itep.ru

В основу данной спецификации легли разработки компаний Europay, MasterCard и Visa (EMV) в марте, 1998 года. Следует принимать во внимание, что данная технология будет использоваться не только для финансовых операций. Планируется ее применения для проездных билетов и контроля доступа к ЭВМ. В перспективе можно предположить, что эта техника будет использоваться для идентификации личности, например, вместо паспорта.
IEC 512-2:1979Спецификации для электромеханических компонентов оборудования - Часть 2: Тесты сопротивления контактов, тесты проверки изоляции и перегрузок
FIPS Pub 180-1:1995Стандарт на безопасные хэши. Спецификация терминала платежных систем для карт с интегральными схемами
ISO 639:1988Коды названий языков
ISO 3166:1997Коды названий стран
ISO 4217:1995Коды валют и фондов
ISO/IEC 7811-1:1995

Идентификационные карты - Метод записи - Часть 1: Тиснение

ISO/IEC 7811-3:1995

Идентификационные карты - Метод записи - Часть 3: Положение вытисненных символов на картах ID-1

ISO/IEC 7813:1995 Идентификационные карты - Карты для финансовых операций
ISO/IEC DIS 7816-1:1998Идентификационные карты - Карты с интегральными схемами, имеющими внешние контакты.
Часть 1:Физические характеристики ISO/IEC DIS 7816-2:1998
Часть 2:Размеры и положение контактов
ISO/IEC 7816-3:1989Часть 3:Электрические сигналы и протоколы передачи
ISO/IEC 7816-3:1992Часть 3:Протокол типа T=1, асинхронный полудуплексный протокол блочной передачи
ISO/IEC 7816-3:1994Часть 3:Выбор типа протокола
ISO/IEC 7816-4:1995Часть 4:Команды обмена
ISO/IEC 7816-5:1994Часть 5:Процедура для выработки прикладных идентификаторов
ISO/IEC 7816-6:1996Часть 6:Информационные элементы
ISO 8731-1:1987Часть 1:Алгоритмы аутентификации сообщений (DEA)
ISO 8372:1987Обработка информации. Режимы работы для 64-битовых блочных алгоритмов шифрования/дешифрования
ISO/IEC 8825:1990

Информационная технология. Соединение открытых систем. Спецификация базовых правил кодирования для синтаксической нотации ASN.1

ISO 8583:1987Сообщения банковских карт - Спецификации сообщений - Содержимое финансовых транзакций
ISO 8583:1993Сообщения транзакций банковских карт - Спецификации сообщений
ISO 8859:1987Обработка сообщений - 8-битовые графические символьные наборы
ISO/IEC 9796-2: 1997Информационная технология - Методы безопасности - Схема восстановления сообщений с цифровой подписью. Часть 2: Механизм использования хэш-функций
ISO/IEC 9797:1994Информационная технология - Методы безопасности - Механизм информационной целостности, использующий функцию криптографической проверки на базе алгоритма блочного шифра
ISO/IEC 10116: 1997Информационная технология - режимы работы алгоритмов n-битовых блочных шифров
ISO/IEC 10118-3: 1998Информационная технология - Методы безопасности - хэш-функции

Рис. 4.6.4.1. Расположение контактов на лицевой стороне карты

Рис. 4.6.4.2. Положение контактов (все контакты имеют размер 1,7х2,0 мм)

Всего на карте 8 контактов. На рис. 4.6.4.1 обязательные контакты представлены закрашенными прямоугольниками. Контакты C4 и С8 не используются и могут отсутствовать, контакт же С6 используется для программирования на фазе изготовления. Сопротивление для этого контакта по отношению к любым другим контактом должно превышать 10 Мом при напряжении 5 В.

Таблица 4.6.4.1.

КонтактНазначениеКонтактНазначение
С1VCC - напряжение питанияС5GND - земля
С2RST - сбросС6Не используется
С3CLK - тактовые импульсыС7Вход/Выход (I/O)

VCC - напряжение питания 5 ± 0,5В при токе 50 мА при любых частотах работы микросхемы.

В таблице 4.6.4.2 представлены параметры входных информационных сигналов

VIH- Высокий уровень входного сигнала
VIL- Низкий уровень входного сигнала
VOH- Высокий уровень выходного сигнала
VOL- Низкий уровень выходного сигнала
tR- Время нарастания сигнала
tF- Время спада сигнала

Таблица 4.6.4.2

 МинимумМаксимум
VIH0,7xVccVcc
VIL00,8 В
tR и tF-1,0 мксек

Если передача не осуществляется, состояние драйвера ICC должно соответствовать режиму приема. В таблице 4.6.4.3 представлены параметры выходных информационных сигналов

Таблица 4.6.4.3

 УсловияМинимумМаксимум
VOH-20мкА<IOH<0, Vcc= min0,7xVccVcc
VOL0< IOL < 1мА, Vcc = min00,4 В
tR и tFC IN(терминала) =30пФ макс-1,0 мксек

В таблице 4.6.4.4 перечислены требования на параметры тактовых импульсов. ICC может работать корректно при скважности тактовых импульсов в диапазоне (44-56)% и значении тактовой частоты от 1 до 5 МГц.

Таблица 4.6.4.4

 МинимумМаксимум
VIHVcc-0,7ВVcc
VIL00,5 В
tR и tF-9% тактового периода

В таблице 5 представлены характеристики сигнала сброса (RST).

Таблица 4.6.4.5

 МинимумМаксимум
VIHVcc-0,7ВVcc
VIL00,6 В
tR и tF-1,0 мксек

ICC выдерживает уровни сигнала на шине RST от -0,3В до Vcc+0,3В. ICC откликается на сигнал сброса асинхронно. Микросхема может также противостоять импульсам тока через цепь питания до 100 мА длительностью 400 нсек и с интегральным зарядом 40 нАсек.

Любая транзакция для карты начинается с ее вставления в интерфейсное устройство IFD (Interface Device) и активации контактов карты. Далее следует сброс микросхемы ICC в исходное состояние и установление связи между ICC и IFD. Только после этого начинает реализовываться конкретная транзакция. Любая транзакция завершается дезактивацией контактов и удалением ICC из интерфейсного устройства.

После вставления карты в IFD терминал проверяет, что все сигнальные контакты находятся в состоянии L (низкий логический уровень - VOL). IFD контролирует корректность положения ICC с точностью ±0,5мм. Если карта позиционирована правильно, производится активация контактов в соответствии с порядком, представленном на рис. 4.6.4.3.

Рис. 4.6.4.3. Последовательность активации контактов ICC

Через некоторое время после подачи на ICC напряжения питания Vcc начинают поступать тактовые импульсы. В исходный момент времени (сразу после вставления карты уровень сигналов на шине I/O является низким (L). Далее уровень этой шины может быть неопределенным (обозначено на рисунке серым прямоугольником), но после прихода 200 тактов этот уровень становится высоким (H). При этом уровень на шине RST остается низким (L). Терминал IFD устанавливает свой драйвер I/O в режим приема не позднее поступления 200-го такта. После этого выполняется процедура сброса (Reset). ICC откликается на команду RESET асинхронно. Время, когда на ICC начинают поступать тактовые импульсы, называется T0. Терминал поддерживает в это время уровень шины RST в низком состоянии.

Рис. 4.6.4.4. Диаграмма реализации "холодного" сброса

После прихода 40000-45000 тактов после Т0 шина RST переходит в состояние H. Этот момент времени называется T1. Начало отклика на Reset со стороны ICC наступает спустя 400-40000 тактов после T1 (время t1). Если за это время отклик со стороны ICC не поступает, терминал в пределах 50 мсек деактивирует контакты микросхемы на карте. Диаграмма холодного сброса ICC показана на рис. 4.6.4.4.

Команда сброса может поступать и в процессе обычной работы - так называемый "теплый" сброс. Временная диаграмма такого сброса показана на рис. 4.6.4.5.

Рис. 4.6.4.5. Временная диаграмма "теплого" сброса

Следует учитывать, что при теплом сбросе напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. После перехода шины RST в состояние L (момент времени T0') на шине I/O не позднее чем через 200 тактов должен установиться уровень H. В момент Т1' шина RST переходит в состояние H, после чего завершается процедура сброса аналогично "холодному" варианту.

Процедура деактивации контактов ICC показана на рис. 4.6.4.6. В момент начала этой процедуры напряжение питание Vcc имеет рабочий уровень, шина RST имеет уровень H, состояние шины I/O может быть любым. Сигналом к началу процесса является переход шины RST в низкое состояние. Через некоторое время состояние шины I/O должно стать низким, прекращается подача тактовых импульсов, после чего с небольшой задержкой напряжение питания Vcc становится равным нулю и процедура в пределах 100 мсек завершается. При гальваническом отключении контактов Vcc должно быть не более 0,4 В. По завершении процедуры карта может быть извлечена из интерфейсного устройства.

Рис. 4.6.4.6. Временная диаграмма дезактивации контактов ICC

Исходная длительность такта на шине I/O определяется как:

t = 372/f секунд,

где f частота в Гц. В общем случае t определяется как:

t = F/(Df),

где f частота в Гц, F и D параметры, которые могут варьироваться, но обычно F=372, а D=1. f лежит в пределах (1-5) МГц.

Рис. 4.6.4.7. Диаграмма передачи символов по шине I/O

Перед началом передачи символа шина I/O должна находиться в состоянии H. Для передачи любого символа требуется 10 бит (смотри рисунок 4.6.4.7). Стартовый бит должен иметь уровень L и номер 1. Последний бит представляет собой бит четности (нечет). Стартовый бит детектируется путем стробирования шины I/O. Время стробирования составляет 0,2 t. Время между началами передачи последовательных символов составляет t(10±0,2) плюс время выдержки. Во время выдержки ICC и терминал должны находиться в режиме приема. (H).

Определены два протокола: символьный (Т=0) и блочный (Т=1). ICC поддерживает один из этих протоколов, терминалы поддерживают оба. Тип протокола определяется значением символа TD1. При отсутствии в ATR TD1 рабочим считается протокол Т=0. Физический уровень обмена должен согласовываться с обоими протоколами. Минимальный интервал между лидирующими битами двух последовательных символов, посылаемых ICC, равно 12t. Максимальный интервал между стартовыми битами двух последовательных символов (Work Waiting Time) не должно превышать (960хDxWI) t (параметры D и WI пересылаются с помощью символов TA1 и TC2, соответственно). Если это время будет превышено, терминал не позднее, чем спустя 960t должен начать процесс дезактивации.

В режиме T=0, если ICC или терминал детектировали при передаче/приеме символа ошибку четности, шина I/O переводится в состояние L, чтобы передающая сторона узнала об ошибке.

На транспортном уровне терминала TTL (Terminal Transport Layer) данные всегда передаются через шину I/O так, что старший байт следует первым. Будет ли первым старший бит, определяется символом TS, возвращаемым в ответ на команду сброс ATR. Такой отклик может содержать строку символов.

При отклике на сброс минимальное время между стартовыми битами последовательных символов составляет 9600t. ICC передает все символы отклика в пределах 19200 t. Это время измеряется между стартовым битом первого символа TS и после 12 t от начала последнего символа. Число символов в отклике зависит от транспортного протокола и поддерживаемых управляющих параметров.

ICC может опционно поддерживать более одного транспортного протокола, но одним из таких протоколов должен быть Т=0 или Т1. Символы, присылаемые в рамках ATR, представлены в таблице 4.6.4.6.

Таблица 4.6.4.6. Базовый ATR для T=0

СимволЗначениеПримечания
TS3B или 3FУказывает на прямую или инверсную схему передачи бит
T06xПрисутствуют TB1 и TC1; х обозначает число исторических байтов
TB100VPP не требуется
TC100 - FFУказывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.

Если поддерживается только протокол типа T=1 (блочный асинхронный транспортный протокол), то используемые символы отклика ATR содержатся в таблице 4.6.4.7. Следует иметь в виду, что ICC может поддерживать более одного транспортного протокола.

Таблица 4.6.4.7. Базовый ATR для T=1

СимволЗначениеПримечания
TS3B или 3FУказывает на прямую или инверсную схему
T0ExПрисутствуют TB1 - TD1; х обозначает число исторических байтов
TB100VPP не требуется
TC100 - FFУказывает на необходимость дополнительного времени выдержки. FF имеет специальное назначение.
TD181TA2 - TC2 отсутствуют; TD2 присутствует; должен работать протокол T=1
TD231

TA3 и TB2 присутствуют; TC3 и TD3 отсутствуют; должен работать протокол T=1

TA310 - FEВозвращает IFSI, что указывает на начальное значение размера информационного поля для ICC и IFSC равное 16-254 байтам
TB3

Старший полубайт =0-4
Младший полубайт =0-5

BWI = 0-4
CWI = 0-5

TCK Контрольный символ

Интерфейсы могут поддерживать отклики, не описанные в данной спецификации. Максимальное число символов в отклике, включая TS, не должно превышать 32.

TS служит для синхронизации терминала и для определения логической схемы интерпретации последующих символов. Инверсная логическая схема предполагает, что логической единице на шине I/O соответствует уровень L, а старший бит данных передается первым. Прямая схема предполагает, что логической единице на шине I/O соответствует уровень H, а первым передается младший бит. Первые четыре бита LHHL используются для синхронизации.

ICC может прислать ATR, содержащий TS, который имеет одно из следующих значений:
(H)LHHLLLLLLH - инверсная схема, значение 3F.
(H)LHHLHHHLLH - прямая схема, значение 3B
Последний бит этих кодов Н является битом четности (смотри рис. 4.6.4.7).

T0 - символ формата. Старший полубайт (b5-b8) используется для определения того, присутствуют ли последующие символы TA1-TD1. Если биты b5-b8 установлены в состояние логической единицы, TA1-TD1 присутствуют. Младший полубайт (b1-b4) содержит число опционных исторических байтов (0-15). Смотри таблицу 4.6.4.8.

Таблица 4.6.4.8

 b8b7b6b5b4b3b2b1
Только Т=00110XXXX
Только Т=11110XXXX

Символы интерфейса TA1-TC3 передают информацию, которая используется при обмене между терминалом и ICC. Они определяют значения параметров F, D, I, P и N, а также IFSC, BWI (Block Waiting time Integer) и CWI (Character Waiting time Integer). Информация, содержащаяся в TA1, TB1, TC1, TA2 и TB2 будут применяться для всех последующих обменов вне зависимости от используемого протокола.

TA1 служит для передачи значений FI и DI, где FI используется для задания значения F (параметр, определяющий тактовую частоту). DI служит для задания значения D, используемого для настройки частоты следования бит. По умолчанию FI=1 и DI=1, что означает F=372, а D=1.

Если ТА1 присутствует в ATR (b5 в T0 равен 1) и TA2 прислан с b5=0, то терминал воспринимает ATR, если TA1=11, и немедленно реализует указанные F и D.

ТВ1 несет в себе значения PI1 и II, где PI1 специфицировано в битах b1-b5 и используется для программирования значения напряжения P, необходимого ICC. PI0=0 означает, что VPP не подключено к ICC. II специфицируется в битах b6 и b7 и служит для определения максимального тока, потребляемого ICC. Этот параметр не используется, если PI1 = 0.

TC1 несет в себе величину N, которая используется для задания дополнительной выдержки (guardtime) между символами. Это время будет добавлено к минимальной выдержке. N может принимать значения 0-255 t.

TD1 указывает, должны ли быть переданы еще интерфейсные байты, и содержит информацию о типе протокола. Старший полубайт используется для индикации наличия символов TA2 - TD2. Биты b5-b8 принимают значение логической единицы, если указанные выше символы присутствуют. Младший полубайт указывает протокол, который будет использован для последующих обменов.

ATR не содержит TD1, если используется только Т=0. Для T=1 TD1=81 указывает на наличие TD2.

Наличие или отсутствие TA2 говорит о работе ICC в специфическом или согласованном режиме, соответственно. Базовый отклик ATR не содержит ТА2.

ТВ2 передает PI2, который используется для определения величины программируемого напряжения Р, необходимого ICC. Если этот символ присутствует, значение, указанное в PI1 (ТВ1), заменяется на новое. По умолчанию ТВ2 отсутствует.

ТС2 специфичен для протокола типа Т=0 и несет в себе значение WI (Waiting time Integer), которое используется для определения максимального интервала между началом передачи любого символа, посланного ICC, и началом предыдущего символа, поступившего от ICC или терминала. Время выдержки вычисляется по формуле 960xDxWI. По умолчанию ТС2 отсутствует, а WI=10. Терминал воспринимает ATR, содержащий ТС2=0А. Он отвергает ATR, несущий в себе ТС2=00 или ТС2>0А.

TD2 указывает, будут ли еще переданы какие-либо интерфейсные байты, а также определяет тип протокола, используемого далее. Старший полубайт используется для указания наличия символов ТА3 - TD3. Биты b5-b8 устанавливаются в единичное состояние при наличии ТА3 - TD3. Младший полубайт указывает тип протокола, применяемый в последующих обменах. При Т=1 он равняется 1. По умолчанию при Т=0 ATR не содержит TD2, в противном случае ATR содержит TD2=31 (T=1).

ТА3 несет в себе информацию о размере поля данных для ICC (IFSI) и специфицирует длину информационного поля INF блоков, которые могут быть получены картой. Этот символ характеризует длину IFSC в байтах и может содержать коды в интервале 0х01-0хFE. Значения 0х00 и 0хFF зарезервированы на будущее. По умолчанию ATR содержит ТА3 со значение в диапазоне 0х10-0хFE, если Т=1, IFSC лежит в интервале 16-254 байта. Если ТА3 содержит недопустимый код, ATR терминалом отвергается.

ТВ3 характеризует значения CWI и BWI, используемые для вычисления CWT и BWT, соответственно. ТВ3 имеет две части. Младший полубайт (b1-b4) используется для определения значения CWI, а старший полубайт (b5-b8) - BWI. По умолчанию ATR несет в себе ТВ3, при этом младший полубайт содержит код 0-5, а старший - 0-4, если Т=1, указывая, что CWI=0-5, а BWI=0-4. Формат ТВ3 показан в таблице 4.6.4.9.

Таблица 4.6.4.9

 b8b7b6b5b4b3b2b1
Только Т=10XXX0YYY

XXX лежит в интервале 000-100, а YYY - 000-101

Терминал отвергает ATR, не содержащий ТВ3 или указывающий на значения BWI больше 4 и/или CWI больше 5, или 2CWI<(N+1).

TC3 индицирует тип блока кода детектирования ошибки. Тип кода определяется битом b1 (b2-b8 - не используются). По умолчанию ATR не содержит ТС3. Терминал воспринимает ATR с ТС3=00, и отбрасывает любые-другие ATR, содержащие другие значения ТС3.

ТСК (контрольный символ) имеет значение, которое позволяет проверить целостность данных, пересылаемых в ATR. Значение TCK таково, что исключающее ИЛИ всех байтов от Т0 до ТСК включительно должно давать код 0. По умолчанию ATR не содержит ТСК, если используется только Т=0, во всех других случаях ТСК должен присутствовать. Терминал воспринимает ATR ICC без TCK, если только Т=0. Во всех остальных случаях терминал отвергнет ATR без, или с некорректным ТСК. Если ТСК некорректно, терминал инициирует последовательность дезактивации не позднее 480 t после начала ТСК.

Если терминал отверг холодный АТR, он не отвергает карту немедленно, а инициирует "теплый" сброс в пределах 4800t. Если терминал отверг теплый ATR, он в пределах 4800 t запускает процедуру дезактивации.

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

Если отклик на холодный или теплый сброс не завершился в пределах 19200t, терминал спустя 24000t (от начала TS) запускает процедуру дезактивации карты.

Если терминал обнаруживает ошибку по четности при передаче символа ATR, он прерывает сессию карты и спустя 4800t инициирует процедуру дезактивации.

4.6.4.1. Команды

Команды всегда инициируются прикладным уровнем терминала TAL (Terminal Application Layer), который посылает инструкции ICC через транспортный уровень TTL (Terminal Transport Layer). Команда содержит последовательность из 5 байт: CLA, INS, P1, P2 и P3.

Имя байтаНазначение
CLAКласс команды (1 байт).
INSКод инструкции (1 байт).
P1 и P2Cодержат дополнительные специфические параметры (по 1 байту).
Р3

Указывает либо длину посылаемых в команде данных, либо максимальную длину данных, которые должны быть присланы в отклике от ICC (зависит от кода INS).

Эти 5 байт вместе с байтами данных образуют командный блок протокольной информации C-TPDU для Т=0.

Получив команду, ICC откликается отправкой процедурного или статусных байтов. Процедурный байт указывает TTL, какая операция является следующей. Отклик терминала на процедурный байт представлен в таблице 4.6.4.10.

Таблица 4.6.4.10. Отклик терминала на процедурный байт

Значение процедурного байтаДействие терминала
Байт равен INSВсе остальные байты данных будут переданы TTL, или TTL будет готов принять все остальные байты от ICC
Байт равен дополнению INSСледующий байт данных будет передан TTL или TTL будет готов принять следующий байт от ICC
60TTL введет дополнительное время выдержки (Work Waiting Time)
61TTL будет ждать следующий процедурный байт, затем пошлет ICC команду GET RESPONSE с максимальной длиной "xx", где хх равно значению второго процедурного байта
6CTTL будет ждать следующий процедурный байт, после чего немедленно повторно пошлет ICC предыдущий командный заголовок, используя длину "xx", где хх равно значению второго процедурного байта

Во всех случаях после реализации операции TTL ждет прихода процедурного байта или статусного сообщения.

Командное сообщение, посылаемое от прикладного уровня, и сообщение-отклик ICC называются APDU (Application Protocol Data Unit). Формат APDU показан на рисунке 4.6.4.8.

Рис. 4.6.4.8. Структура командного APDU.

Все поля заголовка имеют по одному байту. Поле данных содержит Lc байт.
LcЧисло байт в поле данные (0 или 1 байт)
LeМаксимальное число байт в поле данных отклика (0 или 1 байт)

Если параметры Р1 и Р2 не используются, коды полей должны равняться 00.

Формат отклика APDU аналогичен показанному на 4.6.4.8.

Поле данных имеет переменную длину и, вообще говоря, может отсутствовать. Однобайтовые поля SW1 и SW2 должны присутствовать обязательно. SW1 характеризует состояние обработки команды, а SW2 - является квалификатором обработки команды.

Кодировка команд для полей CLA и INS представлена в таблице 4.6.4.11.

Таблица 4.6.4.11. Кодирование командного байта

CLAINSНазначение
APPLICATION BLOCK (Заблокировать приложение)
18APPLICATION UNBLOCK (Разблокировать приложение)
16CARD BLOCK (Заблокировать карту)
82EXTERNAL AUTHENTICATE (Внешняя аутентификация)
АЕ

GENERATE APPLICATION CRYPTOGRAM (Сформировать прикладную криптограмму)

84GET CHALLENGE (Получить вызов)
САGET DATA (Получить данные)
А8GET PROCESSING OPTIONS (Получить опции обработки)
88INTERNAL AUTHENTICATE (Внутренняя аутентификация)
24PERSONAL IDENTIFICATION NUMBER (PIN) CHANGE/UNBLOCK - изменение/разблокировка персонального идентификатора
В2READ RECORD (Прочесть запись)
А4SELECT (Выбор)
20VERIFY (Проверка)
DxRFU для платежных систем
ExRFU для платежных систем
XxRFU производителя для кодирования INS собственника
ЕхxxRFU эмитента для кодирования INS собственника

Статусные байты SW1 и SW2 указывают TTL, что обработка команды завершена. Значения этих байт интерпретируются в зависимости от обрабатываемой команды. Коды и значения полей SW1 и SW2 представлены в таблице 4.6.4.12.

Таблица 4.6.4.12. Кодирование статусных байтов SW1, SW2

SW1SW2Значение

90

00

Нормальная обработка
Процесс завершился успешно


62
63
63


83 00 Сх

Обработка с предупреждением
Состояние постоянной памяти не изменилось; выбранный файл некорректен
Состояние постоянной памяти изменилось; аутентификация не прошла
Состояние постоянной памяти изменилось; счетчик задан "x" (0-15)


69
69
69



83
84
85
81
82
83

Контроль ошибок
Команда не разрешена; метод аутентификации блокирован
Команда не разрешена; запрошенные данные некорректны
Команда не разрешена; условия использования не выполнены
Неверные параметры Р1 Р2; функция не поддерживается
Неверные параметры Р1 Р2; файл не найден
Неверные параметры Р1 Р2; запись не найдена

Таблица 4.6.4.12А. Сводные данные по командам/откликам

КомандаCLAINSP1P2LcДанныеLe
APPLICATION BLOCK8C/841E0000Число байт данныхКод аутенти-фикации сообщения (MAC)-
APPLICATION UNBLOCK8C/84180000Число байт данныхКомпонент MAC-
CARD BLOCK8C/84160000Число байт данныхКомпонент MAC-
EXTERNAL AUTHENTICATE008200008-16Issue Authentication Data-
GENERATE APPLICATION CRYPTOGRAM80AE

Парам.
ссылки

00Перемен.Данные транзакции00
GET DATA80CA

9F36

9F13

9F17

9F36

9F13

9F17

--00
GET PROCESSING OPTIONS80A80000Перемен.Processing Option Data Object List (PDOL)00
INTERNAL AUTHENTICATE00880000Длина аутент. данныхАутентиф. данные00
PIN CHANGE/UNBLOCK8C/84240000, 01 или 02Число байт данныхPIN данные-
READ RECORD00B2Номер записи

Парам.

ссылки

-

-

00

SELECT00A4

Парам.
ссылки

Опции выбора05-10Имя файла00
VERIFY002000Квали-фикаторПеременPIN данные транзакции-
GET CHALLENGE00840000--00

Блочный протокол Т=1 предполагает передачу блоков данных между TAL (Terminal Application Layer) и ICC. Эти блоки несут в себе команды, R-APDU (Response Application Protocol Data Unit) и управляющую информацию. Структура блока показана на рисунке 4.6.4.10. Поля заголовка и эпилога (хвостовика) являются обязательными. Биты b1-b3 NAD указывают на адрес отправителя (SAD), а b5-b7 - адрес получателя (DAD). В настоящее время адресация узлов не поддерживается и по этой причине в поле NAD следует записывать код 00. Биты b4 и b8 равны нулю. Код PCB определяет тип блока. Существует три типа блоков: информационные (I-блок), готовности приема (R-блок, подтверждение) и управляющие (S-блок).

Заголовок (Prologue)ДанныеЭпилог
Адрес узла (NAD)Управляющий протокольный байт (PCB)

Длина
(LEN)
 

APDU или управляющая информация (INF)

EDC
(код детектирования ошибки)

1 байт1 байт1 байт0-254 байта1 байт

Рис. 4.6.4.9. Структура блока

Кодирование PCB зависит от его типа, оно представлено в таблицах 4.6.4.13-15.

Таблица 4.6.4.13. Кодирование PCB I-блоков

b80
b7Номер по порядку
b6Цепочка (есть еще данные)
b5-b1Зарезервировано на будущее

Таблица 4.6.4.14. Кодирование PCB R-блоков

b81
b70
b60
b5Номер по порядку
b4-b1

0 - Отсутствие ошибки
1 - EDC и/или ошибка четности
2 - другие ошибки
остальные коды зарезервированы

Таблица 4.6.4.15. Кодирование PCB S-блоков

b81
b71
b6

0 - запрос
1 - отклик

b5-b1

0 - запрос повторной синхронизации
1 - запрос размера поля данных
2 - запрос абортирования
3 - расширение BWT-запроса
4 - VPP-ошибка
остальные коды зарезервированы

Поле LEN определяет размер информационного поля и может равняться 0-254. R-блоки не имеют поля данных. Блоки I- и S-типов нумеруются по модулю 2, их число может равняться 0 или 1 (первый блок имеет номер 0). Счетчик нумерации сбрасывается в 0 после ресинхронизации.

Поле EDC представляет собой объединение всех байт блока, начиная с NAD и кончая последним байтом поля INF (если это поле присутствует), с помощью операции исключающее ИЛИ.

Максимальный размер поля данных ICC (IFSC) блока определяется параметром ТА3, присылаемым ICC в отклике на сброс. IFSI может принимать значения 10-FE, что означает для IFSC диапазон 16-254 байта. Максимальный размер поля данных терминала (IFSD) составляет 254 байта.

Время ожидания блока BWT (Block Waiting Time) в общем случае вычисляется согласно следующей формуле. Реально BWT может лежать в диапазоне (971-15371)t.

Когда отправитель намерен передать объем данных больше, чем это определено параметрами IFSC или IFSD, он должен разбить эту последовательность байтов на несколько I-блоков. Передача этих блоков осуществляется с привлечением механизма цепочек. Для объединения I-блоков в цепочку используется бит b6 в PCB (смотри табл. 4.6.4.13). Если b6=0, то это последний блок в цепочке. Если же b6=1, далее следует как минимум еще один блок. Получение любого I-блок с b6=1 должно быть подтверждено R-блоком. Последний блок цепочки, посланный терминалом, подтверждается I-блоком, если получен безошибочно, или R-блоком, при обнаружении ошибки. В случае ICC получение последнего блока цепочки подтверждается R-блоком при обнаружении ошибки. Если ошибки не было, терминал просто посылает очередной I-блок, если должна обрабатываться очередная команда. Передача цепочки возможна в одно и тоже время только в одном направлении. Когда терминал является получателем, он воспринимает цепочки I-блоков, передаваемых ICC, если длина блоков ≤ IFSD. Если получателем является ICC, карта воспринимает цепочку I-блоков, посланных терминалом и имеющих длину LEN=IFSC, за исключением последнего блока, длина которого может лежать в диапазоне (1-IFSC). Если длина блока > IFSC, ICC такой блок отвергает, послав R-блок с битами b4-b1 в PCB, равными 2.

4.6.4.2. Элементы данных и файлы

Приложение в ICC содержит набор информационных элементов. Терминал может получить доступ к этим элементам после успешного выбора приложения. Информационным элементам присваиваются имена, они имеют определенное описание содержимого, формат и кодирование. Информационный объект состоит из метки (tag), кода длины и значения. Метка однозначно идентифицирует объект в рамках данного приложения. Поле длина определяет число байт в поле значение. Объекты могут объединяться, образуя составные объекты. Определенное число простых или составных объектов могут образовывать записи. Присвоение меток регламентируется документами ISO/IEC 8825 и ISO/IEC 7816. Записи, содержащие информационные объекты, хранятся в файлах ICC. Структура файла и метод доступа зависят от назначения файла. Организация файлов определяется приложениями платежной системы PSA (Payment System Application). Проход к набору PSA в ICC разрешается с помощью выбора среды платежной системы PSE (Payment System Environment). Когда PSE присутствует, файлы, относящиеся к PSA, доступны для терминала через древовидную структуру каталога. Каждая ветвь этого дерева является файлом определения приложения ADF (Application Definition File) или файлом определения каталога DDF (Directory Definition File). ADF является входной точкой одного или нескольких прикладных первичных файлов AEF (Application Elementary File). ADF со стороны терминала воспринимается как файл, содержащий информационные объекты, которые инкапсулированы в FCI (File Control Information). Информационные файлы состоят из последовательности пронумерованных записей. Каждому файлу присваивается короткий идентификатор SFI (принимает значения 1-10), с помощью которого можно обращаться к файлу. Чтение каталога осуществляется с помощью команды READ RECORD.

Когда PSE присутствует, ICC поддерживает структуру каталога для списка приложений в пределах PSE (определяется эмитентом карты). Каждому приложению присваивается идентификатор AID (Application Identifier; ISO/IEC 7816-5). К любому ADF или DDF в карте обращение производится посредством имени DF (Dedicated File). DF для ADF соответствует AID и для данной карты должно быть уникальным. Формат записи каталога PSE показан на рисунке 4.6.4.11.

Метка

70

Длина
данных
(L)

Метка
61

Длина элемента 1 каталога

Элемент каталога 1 (ADF или DDF)



Метка
61

Длина элемента N каталога

Элемент каталога N (ADF или DDF)

Рис. 4.6.4.11. Формат записи каталога PSE

Содержимое полей элемент каталога характеризуется в таблицах 4.6.4.16 и 4.6.4.17.

Таблица 4.6.4.16. Формат элемента каталога DDF

Метка (Tag)ДлинаЗначение
9D5-16Имя DDF
73переменнаяШаблон каталога

Таблица 4.6.4.17. Формат элемента каталога ADF

Метка (Tag)ДлинаЗначение
0х4F5-16Имя ADF (AID)
0х501-16Метка приложения
0х9F121-16Предпочитаемое имя приложения
0х871Индикатор приоритетности приложения
0х73переменнаяШаблон каталога

Понятно, что в области, где используются карты ICC, наиболее важными являются аспекты безопасности.

4.6.4.3. Соображения безопасности

  1. Статическая аутентификация данных

Статическая аутентификация выполняется терминалом, использующим цифровую подпись, которая базируется на методике общедоступных ключей. Эта техника позволяет подтвердить легитимность некоторых важных данных, записанных в ICC и идентифицируемых с помощью AFL (Application File Locator).

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

Рис. 4.6.4.12. Диаграмма статической аутентификации данных

Карта ICC, которая поддерживает статическую аутентификацию данных, должна содержать следующие информационные элементы.

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

  • Сертификат общедоступного ключа эмитента карты. Этот элемент имеет переменную длину и предоставляется центром сертификации эмитенту карты.

  • Подписанные данные приложения. Информационный элемент переменной длины, формируемый эмитентом карты с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате эмитента.

  • Остаток (remainder) общедоступного ключа эмитента. Опционный элемент переменной длины ICC.

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

Для поддержки статической аутентификации ICC должна содержать статические прикладные данные, подписанные секретным ключом эмитента. Общедоступный ключ эмитента записывается в ICC вместе с сертификатом общедоступного ключа. Модуль общедоступного ключа сертификационного ключа имеет NCA байт, где NCA ≤ 248, показатель степени этого ключа равен 2, 3 или 216+1.

Общедоступный ключ эмитента имеет модуль ключа, содержащий NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части. Одна часть, состоящая из NCC -36 старших байт модуля (левые цифры общедоступного ключа эмитента), и вторая часть с оставшимися NЭ - (NCC - 36) младшими байтами. Показатель степени общедоступного ключа эмитента должен быть равен 2, 3 или 216+1.

Вся необходимая информация, необходимая для статической аутентификации записывается в ICC (смотри таблицу 4.6.4.18 и 4.6.4.19). За исключением RID (Registered Application Provider Identifier), который может быть получен из AID (Application Identifier), эта информация может быть получена посредством команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

Таблица 4.6.4.18. Данные, сопряженные с общедоступным ключом эмитента, которые должны быть подписаны центром сертификации.

Имя поля

Длина
(байт)

Описание
Формат сертификата1Шестнадцатеричное число 0х02
Идентификационный номер эмитента4

Левые 3-8 цифр номера первичного счета PAN (Primary Account Number)

Дата истечения действительности сертификата2MMГГ, после которых данный сертификат не действителен
Серийный номер сертификата3Двоичное число уникальное для сертификата сертификационного центра
Индикатор хэш-алгоритма1Идентифицирует хэш-алгоритм, используемый для получения электронной подписи
Индикатор алгоритма общедоступного ключа эмитента1

Идентифицирует алгоритм цифровой подписи, используемый с общедоступным ключом эмитента

Длина общедоступного ключа эмитента1Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента1

Идентифицирует длину показателя общедоступного ключа эмитента в байтах

Общедоступный ключ эмитента или левые цифры этого ключаNCC - 36

Если NЭ ≤ NCC -36, это поле состоит из общедоступного ключа эмитента дополненного справа NCC - 36 - NЭ байтами, равными BB.

Если NЭ > NCC -36, это поле состоит из NCC - 36 старших байт общедоступного ключа эмитента

Остаток общедоступного ключа эмитента

0 или
NЭ - NCC + 36

Это поле присутствует, только если NЭ > NCC -36, оно состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента

Показатель общедоступного ключа эмитента1 или 3

Показатель общедоступного ключа эмитента, равный 2, 3 или 216+1.

Таблица 4.6.4.19. Статическая прикладная информация, подписываемая эмитентом

Имя поля

Длина
(байт)

Описание
Формат подписанных данных1Шестнадцатеричное число 0х03
Индикатор хэш-алгоритма1

Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи

Код аутентификации данных2Код, присвоенный эмитентом
Код заполнителяNЭ - 26Код байта заполнителя, равный 0хBB
Статические данные, подлежащие аутентификацииПеремен-ная

Статические данные, которые подлежат аутентификации согласно требованиям приложения ICC

Таблица 4.6.4.20. Информационные объекты, необходимые для аутентификации статических данных

Метка (Tag)ДлинаЗначение
-5Зарегистрированный идентификатор провайдера приложения (RID)
0х8F1Индекс общедоступного ключа сертификационного центра
0х90NCCСертификат общедоступного ключа эмитента
0х92NЭ - NCC + 36Остаток общедоступного ключа эмитента (если присутствует)
0х9F321 или 3Показатель общедоступного ключа эмитента
0х93NЭПодписанные статические прикладные данные
-ПеременнаяСтатические данные, которые должны быть аутентифицированы

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

Если сертификат общедоступного ключа эмитента имеет длину отличную от модуля общедоступного ключа сертификационного центра, то аутентификация не пройдет.

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

Таблица 4.6.4.21. Формат восстановленных данных сертификата общедоступного ключа эмитента

Имя поля

Длина
(байт)

Описание
Заголовок восстановленных данных1Шестнадцатеричное число 0х6A
Формат сертификата1Шестнадцатеричное число 0х02
Идентификационный код эмитента4Левые 3-8 цифр РАN, дополняемые справа кодами 0хF
Дата истечения действия сертификата2Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата1Двоичное число уникальное для сертификата, выданного центром сертификации
Индикатор хэш-алгоритма1Идентифицирует хэш-алгоритм, используемый для получения кода поля результата хэширования при вычислении электронной подписи
Индикатор алгоритма общедоступного ключа эмитента1Идентифицирует алгоритм цифровой подписи, который должен быть использован совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента1Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента1Идентифицирует длину показателя степени общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры общедоступного ключа эмитентаNCC - 36

Если NЭ ≤ NCC - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NCC - 36 - NЭ байтами, содержащими код BB.
Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байт общедоступного ключа эмитента

Результат хэширования20Хэш-код общедоступного ключа эмитента и сопряженной с ним информации
Хвостовик восстановленных данных1Шестнадцатеричное число 0хВС

Проводится проверка заголовка восстановленных данных и, если он не равен 0х6А, аутентификация аннулируется.

Проверяется поле формат сертификата и, если его код не равен 0х02, аутентификация отвергается.

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

Результат данного объединения подвергается хэшированию согласно заданному алгоритму. Полученный результат сравнивается со значением поля результат хэширования (см. табл. 4.6.4.21). Если совпадения нет, аутентификация не состоялась.

Проверяется, что идентификационный номер эмитента соответствует левым цифрам 3-8 PAN. При несоответствии аутентификация отвергается.

Проверяется, не закончился ли срок действия сертификата. Если срок истек, аутентификации не происходит.

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

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

Если подписанные статические прикладные данные имеют длину, отличную от длины модуля общедоступного ключа эмитента, аутентификация не состоится.

Для того чтобы получить данные, представленные в таблице 4.6.4.22, берутся подписанные статические прикладные данные и общедоступный ключ эмитента. Если хвостовик восстановленных данных окажется не равным BC, аутентификация отвергается.

Таблица 4.6.4.22. Формат восстановленных данных из подписанных статических прикладных данных.

Имя поля

Длина
(байт)

Описание
Заголовок восстановленных данных1Шестнадцатеричное число 0х6А
Формат подписанных данных1Шестнадцатеричное число 0х03
Индикатор хэш-алгоритма1

Идентифицирует алгоритм хэширования, используемый для вычисления поля результат хэширования для цифровой подписи

Код данных аутентификации2Код, присвоенный эмитентом
Код заполнителяNЭ - 26Код байтов заполнителя, равный 0хBB
Результат хэширования20Хэш статических прикладных данных, которые должны быть аутентифицированы
Хвостовик восстановленных данных1Шестнадцатеричное число 0хВС

Проверяется заголовок восстановленных данных и, если он не равен 0х6A, аутентификация не проходит.

Проверяется формат подписанных данных и, если его код не равен 0х03, аутентификация не проходит.

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

4.6.4.4. Динамическая аутентификация данных

Динамическая аутентификация данных выполняется терминалом, с использованием цифровой подписи, базирующейся на технике общедоступного ключа, и имеет целью аутентифицировать ICC и подтвердить легитимность динамической информации, записанной на ICC. Динамическая аутентификация требует наличия центра аутентификации, который подписывает общедоступные ключи эмитента. Каждый терминал должен иметь общедоступные ключи сертификационного центра для каждого приложения, распознаваемого терминалом. Схема аутентификации динамических данных показана на рис. 4.6.4.12.

Рис. 4.6.4.12. Схема динамической аутентификации данных

ICC, которая поддерживает аутентификацию динамических данных, должна содержать следующие информационные элементы.

  • Индекс общедоступного ключа сертификационного центра. Этот элемент состоит из одного байта, который указывает, какой из общедоступных ключей сертификационного центра и алгоритм, доступный терминалу, следует использовать с данной картой ICC.

  • Сертификат общедоступного ключа эмитента. Этот элемент переменной длины записывается в ICC эмитентом карты. Когда терминал проверяет этот элемент, он аутентифицирует общедоступный ключ и сопутствующие данные ICC.

  • Остаток общедоступного ключа эмитента.

  • Показатель общедоступного ключа эмитента.

  • Остаток общедоступного ключа ICC.

  • Показатель общедоступного ключа ICC.

  • С

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

ICC, которые поддерживают аутентификацию динамических прикладных данных, должны сформировать следующий информационный элемент.

Подписанные динамические прикладные данные. Этот информационный элемент переменной длины формируется ICC с помощью секретного ключа, который соответствует общедоступному ключу, аутентифицированному в сертификате общедоступного ключа ICC.

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

ICC, поддерживающая аутентификацию динамических данных должна иметь пару ключей, один из которых является секретным, служащим для цифровой подписи, другой - общедоступный для верификации. Общедоступный ключ ICC запоминается ИС картой в сертификате общедоступного ключа, сформированном эмитентом карты. Общедоступный ключ эмитента сертифицирован центром сертификации. Как следствие для верификации подписи ICC терминал должен сначала верифицировать два сертификата, для того чтобы получить и аутентифицировать общедоступный ключ ICC, который далее служит для проверки корректности динамической подписи ICC.

Процедура цифровой подписи использует данные, представленные в таблицах 4.6.4.23 и 4.6.4.24. Модуль общедоступного ключа сертификационного центра содержит NCC байт, где NCC ≤ 248. Показатель общедоступного ключа сертификационного центра равен 2, 3 или 216+1. Модуль общедоступного ключа эмитента содержит NЭ байт, где NЭ < 248 и NЭ < NCC. Если NЭ > (NCC - 36), модуль общедоступного ключа эмитента делится на две части, одна состоит из NCC - 36 старших байт модуля (левые цифры), а вторая часть содержит остальные NЭ - (NCC - 36) младших байт модуля (остаток общедоступного ключа эмитента). Показатель общедоступного ключа эмитента равен 2, 3 или 216+1.

Модуль общедоступного ключа ICC содержит NIC байт, где NIC ≤ 128 и NIC < NЭ. Если NIC > (NЭ - 42), модуль общедоступного ключа ICC делится на две части, одна - состоит из NЭ - 42 старших байт модуля (левые цифры общедоступного ключа ICC) и остальных NIC - (NЭ - 42) младших байт модуля (остаток общедоступного ключа ICC). Показатель общедоступного ключа ICC равен 2, 3 или 216+1.

Для осуществления аутентификации динамических данных терминал сначала извлекает и аутентифицирует общедоступный ключ ICC (аутентификация общедоступного ключа ICC). Вся информация, необходимая для аутентификации общедоступного ключа ICC представлена в таблице 4.6.4.25 и хранится в памяти ICC. За исключением RID, который может быть получен из AID, эта информация извлекается с помощью команды READ RECORD. Если что-то из этой информации отсутствует, аутентификация терпит неудачу.

Таблица 4.6.4.23. Данные общедоступного ключа эмитента, которые должны быть подписаны сертификационным центром.

Имя поля

Длина
(байт)

Описание
Формат сертификата1Шестнадцатеричное число 0х02
Идентификационный номер эмитента4Левые 3-8 цифр от PAN (дополняемые справа кодами 0хF)
Дата истечения времени действия сертификата2Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата3Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма1Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента1Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента1Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента1Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключаNCC - 36

Если NЭ ≤ NCC - 36, это поле состоит из полного общедоступного ключа эмитента дополненного справа NCC -36 - NЭ байт с кодом 0хBB.
Если NЭ > NCC - 36, это поле состоит из NCC - 36 старших байтов общедоступного ключа эмитента

Остаток общедоступного ключа эмитента

0 или
NЭ -NCC + 36

Это поле присутствует только если NЭ > NCC - 36 и состоит из NЭ - NCC + 36 младших байт общедоступного ключа эмитента

Показатель общедоступного ключа эмитента1 или 3Показатель общедоступного ключа эмитента равен 2, 3 или 216+1

Таблица 4.6.4.24. Данные общедоступного ключа ICC, которые должны быть подписаны эмитентом карты

Имя поля

Длина
(байт)

Описание
Формат сертификата1Шестнадцатеричное число 0х04
PAN (Primary Application Number) приложения10PAN дополненный справа кодами 0хF
Дата истечения времени действия сертификата2Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата3Двоичное число, уникальное для данного сертификата, присваиваемое эмитентом
Индикатор хэш-алгоритма1Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC1Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC1Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC1Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры этого ключаNЭ - 42

Если NIC ≤ NЭ - 42, это поле состоит из полного общедоступного ключа ICC дополненного справа NЭ - 42 - NIC байт с кодом 0хBB.

Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC

Остаток общедоступного ключа ICC

0 или

NIC - NЭ + 42

Это поле присутствует, только если NIC > NЭ - 42 и состоит из NЭ - N + 42 младших байт общедоступного ключа ICC

Показатель общедоступного ключа ICC1 или 3Показатель общедоступного ключа ICC равен 2, 3 или 216+1
Данные, подлежащие аутентификацииПеременнаяСтатические данные, подлежащие аутентификации согласно спецификации ICC для платежных систем

Таблица 4.6.4.25. Информационные объекты, необходимые для аутентификации общедоступного ключа

Метка (Tag)

Длина
(байт)

Описание
-5Зарегистрированный идентификатор провайдера приложения (RID)
0х8F1Индекс общедоступного ключа центра сертификации
0х90NCCСертификат общедоступного ключа эмитента
0х92NЭ - NCC + 36Остаток общедоступного ключа эмитента (если имеется)
0х9F321 или 3Показатель общедоступного ключа эмитента
0х9F46NЭСертификат общедоступного ключа ICC
0х9F48NIC - NЭ + 42Остаток общедоступного ключа ICC (если он имеется)
0х9F471 или 3Показатель общедоступного ключа ICC
-ПеременнаяДанные, подлежащие аутентификации

Терминал считывает индекс общедоступного ключа центра сертификации. Используя этот индекс и RID, терминал может идентифицировать и извлечь из памяти модуль и показатель общедоступного ключа сертификационного центра и сопряженную с ним информацию. Если терминал не сможет найти нужные данные, сертификация не состоится.

Если сертификат общедоступного ключа эмитента имеет длину отличную от длины модуля общедоступного ключа сертификационного центра, аутентификация динамических данных не проходит.

Для того чтобы получить восстановленные данные, представленные в таблице 4.6.4.26, используется сертификат общедоступного ключа эмитента и общедоступный ключ центра сертификации. Если хвостовик восстановленных данных не равен 0хBC, аутентификация динамических данных не проходит.

Проверяется заголовок восстановленных данных и, если он не равен 0х6А, аутентификация отвергается.

Проверяется код формата сертификата и, если он не равен 0х02, аутентификация отвергается.

Объединяются слева направо информационные элементы со второго по десятый (см. табл. 4.6.4.26), добавляется остаток общедоступного ключа эмитента (если он имеется) и показатель этого ключа. Для полученной строки применяется соответствующий алгоритм хэширования. Сравнивается вычисленный хэш и восстановленное значение поля результата хэширования. При несовпадении аутентификация не проходит.

Таблица 4.6.4.26. Формат восстановленных данных из сертификата общедоступного ключа эмитента.

Имя поля

Длина
(байт)

Описание
Заголовок восстановленных данных1Шестнадцатеричное число 0х6А
Формат сертификата1Шестнадцатеричное число 0х02
Идентификационное число эмитента4Левые 3-8 цифр из PAN, дополненные справа кодами 0хF
Дата истечения времени действия сертификата2Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата3Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма1Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа эмитента1Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом эмитента
Длина общедоступного ключа эмитента1Идентифицирует длину модуля общедоступного ключа эмитента в байтах
Длина показателя общедоступного ключа эмитента1Идентифицирует длину показателя общедоступного ключа эмитента в байтах
Общедоступный ключ эмитента или левые цифры этого ключаNCC - 36

Если NЭ ≤ NСС - 36, это поле состоит из полного общедоступного ключа эмитента, дополненного справа NСС - 36 - NЭ байтами с кодом 0хBB.
Если NЭ > NСС - 36, это поле состоит из NСС - 36 старших байтов общедоступного ключа эмитента

Результат хэширования20Хэш общедоступного ключа эмитента и сопряженных данных
Хвостовик восстановленных данных1Шестнадцатеричное число 0хВС

Проверяется то, что идентификационный номер эмитента соответствуют 3-8 цифрам PAN. Если соответствия нет, аутентификация отвергается.

Проверяется срок действия сертификата и, если он истек, аутентификация отвергается.

Проверяется то, что объединение RID, индекса общедоступного ключа центра сертификации и серийного номера сертификата корректно.

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

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

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

Если при проверке код заголовка восстановленных данных не равен 0х6А, аутентификация не проходит.

Если код формата сертификата не равен 0х04, аутентификация также не проходит.

Таблица 4.6.4.27. Формат восстановленных данных из сертификата общедоступного ключа ICC.

Имя поля

Длина

(байт)

Описание
Заголовок восстановленных данных1Шестнадцатеричное число 0х6А
Формат сертификата1Шестнадцатеричное число 0х04
PAN приложения10PAN, дополненный справа кодами 0хF
Дата истечения времени действия сертификата2Дата ММГГ, после которой сертификат становится недействительным
Серийный номер сертификата3Двоичное число, уникальное для данного сертификата, присваиваемое центром сертификации
Индикатор хэш-алгоритма1Индицирует алгоритм, используемый для вычисления результирующего хэша цифровой подписи
Индикатор алгоритма общедоступного ключа ICC1Индицирует алгоритм вычисления цифровой подписи, который должен использоваться совместно с общедоступным ключом ICC
Длина общедоступного ключа ICC1Идентифицирует длину модуля общедоступного ключа ICC в байтах
Длина показателя общедоступного ключа ICC1Идентифицирует длину показателя общедоступного ключа ICC в байтах
Общедоступный ключ ICC или левые цифры общедоступного ключа ICCNЭ - 42

Если NIC ≤ NЭ - 42, это поле состоит из полного общедоступного ключа ICC, дополненного справа NЭ - 42 - NIC байтами с кодом 0хBB.
Если NIC > NЭ - 42, это поле состоит из NЭ - 42 старших байтов общедоступного ключа ICC

Результат хэширования20Хэш общедоступного ключа ICC и сопряженных с ним данных
Хвостовик восстановленных данных1Шестнадцатеричное число 0хВС

Объединяются слева направо поля из таблицы 4.6.4.27, начиная со второго до десятого, добавляется остаток общедоступного ключа ICC (если имеется), показатель общедоступного ключа ICC и данные, подлежащие аутентификации. Это объединение хэшируется согласно указанному алгоритму. Результат сравнивается со значением поля результат хэширования. При несовпадении аутентификация не проходит.

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

После получения общедоступного ключа ICC терминал выдает команду INTERNAL AUTHENTICATE для объединения информационных элементов DDOL (Dynamic Data Authentication Data Object List). ICC может нести в себе DDOL, но терминал имеет значение DDOL по умолчанию, специфицированное платежной системой на случай отсутствия этих данных в ICC. DDOL должен содержать непредсказуемое число, формируемое терминалом (тэг 0х9F37, четыре двоичных байта).

ICC генерирует цифровую подпись для данных, специфицированных в таблице 4.6.4.28 с использованием секретного ключа (SIC) ICC. Результат называется подписанными динамическими данными приложения.

Таблица 4.6.4.28. Динамические данные приложения, которые должны быть подписаны

Имя поля

Длина
(байт)

Описание
Формат подписанных данных1Шестнадцатеричное число 0х05
Индикатор хэш-алгоритма1Индицируется алгоритм хэширования, используемый для получения результата
Длина динамических данных ICC1

Идентифицирует длину LDD динамических данных ICC в байтах

Динамические данные ICCLDDДинамические данные, сформированные и/или записанные в ICC
Символы заполнителяNIC - LDD - 25 (NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB
Динамические данные терминалаПеременнаяОбъединение информационных элементов, специфицированных DDOL

Длина динамических данных ICC LDD удовлетворяет условию 0 ≤ LDD ≤ NIC - 25. 3-9 самых левых байтов динамических данных ICC включают в себя 1 байт длины динамического числа ICC, за которым следует 2-8 байт значения этого числа (тэг 9F4C, 2-8 двоичных байтов). Динамическое число ICC формируется ICC.

Кроме данных, перечисленных в таблице 4.6.4.28, для аутентификации динамических данных необходимы информационные объекты:

Подписанные динамические данные приложения (NIC байтов; тэг 9F4B) и DDOL (тэг 9F49).

Если подписанные динамические данные приложения имеют длину отличную от длины модуля общедоступного ключа ICC, аутентификация не проходит.

Чтобы получить восстановленные данные, описанные в таблице 4.6.4.29 для подписанных динамических данных приложения используется общедоступный ключ ICC. Если хвостовик восстановленных данных не равен 0хBC, аутентификация не проходит.

Таблица 4.6.4.29. Формат данных, полученных из подписанных динамических данных приложения

Имя поля

Длина
(байт)

Описание
Заголовок восстановленных данных1Шестнадцатеричное число 0х6А
Формат подписанных данных1Шестнадцатеричное число 0х05
Индикатор алгоритма хэширования1Индицируется алгоритм хэширования, используемый для получения результата при вычислении цифровой подписи
Длина динамических данных ICC1Идентифицирует длину динамических данных ICC в байтах
Динамические данные ICCLDDДинамические данные, сформированные и/или записанные в ICC
Символы заполнителяNIC - LDD - 25(NIC - LDD - 25) байтов заполнителя, содержащего коды 0хBB
Результат хэширования20Хэш динамических данных приложения и сопряженной информации
Хвостовик восстановленных данных1Шестнадцатеричное число 0хВС

Далее проверяется заголовок восстановленных данных, если его код не равен 0х6А, аутентификация не проходит. Проверяется код формата подписанных данных и, если он не равен 0х05, аутентификация не проходит.

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

4.6.4.5. Безопасный обмен сообщениями

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

Формат 1 следует спецификации ISO/IEC 7816-4, где поле данных кодируется согласно BER-TLV и правилам ASN.1/ISO 8825. Этот формат задается младшим полубайтом класса команды равным 0xC. Формат предполагает также, что заголовок команды включается в вычисление MAC (Message Authentication Code).

Формат 2 не использует кодирования BER-TLV. В этом случае информационные объекты, содержащиеся в поле данных и их длины должны быть известны отправителю команды и выбранному приложению. Согласно спецификации ISO/IEC 7816-4 этот формат задается младшим полубайтом байта класса, который должен быть равен 0х4.

Поле данных команды в случае формата 1 состоит из следующих TLV (Tag Length Value) информационных объектов, как это показано на рисунке 4.6.4.13.

Рис. 4.6.4.13. Формат 1 поля данных команды для безопасного обмена сообщениями

Данные команды, если имеются, должны быть подписаны. Если поле данных закодировано согласно BER-TLV, оно либо не должно принадлежать контекстному классу (тэг лежит вне диапазона 80-BF), либо иметь четный тэг. Вторым информационным объектом является MAC. Его тэг равен 0х8Е, а его длина лежит в диапазоне 4-8 байт.

В случае формата 2 МАС не кодируется BER-TLV и всегда является последним элементом информационного поля, а его длина лежит в пределах 4-8 байт.

Вычисление s байтов МАС (4≤s≤8) осуществляется согласно ISO/IEC9797 с использованием 64-битового блочного шифра ALG в режиме CBC.

Процедура формирования МАС начинается с получения ключа сессии из мастерного ключа МАС ICC. Ключ сессии KS для безопасного обмена сообщениями получается из уникальных мастерных ключей MK с привлечением непредсказуемых данных R, так что KS := F(KS)[R]. Единственным требованием к функции F является то, что число возможных ее значений достаточно велико и равномерно распределено.

При использовании формата 1 сообщение состоит из заголовка команды APDU (Application Protocol Data Unite = CLA INS P1 P2) и командной информации (если таковая имеется).

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

Если МАС специфицирован, как имеющий длину менее 8 байтов, он получается из старших (левых) байтов 8-байтного результата его вычисления.

Формат зашифрованных командных данных показан на рисунке 4.6.4.14.

ТэгДлинаЗначение
TLКриптограмма (зашифрованные данные)

Рис. 4.6.4.14. Формат 1 для зашифрованных командных данных

Тэг, согласно спецификации ISO/IEC 7816-6 определяется характером исходных (незашифрованных данных). Четный тэг используется, если объект должен быть включен в вычисление МАС; во всех остальных случаях тэг должен быть нечетным.

В случае формата 2 поле данных команды шифруется как целое, исключение составляет MAC, если он присутствует (см. рис. 4.6.4.15)

Значение 1Значение 2
Криптограмма (зашифрованные данные)МАС (если имеется)

Рис. 4.6.4.15. Формат 2 поля данных команды

Процедура шифрования начинается с получения ключа сессии, который вычисляется на основе мастерного ключа шифрования ICC (см. выше). Шифрование производится с использованием 64-битного блочного шифра ALG в режиме СВС (симметричная схема).

Для увеличения безопасности может использоваться PIN (Personal Identification Number). Верификация PIN осуществляется терминалом с использованием асимметричного алгоритма (общедоступный и секретный ключи).

Более полное описание технологии EMV вы можете найти по адресу (английская версия): ftp://saturn.itep.ru/~emvcard.pdf

Не исключено, что конкуренцию EMV-картам в торговле через Интернет составят виртуальные кредитные карты, применение которых упомянуто во введении.

Назад: 4.6.3. Протокол для работы с кредитными картами CyberCash версия 0.8
Оглавление: Телекоммуникационные технологии
Вперёд: 5. Диагностика локальных сетей и Интернет

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...