apdu команды что такое

Смарт-карты. Часть 2. APDU

После общей информации, описанной в первой части, сегодня поговорим об APDU в формате, описанном в стандарте ISO7816-4.

APDU (application protocol data unit) — это формат общения карты и терминала. Терминал посылает Command APDU (C-APDU), а карта отвечает с Response APDU (R-APDU).

C-APDU

Формат C-APDU таков:

Каждый элемент заголовка (header) сохранен на одном байте и является обязательным. К заголовку вернемся чуть позже, сейчас поговорим о body команды.

Элементы body следующие:

Lc и Le, если присутствуют, могут занимать 1 (Short Length) или 3 байта (Extended Length) каждый. При Short Length кодируются значения от 1 до 256. Длина данных на 256 байтов записывается как «00». При Extended Length кодируются значения от 1 до 65536. Первый байт всегда «00» и остальные 2 байта — номер в формате Big Endian. Когда Lc или Le — «00 00 00», то длина данных — 65536 байтов.

В зависимости от присутствия или отсутствия элементы body команды можно разделить на 4 категории:

Так как серия моих статей нацелена на рассмотрение в подробностях Global Platform, то значение CLA я буду описывать в контексте Global Platform.

b5 в стандарте ISO7816-4 обозначает Command Chaining. В Global Platform не используется.

R-APDU

Формат R-APDU таков:

Body присутствует при успешном исполнении (с замечаниями или без них) команд из категории Case 2 и Case 4. Его содержание зависит от конкретной команды. Trailer есть всегда и содержит так называемый Status Word, то есть код результата, положительного или отрицательного. Статус может быть одним из следующих:

Ошибки из серии 69ХХ и 6АХХ часто используются в Global Platform и будут описаны в подробностях в частях статьи, посвященных Global Platform.

Статусы из серии 61ХХ и 6CXX требуют особенного внимания. Код 61ХХ возможен, когда карта исполнила команду из категории Case 2 или Case 4 и послала неполный ответ. В этом случае, SW2 кодирует длину остатка ответа («00» = 256). В ответ терминал может отправить команду GET RESPONSE для того, чтобы получить оставшиеся данные. Эта процедура может повторяться несколько раз, до тех пор, пока карта не отправит полный ответ. Настоящий Status Word — это статус, содержащийся в последнем ответе на команду GET RESPONSE. Подобная ситуация встречается преимущественно, когда APDU передается через протокол ISO7816-3 T=0 ввиду особенности передачи команд из категории Case 4 (об этом поговорим чуть позже). Код 6CXX встречается, когда указанный Le не соответствует действительной длине ответа. Стоит отметить, что при этом карта не посылает никаких данных в R-APDU, а требует, чтобы терминал повторил команду с Le равным числу, закодированному в SW2.

Особенности передачи команд в категории Case 4 через протокол Т=0

Протокол T=0 очень распространен, так как он используется в SIMках. Его особенность заключается в том, что header всегда состоит из 5 байтов: CLA, INS, P1, P2, P3. P3 может быть использован для кодировки Lc либо Le. Получается, что он, будет лишним для команд Case 1, подходит для команд Case 2 и Case 3, но недостаточен для команд Case 4, где нужны как Lc, так и Le. Как можно решить эту проблему?

Следующим образом. Команды Case 4 передаются с P3=Lc, как будто это команда Case 3. Тогда карта, при успешном исполнении команды, отвечает без данных, но со статусом 61ХХ. В свою очередь терминал посылает команду GET RESPONSE (из категории Case 2), а затем карта посылает настоящий ответ.

GET RESPONSE

Примеры общения с картой

Наконец-то, мы подошли к самой интересной части статьи — примеры.

GET DATA (Card Production Life Cycle)

C-APDU => 80 CA 9F 7F 00
R-APDU 80 CA 9F 7F 2D
R-APDU 80 F2 40 00 08 4F 06 31 32 33 34 35 36 09
R-APDU 80 F2 40 00 08 4F 06 31 32 33 34 35 36
R-APDU => 61 09
C-APDU => 00 C0 00 00 09
R-APDU

Источник

