Расширенные APDU и протоколы связи T = 0/1

У меня есть java-карта JCOP V2.4.2 R3, которая упоминается в ее техническом описании «Карта поддерживает протоколы связи T=1 и T=0»

У меня также есть устройство для чтения смарт-карт ACR38, которое поддерживает протоколы T = 0 и T = 1. (У меня успешно установлено соединение T = 0 с одной картой и соединение T = 1 с этой картой успешно.)

Я написал приведенную ниже программу и загрузил ее на карту для отправки и получения расширенных APDU:

package extAPDU;

import javacard.framework.APDU;
import javacard.framework.Applet;
import javacard.framework.ISOException;
import javacardx.apdu.ExtendedLength;

public class ExAPDU extends Applet implements ExtendedLength {

    private ExAPDU() {
    }


    public static void install(byte bArray[], short bOffset, byte bLength)
            throws ISOException {
        new ExAPDU().register();
    }

    public void process(APDU arg0) throws ISOException {
        short number = arg0.setIncomingAndReceive();
        arg0.setOutgoingAndSend((short)0, (short)(number+7));
    }

}

На стороне САПР я использовал скрипты Python для отправки различных APDU на карту. Вопросы следующие:

1- Почему я не могу начать обмен данными по протоколу T = 0 (хотя упоминается, что карта поддерживает этот протокол):

Скрипт на Python:

from smartcard.scard import *
import smartcard.util
from smartcard.System import readers
from smartcard.CardConnection import CardConnection

r=readers()
print r
connection =r[0].createConnection()
connection.connect(CardConnection.T0_protocol)

normalCommand=[0x00,0xa4,0x04,0x00,0x06,0x01,0x02,0x03,0x04,0x05,0x06]
data,sw1,sw2=connection.transmit(normalCommand)
print "SW for Normal Command:"
print data,hex(sw1),hex(sw2)

Выход:

>>> ================================ RESTART ================================
>>> 
['ACS CCID USB Reader 0']

Traceback (most recent call last):
  File "C:\extAPDU.py", line 13, in <module>
    connection.connect(CardConnection.T0_protocol)
  File "D:\PythonX\Lib\site-packages\smartcard\CardConnectionDecorator.py", line 54, in connect
    self.component.connect(protocol, mode, disposition)
  File "D:\PythonX\Lib\site-packages\smartcard\pcsc\PCSCCardConnection.py", line 118, in connect
    raise CardConnectionException('Unable to connect with protocol: ' + dictProtocol[pcscprotocol] + '. ' + SCardGetErrorMessage(hresult))
CardConnectionException: Unable to connect with protocol: T0. The requested protocols are incompatible with the protocol currently in use with the smart card. 
>>> 

2- Почему карта не работает нормально с командами Select APDU в расширенной форме по протоколу T = 1:

Скрипт на Python:

from smartcard.scard import *
import smartcard.util
from smartcard.CardConnection import CardConnection
from smartcard.System import readers

r=readers()
print r
connection =r[0].createConnection()
connection.connect(CardConnection.T1_protocol)

normalCommand=[0x00,0xa4,0x04,0x00,0x00,0x00,0x06,0x01,0x02,0x03,0x04,0x05,0x06]
data,sw1,sw2=connection.transmit(normalCommand)
print "SW for Normal Command:"
print data,hex(sw1),hex(sw2)

Выход :

>>> ================================ RESTART ================================
>>> 
['ACS CCID USB Reader 0']
SW for Normal Command:
[] 0x67 0x0
>>> 

Думаю, я неправильно понял эту концепцию и перепутал расширенные APDU с протоколами T=1 и T=0!

Может ли каждая T=1 совместимая смарт-карта отправлять и получать расширенные APDU? и мы не можем отправлять и получать расширенные APDU по T=0 протоколам? Если мы хотим отправлять расширенные команды SELECT APDU в домен безопасности, SD должен реализовывать ExtendedLength интерфейс?

Каковы требования для передачи расширенного APDU?

  1. Картридер, совместимый с A T = 1
  2. Смарт-карта, совместимая с T = 1
  3. Апплет, реализующий ExtendedLength интерфейс

Это правильно?

Меня действительно смущает расширенная совместимость и T=0/1 совместимость смарт-карт. Любой свет будет оценен по достоинству.

Обратите внимание, что я могу успешно отправить расширенные APDU в указанный выше апплет с протоколом T=1!


person Jean    schedule 04.03.2015    source источник


Ответы (3)


Q1: изменение протокола возможно. Информация о том, какие протоколы поддерживаются картой, передается через ATR / ATS. Затем терминал может решить, какой из них использовать. Таким образом, это зависит от вашей оболочки терминала, выбираются ли протоколы или нет. Для оболочки JCOP это /change-protocol. Однако в целом не рекомендуется T = 0.

Q2: Если вы запускаете карту, отправляя ATR / ATS, активируется диспетчер карт, который поддерживает только команды глобальной платформы. Global Platform не поддерживает расширенную длину. Отправляя команду Select (которая из-за этого должна быть простой длины), апплет выбирается, и эти фактические команды Select также перенаправляются в метод process() вашего апплета (и могут быть обнаружены методом selectingApplet()). Теперь, когда вы находитесь в своем апплете, вы можете отправлять столько команд с расширенной длиной, сколько хотите. Вы можете обойти начальный вариант Non-Extended-Length-Select, установив апплет по умолчанию.

