Почему карта отказывается от команды GPO?

Я работаю с бесконтактной тестовой картой Visa CDET. Я успешно выбрал приложение, которое дало мне следующий результат:

<= 6f 29 84 07 a0 00 00 00 03 10 10 a5 1e 50 0b 56 49 53 41 20 43 52 45 44 49 54 5f 2d 02 65 6e 9f 38 09 9f 66 04 9f 02 06 9f 37 04

Результат включал PDOL, в котором запрашивались следующие элементы:

Terminal Transaction Qualifiers
Length: 4 bytes

Authorised Amount
Length: 6 bytes

Unpredictable Number
Length: 4 bytes

Когда дело доходит до команды GPO, у меня есть все необходимые элементы, как показано ниже:

=> 80 a8 00 00 10 83 0e f3 20 40 00 00 00 00 00 12 00 bc 4b a2 3f 00

Но когда я запускаю команду, я получаю ошибку 67 00: Неверная длина Lc. В чем может быть проблема? Имейте в виду, что эта же программа отлично работает при работе с тестовыми карточками Visa CDET Contact из того же комплекта.

РЕДАКТИРОВАТЬ: О той же проблеме у меня есть тестовый ридер, который я использую для подтверждения своих показаний. Читатель и его программа могут получить параметры GPO и вернуть результат для других карт, но моя программа не дает мне никаких результатов, когда я пытаюсь ТОЧНО ту же команду, используя ТОЧНО ту же карту в моей пользовательской программе. Результатом является пробел, но слова состояния равны 90 00 (они отделены от возвращаемых данных). Это почему?


person Peter    schedule 04.03.2015    source источник
comment
Вы уверены, что TTQ, который вы отправляете для этой транзакции, верны/действительны для бесконтактной транзакции? См. Получение ошибки парсера при запросе команды GPO для карты EMV.   -  person Michael Roland    schedule 05.03.2015
comment
@MichaelRoland, пожалуйста, объясните подробнее об этом, поскольку те же карты, вызывающие вышеуказанные ошибки при использовании бесконтактного метода, не показывают такие ошибки при использовании метода контактной транзакции, оба теста выполняются с использованием одной и той же программы. Но я уверен, что мой TTQ подходит для мобильного POS-устройства.   -  person Peter    schedule 05.03.2015
comment
Я не знаком со спецификациями контактов, но для бесконтактных, байт 1 (F3) TTQ: бит 7 — это RFU, и ожидается, что он будет равен нулю в соответствии с текущей спецификацией CL Kernel 3. Бит 1 — это RFU, и ожидается, что он будет равен нулю в соответствии со спецификацией CL Kernel 3 в версии 2.1. Поэтому я бы посоветовал вам попробовать B2 или B3. Однако неправильный TTQ не объясняет, почему карта отвечает SW 67 00.   -  person Michael Roland    schedule 05.03.2015
comment
@MichaelRoland, вы случайно не знаете, какие условия могут привести к тому, что команда GPO не вернет результатов, но состояние состояния равно 90 00? Это когда нет вариантов PDOL для обработки   -  person Peter    schedule 06.03.2015


Ответы (2)


Просто предположим сначала, что карта правильная: если длина объекта данных 83 равна 0x0F (вместо 0x0E), если я правильно посчитал, то общая длина, которая должна быть указана в LC, должна быть 0x11 вместо 0x10 (тег и длина для быть добавленным). Это не объясняет, почему работает контактная версия, но, возможно, она еще будет работать после настройки.

person guidot    schedule 04.03.2015
comment
Ну 4+6+4=14=0x0E; 14 + 2 = 16 = 0x10. - person Michael Roland; 04.03.2015
comment
@MichaelRoland: Хотя ваши вычисления безупречны, 15 байтов следуют за байтом 0x0E: f3 20 40 00 / 00 00 00 00 / 12 00 bc 4b / a2 3f 00 - верно ли количество нулевых байтов в середине? - person guidot; 04.03.2015
comment
Верный. Последний байт — это байт Le (поскольку карта должна сообщать параметры обработки в ответ на команду GPO). - person Michael Roland; 04.03.2015
comment
@guidot, как сказал Майкл, последний байт для Le - person Peter; 05.03.2015

Я получил ошибку 67 00: Неверная длина Lc.

хорошо, потому что у вас нет Lc=0x00 в APDU, просто добавьте 0x00 в APDU

person Oleg Moiseenko    schedule 12.08.2018