Эквайринг: EMV-транзакция (EMV Transaction Flow). Часть 1: Интерфейсы и основы APDU

Введение

В данном цикле работ постараемся просто и доступно рассказать о том, что происходит между картой и устройством в момент совершения покупки по POS-терминалу, либо при обслуживании в ATM. Поочередно рассмотрим все шаги обмена между чиповой картой и устройством. То есть, расскажем о том, что принято называть «EMV Transaction flow» (Транзакционный цикл EMV). Первая часть посвящена обзору интерфейсов обмена и базовым принципам работы формата APDU.

Интерфейсы обмена

«Интерфейсом» принято называть тот или иной способ обмена между картой и устройством. В контексте POS или ATM следует перечислить три основные интерфейса:

1. MS/MStripe, или Magnetic Stripe (Магнитная полоса) — наиболее старый интерфейс обмена, постепенно «уходящий в лету». Главным образом по причинам технологического несовершенства и логически вытекающих из него проблем с безопасностью. В силу его бесперспективности (а также простоты) ограничимся лишь сжатым обзором механизмов реализации. В основе «магнитки» лежит набор данных, состоящий из двух или трех объектов (так называемых «трэков»). Они включают в себя номер карты, срок ее действия, фамилию/имя кардхолдера, а также сервис-код и некий набор данных для проверки валидности карты (т.н. CVV, Card Verification Value). Сервис-код, в свою очередь, содержит параметры, контролирующие региональное использование карты (транзакции внутри страны, международные и т.д.), онлайн-запросы к эмитенту, а также допустимые сервисы (POS/ATM) и условия запроса пин-кода. Как уже говорилось, поскольку структура данных достаточно проста, а объем их ограничен, магнитная карта легко копируется мошенниками. Что и является основной причиной отказа от использования данного интерфейса в настоящее время.

2. ICC Contact (Integrated Circuit Card, Contact) — Контактная карта с интегрированными электронными схемами. Она же именуется «смарт-картой», «EMV-картой» или «чиповой картой». Широко известная классическая контактная чиповая карта. В отличие от «магнитки» обладает несравнимо более высокими технологическими возможностями, а также уровнем безопасности (особенно если эмитент следует всем требованиям и рекомендациям ПС). Интересно, что в сравнении с более современным «бесконтактом», классический контактный чип также обладает рядом возможностей, которые сложно реализуемы на «бесконтакте» в силу особенностей последнего. К таким следует отнести возможность удаленной отправки эмитентом на карту управляющий команд (так называемых «Эмитентских скриптов» (Issuer Scripts)), возможность гибкого управления оффлайновым функционалом (различные лимиты, расчеты комиссии и/или скидки) и ряд других.

H2H (Host to Host)

3. ICC Contactless (Integrated Circuit card, Contactless) — Бесконтактная карта с интегрированными электронными схемами. Не менее широко распространенная в нашем регионе карта, оснащенная встроенной антенной для обмена по бесконтактному интерфейсу. В отличие от контактной EMV-карты, работает на протоколе ISO 14443. Лишена такого недостатка, как скорость обмена, что явным образом подчеркивалось и подчеркивается Платежными системами. Например, известный слоган для Mastercard Contactless — «Just Tap & Go». Характерной особенностью бесконтакта являются существенные отличия при реализации обмена в разрезе той или иной ПС. Иными словами, если обмен по контактной чиповой карте весьма сходен для карт всех ПС (что несомненно положительно влияет при обеспечении поддержки карт той или иной ПС со стороны Участника), то «бесконтакт» варьирован, в ряде случаев, основательно. Например, если бесконтактное ядро Mastercard претерпело не столь значительные изменения, то Contactless Visa обладает рядом фундаментальных, с точки зрения информационного обмена, характерных черт. Из этого следует, что даже при условии того что в конфигурации POS или ATM описаны идентификаторы той или иной карты, совершенно не значит, что устройство будет способно поддерживать их при обмене через бесконтактный интерфейс.