person Paul Bastian    schedule 05.03.2015
comment
И почему он не может начать общение по протоколу T = 0? Могу я попросить взглянуть и на последний комментарий под другим ответом? - person Ebrahim Ghasemi; 06.03.2015
comment
Предоставление возможности выбора протокола связи в библиотеке PySCard не означает, что протоколы можно выбирать? (Я имею в виду: connection.connect(CardConnection.T1_protocol) или connection.connect(CardConnection.T0_protocol))? Неудача при запуске с T0, связана с картридером? (ACR38) - person Ebrahim Ghasemi; 06.03.2015
comment
И последний вопрос: должен ли производитель явно указывать в даташите совместимость с увеличенной длиной? или пользователь может сделать вывод о совместимости или несовместимости на основе версии платформы Java Card и совместимости T-1/0? Другими словами: возможно ли, чтобы карта была совместима с платформой Java Card 3, но не поддерживала передачу APDU с расширенной длиной? Или возможно ли быть совместимым с T = 1, но не поддерживать увеличенную длину? Или возможно быть совместимым с платформой Java Card 3 и T = 1, но не поддерживать расширенную длину? Какая связь между этими параметрами :) - person Ebrahim Ghasemi; 06.03.2015
comment
ну, в документации производителя указано, поддерживается ли Extended Length или нет. Для JCOP 242R3 я совершенно уверен, что ExtLength поддерживается. Я не знаю PySCard и не работал с ACR38 (по слухам, это дерьмо). Это может быть проблема с драйвером. Мы хотим запустить протокол T = 0? - person Paul Bastian; 06.03.2015
comment
Хочу быть уверенным, что если где-то был T = 1 несовместимый ридер, моя карта будет нормально работать в T = 0. Так что предложите, пожалуйста, какую-нибудь хорошую читалку (как контактную, так и бесконтактную). И признателен, если вы добавите в свой ответ связь между совместимостью T = 0/1 и совместимостью ExtendedLength (вопросы, которые я задал в предыдущем комментарии). Действительно, спасибо :) - person Ebrahim Ghasemi; 06.03.2015
comment
Вы должны прочитать руководства JCOP, я не использовал ExtLength с T = 0, поэтому я не могу посоветовать никому из читателей и не думаю, что ТАК любит брендинг (может быть много). Также прочтите все подробности о случаях T = 0 в JC Spec (есть о чем позаботиться) - person Paul Bastian; 06.03.2015
comment
Мой вопрос касается не только JCOP. Это общий вопрос для всех карт. Я не могу понять отношения между этими параметрами (ни в коем случае!) Кстати, спасибо. :) - person Ebrahim Ghasemi; 06.03.2015
comment
Что ж, ExtendedLength - это просто дополнительная функция, поэтому вы не можете делать никаких заявлений в целом. В общем, я бы сказал, что существует множество спецификаций, и в основном все является необязательным, и, в конце концов, разработчики аппаратного / программного обеспечения решают, что они поддерживают. Итак, вам нужно определить некоторые части вашей системы и прочитать документы разработчика. Я больше не могу об этом сказать: P - person Paul Bastian; 06.03.2015
comment
Ничего о связи между T = 1/0 и совместимостью ExtendedLength? : D - person Ebrahim Ghasemi; 06.03.2015
comment
Я просто не знаю ни одного - person Paul Bastian; 06.03.2015

Дело не в том, что каждая ISO-совместимая карта может отправлять и получать расширенные APDU. Это дополнительная функция. Какую версию JCOP поддерживает ваша карта?

Что касается T = 0 против T = 1: когда карта указывает на поддержку обоих протоколов, именно устройство чтения карт решает, какой из них использовать. Если это кард-ридер PC / SC, с этим ничего не поделаешь.

Обновлено для добавления: теперь вы говорите, что можете успешно отправлять расширенные APDU в указанный выше апплет. Получается, что карта поддерживает расширенные APDU. Но, возможно, встроенная команда SELECT не разрешает их, если Le отсутствует, потому что для них нет варианта использования.