Другой характерной особенностью, логически вытекающей из всего вышесказанного, является некоторое «урезание» технического функционала бесконтактных ядер относительно контактного чипа, продиктованное главным образом соображениями скорости и безопасности. К таковым можно отнести: исключение оффлайновых пин-кодов из списка CVM-методов, исключение хранения имени/фамилии кардхолдера в бесконтактном карточном профиле и ряд других, характерных для каждой конкретной ПС.

Следует сказать, что бесконтакт может быть как «чиповым», так и «магнитным». То есть, обычно бесконтактная карта хранит в себе два профиля, способных работать в режимах эмуляции либо чипа (EMV-Mode), либо магнитной полосы (MSripe-Mode). При этой EMV-Mode является приоритетным способом, а поддержка MStripe-Mode в нашем регионе постепенно исключается из устройств в соответствии с регламентами ПС. Разумеется, «магнитный бесконтакт» в этом случае обладает достаточным уровнем безопасности в сравнении с физической «магниткой», поскольку обладает расширенными возможностями хранения данных и алгоритмов проверки подлинности карты.

Источник

Работа с командами APDU на примере EToken

«… Путь не так уж сложен для понимания. Силы природы, естественные наклонности, схемы событий…
Примитивное миропонимание замечает только четыре стихии и дальше этого не идёт. Словно вселенная сводится к четырём доступным созерцанию понятным явлениям.»
Стивен Эриксон.
«Полночный прилив».

Тема APDU здесь поднималась неоднократно, но в основном касалась смарт карт, для которых нужен карт ридер и карта которую не жалко, плюс софт, так как работать с консольным интерфейсом OpenSC, по крайней мере в Window$, мягко говоря неудобно.
Для этого я написал небольшую программу с оконным интерфесом, работающую через winscard.
Исходники и бинарники можно скачать здесь.
Компилировалось это под Visual studio 2008, необходимо добавить в проект WinSCard.Lib из Microsoft Windows SDK.

Наверное у многих найдутся синие рыбки EToken PRO Java 72 K с истёкшими много лет назад сертификатами ЭЦП (использовать «боевой», с действующей ЭЦП, токен для экспериментов настоятельно не рекомендуется!).
Подойдут также JaCarta Pro, от етокенов отличающиеся только внешне.
Можно также попробовать работать с Gemalto SafeNet eToken 5100, у них можно просмотреть содержимое директорий, но прочитать файл не получится из-за очень маленького (вероятно несколько миллисекунд) таймаута между командами выбрать и прочитать файл, в результате чего команда прочитать файл при ручном вводе ссылается уже на пустое место (ошибка с кодом 69 85). Возможно это одна из причин того, что на некоторых платформах на этих токенах перестают видеть ключи. Относительно SafeNet eToken 5100 (с честной надписью на боку «Made in China») замечу следующее: «Единый клиент JaCarta» работать с ним не хочет и выводит сообщение, что сие изделие не поддерживается, 64-х разрядный eToken PKI Client 5.1 от Aladdin его не видит, но 32 версия под Win XP с ним работает, хотя для этого токена желательно конечно ставить оригинальный SafeNet Authentication Client.

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

Подробности про формат команд APDU можно прочитать например здесь.
Читатель имеющий синюю рыбку может ознакомиться с работой APDU не вставая с дивана.
Необходимо установить драйвер для eToken eToken PKI Client 5.1 или «Единый клиент JaCarta» и подключить токен.

Для подробного просмотра содержимого токена в удобном виде и сверки с тем, что дают команды APDU можно использовать написанный мной на Autoit JaCarta Editor.

Запускаем APDUExplorer, выбираем в списке ридеров «Aladdin Token JC 0» или «ARDS JaCarta 0» или «SafeNet Token JC 0» и можно вводить команды.
Вводить можно как через двоеточия так и через пробелы или всё слитно.

Для начала можно проверить работоспособность, кликнув «Check ATR» и получить ответ токена.

Первая команда — выбор апплета по умолчанию и переход в корневую директорию с идентификатором 3f00 (этот идентификатор пожалуй единственное общее у токенов любых вендоров).
00:A4:00:04:00

Далее получаем список папок корневой директории
80:01:01:00:04:09:02:00:00:CD (команда является константой «Сообщить список папок»).
Должен быть получен ответ:
0a 02 66 66 0b 01 00 90 00

Второй по счёту байт в ответе размер полученных данных — два байта, то есть только одна папка (идентификатор файла или папки в APDU всегда занимает два байта).
И мы видим только одну папку с идентификатором 66 66, называемую Aladdin AID directory.

Сообщить список файлов (тоже константа)
80:01:02:00:04:09:02:00:00:CD
Должно быть получено
0a 00 0b 01 00 90 00
Ответ в позиции 01 — файлов 00.

Переходим в директорию 66 66
00 A4 08 04 02 66 66 00
Это команда SELECT FILE, её формат: четыре байта сама команда 00 A4 08 04, далее размер поля данных полного пути (в примере 02 байта), затем сам путь (в примере 66 66) и обязательно завершение 00.

Сообщить список папок директории 66 66
80:01:01:00:04:09:02:00:00:CD
Resv bytes:
0a 04 50 01 50 00 0b 01 00 90 00
В поле ответа 01 (размер ответа) указано 04, т.е. 4 байта = две папки 50 01 и 50 00, при этом 50 01 — служебная, а 50 00 основная, называемая PKCS#11 directory, где хранятся все данные

Сообщить список файлов директории 66 66
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 00 0b 01 00 90 00
Файлов здесь нет.

Как показали исследования видимых папок и файлов в директории 50 01 нет, поэтому переходим в основную директорию 50 00
00 A4 08 04 04 66 66 50 00 00
Сообщить список папок
80:01:01:00:04:09:02:00:00:CD
Ответ будет зависить от того что хранится на токене.
Сообщить список файлов
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 14 00 0f 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0a 0b 01 00 90 00
Мы видим 14 файлов (поле ответа 01), далее каждые 2 байта это имена файлов, затем идёт служебная информация.