person TonyK    schedule 04.03.2015
comment
Обновляю вопрос. Это карта JCOP V2.4.2 R3. а мой считыватель - ACR38, который поддерживает оба протокола. Таким образом, и кард-ридер, и кард-ридер поддерживают T = 0. Так почему я не могу начать общение по протоколу T = 0? - person Jean; 04.03.2015
comment
@ Am1r: Итак, считыватель ACR38 видит, что карта поддерживает оба протокола, и решает для себя использовать T = 1. С этим мало что можно поделать. - person TonyK; 04.03.2015
comment
Кто выбирает протокол передачи? Программист или читатель ?! - person Jean; 04.03.2015
comment
@ Am1r: Ха! Добро пожаловать в мир PC / SC. Все ваши смарт-карты принадлежат нам. - person TonyK; 04.03.2015
comment
: D почему в библиотеку pyscard добавляют возможность выбора протокола? Не могли бы вы добавить больше деталей? Я запуталась в этом понятии! - person Jean; 04.03.2015
comment
Каковы требования для передачи расширенного APDU и как выбрать протокол? - person Jean; 04.03.2015
comment
почему в библиотеку pyscard добавляют возможность выбора протокола? Поскольку спецификация была написана Microsoft. - person TonyK; 04.03.2015
comment
Позвольте нам продолжить это обсуждение в чате. - person Jean; 04.03.2015
comment
Каковы требования для передачи расширенного APDU и как выбрать протокол? Вы не обязаны. То, что вы сделали, мне кажется правильным. Но команда SELECT в карте почему-то отклонила его. Просто будьте благодарны за то, что ваш апплет может обрабатывать расширенные APDU! - person TonyK; 04.03.2015
comment
Есть ли какая-либо связь между совместимостью расширенных APDU и протоколами T = 0/1? - person Jean; 04.03.2015
comment
В принципе нет. Но это сложнее реализовать в протоколе T = 0, поэтому некоторые карты могут поддерживать его только в протоколе T = 1. - person TonyK; 04.03.2015
comment
Сложнее для программиста или производителя карт? : D - person Jean; 04.03.2015
comment
Сложнее разработчикам ОС JCOP (они тоже программисты!) - person TonyK; 04.03.2015
comment
@TonyK Означает ли это, что все карты платформы Java Card 3 поддерживают extendedLength передачу APDI? (Насколько я понимаю, вы сказали, что нет никакой связи между протоколом передачи и extendedLength совместимостью. Итак, если прикладной программист реализует интерфейс extendedLength, его / ее карта сможет отправлять расширенные APDUs. Верно?) - person Ebrahim Ghasemi; 06.03.2015
comment
Другими словами, следует ли упоминать в таблице данных карты, что карта явно поддерживает расширенный APDU? Или достаточно упомянуть, что карта представляет собой платформу Java Card 3, или карту, поддерживающую T = 1, или что-то еще ..., и на основании этого конечный пользователь может сделать вывод, что его карта совместима с APDU увеличенной длины? - person Ebrahim Ghasemi; 06.03.2015
comment
@Abraham: Я предлагаю вам спросить Пола Бастиана. Судя по его ответу, он знает о JCOP гораздо больше, чем я! - person TonyK; 06.03.2015
comment
Все карты jcop с jc3, которые я видел, поддерживают ExtLength. Я не знаю, подразумевается ли это (спросите NXP и сообщите здесь, пожалуйста). Вам следует запросить подробную информацию о продукте или попросить продавца убедиться в этом. Однако в руководстве, которое я получил для своих карт JCOP242R3, говорится, что поддерживается расширенная длина (все еще не давая никаких обещаний здесь). - person Paul Bastian; 06.03.2015
comment
По всем этим вопросам вы видите, что лучше всего прочитать Руководство пользователя JCOP - person Paul Bastian; 06.03.2015

Сама карта Java Card уже обрабатывает специфические команды T = 0, поэтому APDU T = 0 / T = 1 будет выглядеть для программиста примерно так же. Конечно, есть различия, но они довольно хорошо объяснены в классе APDU.

T = 0 - это протокол на основе байтов, тогда как T = 1 использует нижние кадры. Большинство карт с T = 0 не поддерживают увеличенную длину. Обратите внимание, что для получения функциональных возможностей расширенной длины необходимо реализовать интерфейс тегов javacardx.apdu.ExtendedLength.

Карты JCOP можно настроить для использования T = 0 / T = 1 / T = CL и других. Однако вам необходимо иметь доступ к карте (и, возможно, к руководству пользователя) для настройки карт. API Java Card не содержит команд для изменения поддержки протоколов или параметров транспортного протокола в холодном или теплом ATR.

Вы правы в отношении требований к увеличенной длине. Обратите внимание, что картридеры, не поддерживающие T = 1, вероятно, сейчас будет трудно найти. T = 0 - старый протокол, предпочтительнее T = 1.

person Maarten Bodewes    schedule 08.03.2015
comment
Спасибо, дорогой Мартен. Вы хоть представляете, почему я не могу выбрать свой апплет с обычными APDU и протоколом T = 0 (т.е. с первой программой на Python), в то время как я почти уверен, что карта поддерживает протокол связи T = 0? - person Jean; 08.03.2015
comment
Похоже, карта настроена только на T = 1. Вы можете попробовать отобразить ATR карты. Если он настроен правильно, он должен отображать, какие протоколы поддерживаются, если я правильно помню. - person Maarten Bodewes; 08.03.2015
comment
Я разобрал ATR, и думаю, вы правы. (smartcard-atr.appspot.com/) - person Jean; 09.03.2015
comment
кстати, вы работали с CardTool? (Инструмент, предназначенный для компании ACS и предназначенный для считывателя ACR38) - person Jean; 09.03.2015
comment
Нет, из всех читателей я лично не сталкивался с этим (что немного удивительно, учитывая количество читателей, которые в тот или иной день оказывались на моем столе) - person Maarten Bodewes; 09.03.2015