У каждого токена изучаемых моделей всегда пристутствует системная директория b000 и в ней системный файл 0002, попробуем его прочитать, по этому же принципу можно читать и другие файлы.
Переходим в директорию b0 00
00 A4 08 04 06 66 66 50 00 B0 00 00
Получаем список файлов
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 02 00 02 0b 01 00 90 00
Видим файл 00 02 (байт в поле ответа 01 — размер имени (каждое имя всегда занимает два байта, следующие поля — имена файлов, в данном случае файл только один, что определяем по значению поля 01).

Выбрать файл 0002 из B000 по полному пути
00 A4 08 04 08 66 66 50 00 B0 00 00 02 00
Resv bytes:
01 01 02 02 02 00 02 03 02 00 10 04 08 00 ff 00 00 ff ff ff ff 05 00 90 00
Формат ответа здесь следующий: преамбула — 2 байта, тип файла — 1 байт (02 файл, 01 папка), разделитель — 2 байта, имя файла — 2 байта, разделитель — 2 байта, размер файла — 2 байта, разделитель — 2 байта, права доступа — 1 байт (00 — доступен для всех, 63 защищён пин кодом). Далее идёт некая служебная информация, завершающаяся кодом успешного выполнения APDU команды — 90 00.

Прочитать этот файл, последние два байта команды размер буфера сколько надо прочитать (в данном случае равен размеру файла).
80 18 00 00 04 0E 02 00 00 10
Resv bytes: (значение в каждом случае будет своё):
00 06 63 61 72 64 63 66 00 00 00 00 00 00 00 00 90 00

Аутентификацию на етокене я здесь не рассматриваю, так как она состоит из последовательности команд вопрос-ответ и происходит в зашифрованном виде (существует проект Antitoken где проблему авторизации на этих изделиях решили кардинально).
Некоторые другие токены, например JaCarta ГОСТ-2 поддерживают аутентификацию простой передачей пин кода.

Получить значения APDU команд любых смарт-карт и токенов можно путём перехвата трафика WinSCard.dll, запустив сниффер, скомпилированный отсюда (как показали эксперименты, этот сниффер устанавливается и запускается только под Win XP).

Справочно, возможные результаты выполнения APDU команд:
90 00 — OK
69 85 — Conditions of use not stisfied
63 00 — Authentication of host cryptogram failed (Ext auth)
64 00 — No specific diagnosis
67 00 — Wrong length in Lc
67 XX — Error, incorrect parameter P3 (ISO code)
68 81 — Logical channel not supported or is not active
69 82 — Security status not satisfied
69 83 — Secret code locked
69 85 — No currently selected EF, no command to monitor / no Transaction Manager File
6A 80 — The parameters in the data field are incorrect
6A 81 — Card is blocked or command not supported
6A 82 — File not found
6A 85 — Lc inconsistent with TLV structure
6A 86 — Incorrect P1 P2
6A 88 — Referenced data not found (Init upd)
6D 00 — Invalid instruction
6E 00 — Invalid class

Источник

Русские Блоги

Инструкция по использованию SIM-карты APDU

APDU может быть командой или ответом на команду.

Общий формат команды APDU: CLA INS P1 P1 P2 P3 P3 Data

Общий формат ответа на APDU: данные, SW1, SW1, SW2

INS: код команды каждой команды, определенной ниже.

SW1, SW2: успешен ли результат команды.

5 случаев инструкций

Случай 1: нет входа / нет выхода CLA INS P1 P2 P3 (lgth = 0x00) SW1 = 0x90 SW2 = 0x00

Случай 2: длина входного / выходного сигнала неизвестна CLA INS P1 P2 P3 (значение длины lgth) DATA (длина lgth) SW1 = 0x90 SW2 = 0x00

Случай 3: длина входного / выходного сигнала неизвестна CLA INS P1 P2 P3 (lgth = 0) SW1 = 0x9F SW2 = lgth1 ПОЛУЧИТЬ ОТВЕТ CLA INS INS P1 P2 P3 (lgth2) ДАННЫЕ (Lengthleth1

Интеллектуальная рекомендация

vs2015 + opencv3.3 + libfacedetectcnn распознавание лиц

Android Drawable основы (4)

PAT A1099 Построение двоичного дерева поиска (30 баллов)

A Binary Search Tree (BST) is recursively defined as a binary tree which has the following properties: The left subtree of a node contains only nodes with keys less than the node’s key. The righ.

Под Linux камера относится к архитектуре V4L2, и общее ядро ​​имеет связанные драйверы, и могут быть запрограммированы непосредственно в слое приложений без хорошего оборудования; Например / Dev / Vid.

django queryset values&values_list

возврат значенийСписок словаря; Возвращает список значенийСписок кортежей， values_list plus 1 Затем вернитесьСписок ценностей # _obj = <'netStates':HostInfo['NetStates'],'ip':HostInfo['i.

Источник

Работа с командами APDU на примере EToken

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

Запускаем APDUExplorer, выбираем в списке ридеров «Aladdin Token JC 0» или «ARDS JaCarta 0» или «SafeNet Token JC 0» и можно вводить команды.
Вводить можно как через двоеточия так и через пробелы или всё слитно.

Для начала можно проверить работоспособность, кликнув «Check ATR» и получить ответ токена.

Первая команда — выбор апплета по умолчанию и переход в корневую директорию с идентификатором 3f00 (этот идентификатор пожалуй единственное общее у токенов любых вендоров).
00:A4:00:04:00

Далее получаем список папок корневой директории
80:01:01:00:04:09:02:00:00:CD (команда является константой «Сообщить список папок»).
Должен быть получен ответ:
0a 02 66 66 0b 01 00 90 00

Второй по счёту байт в ответе размер полученных данных — два байта, то есть только одна папка (идентификатор файла или папки в APDU всегда занимает два байта).
И мы видим только одну папку с идентификатором 66 66, называемую Aladdin AID directory.

Сообщить список файлов (тоже константа)
80:01:02:00:04:09:02:00:00:CD
Должно быть получено
0a 00 0b 01 00 90 00
Ответ в позиции 01 — файлов 00.

Переходим в директорию 66 66
00 A4 08 04 02 66 66 00
Это команда SELECT FILE, её формат: четыре байта сама команда 00 A4 08 04, далее размер поля данных полного пути (в примере 02 байта), затем сам путь (в примере 66 66) и обязательно завершение 00.

Сообщить список папок директории 66 66
80:01:01:00:04:09:02:00:00:CD
Resv bytes:
0a 04 50 01 50 00 0b 01 00 90 00
В поле ответа 01 (размер ответа) указано 04, т.е. 4 байта = две папки 50 01 и 50 00, при этом 50 01 — служебная, а 50 00 основная, называемая PKCS#11 directory, где хранятся все данные

Сообщить список файлов директории 66 66
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 00 0b 01 00 90 00
Файлов здесь нет.

Как показали исследования видимых папок и файлов в директории 50 01 нет, поэтому переходим в основную директорию 50 00
00 A4 08 04 04 66 66 50 00 00
Сообщить список папок
80:01:01:00:04:09:02:00:00:CD
Ответ будет зависить от того что хранится на токене.
Сообщить список файлов
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 14 00 0f 00 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 0a 0b 01 00 90 00
Мы видим 14 файлов (поле ответа 01), далее каждые 2 байта это имена файлов, затем идёт служебная информация.

У каждого токена изучаемых моделей всегда пристутствует системная директория b000 и в ней системный файл 0002, попробуем его прочитать, по этому же принципу можно читать и другие файлы.
Переходим в директорию b0 00
00 A4 08 04 06 66 66 50 00 B0 00 00
Получаем список файлов
80:01:02:00:04:09:02:00:00:CD
Resv bytes:
0a 02 00 02 0b 01 00 90 00
Видим файл 00 02 (байт в поле ответа 01 — размер имени (каждое имя всегда занимает два байта, следующие поля — имена файлов, в данном случае файл только один, что определяем по значению поля 01).

Выбрать файл 0002 из B000 по полному пути
00 A4 08 04 08 66 66 50 00 B0 00 00 02 00
Resv bytes:
01 01 02 02 02 00 02 03 02 00 10 04 08 00 ff 00 00 ff ff ff ff 05 00 90 00
Формат ответа здесь следующий: преамбула — 2 байта, тип файла — 1 байт (02 файл, 01 папка), разделитель — 2 байта, имя файла — 2 байта, разделитель — 2 байта, размер файла — 2 байта, разделитель — 2 байта, права доступа — 1 байт (00 — доступен для всех, 63 защищён пин кодом). Далее идёт некая служебная информация, завершающаяся кодом успешного выполнения APDU команды — 90 00.

Прочитать этот файл, последние два байта команды размер буфера сколько надо прочитать (в данном случае равен размеру файла).
80 18 00 00 04 0E 02 00 00 10
Resv bytes: (значение в каждом случае будет своё):
00 06 63 61 72 64 63 66 00 00 00 00 00 00 00 00 90 00

Аутентификацию на етокене я здесь не рассматриваю, так как она состоит из последовательности команд вопрос-ответ и происходит в зашифрованном виде (существует проект Antitoken где проблему авторизации на этих изделиях решили кардинально).
Некоторые другие токены, например JaCarta ГОСТ-2 поддерживают аутентификацию простой передачей пин кода.

Получить значения APDU команд любых смарт-карт и токенов можно путём перехвата трафика WinSCard.dll, запустив сниффер, скомпилированный отсюда (как показали эксперименты, этот сниффер устанавливается и запускается только под Win XP).

Справочно, возможные результаты выполнения APDU команд:
90 00 — OK
69 85 — Conditions of use not stisfied
63 00 — Authentication of host cryptogram failed (Ext auth)
64 00 — No specific diagnosis
67 00 — Wrong length in Lc
67 XX — Error, incorrect parameter P3 (ISO code)
68 81 — Logical channel not supported or is not active
69 82 — Security status not satisfied
69 83 — Secret code locked
69 85 — No currently selected EF, no command to monitor / no Transaction Manager File
6A 80 — The parameters in the data field are incorrect
6A 81 — Card is blocked or command not supported
6A 82 — File not found
6A 85 — Lc inconsistent with TLV structure
6A 86 — Incorrect P1 P2
6A 88 — Referenced data not found (Init upd)
6D 00 — Invalid instruction
6E 00 — Invalid class

Источник