Javacard applet RPDU не содержит никаких данных при доступе от seek-for-android

У меня есть сложный апплет Javacard, который разработан и протестирован для обычной смарт-карты (например, NXP J3E145, T = 1). Теперь я должен использовать его в UICC на мобильном телефоне и получить доступ к нему из своего приложения для Android. UICC использует протокол T = 0.

Когда я общаюсь с SIM-картой у обычного кард-ридера (Omnikey 5321), апплет работает нормально.

Однако, когда я переношу его на свой мобильный телефон (Sony Xperia S) и отправляю APDU через API поиска для android, некоторые RPDU не содержат какой-либо части данных, есть только слово состояния 0x9000, а часть данных отсутствует!

Эти APDU не работают:

80 04 00 00 00 --> 90 00 (although there should be some data, 200 bytes approx.) 80 01 00 00 00 --> 90 00 (although I expect 18 bytes) 

Эти APDU в порядке:

 80 05 00 00 00 --> 00 90 00 (one byte as I expected) 80 06 00 00 00 --> <... data of length 20 ...> 90 00 (as I expected) 

Может ли это быть проблемой тайм-аута (время обработки всегда <1 с)? Или какая-то Т = 0 странность?

Мой Android-код приложения очень прост:

 Channel channel = session.openLogicalChannel(aid); byte[] resp = channel.transmit(new byte[] {(byte) 0x80, 0x04, 0x00, 0x00, 0x00}); 

Open Mobile API, 4.4.2 (19).

Любая помощь будет приятной, я потратил два дня на решение этой проблемы. Пожалуйста спаси меня.

Войта

EDIT Мои правила доступа:

 AID: A000000018308005006563686F00 ___ AllApps:Never AID: A0000000183080055A6563686F5A ___ Hash:ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always AID: A000000018308005596563686F59 ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always AID: A000000018308005586563686F58 ___ AllApps:Always AID: NO_AID ___ AllApps:Always AID: A000000018308005006563686F00 ___ AllApps:Never AID: A0000000183080055A6563686F5A ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always AID: A000000018308005596563686F59 ___ Hash: ABFF7159B0530044CD71C6561B0F9D55CBAE8984:Always AID: A000000018308005586563686F58 ___ AllApps:Always AID: NO_AID ___ AllApps:Always 

В приведенном выше списке я только фильтровал правила APDU (и правила NFC вообще не записывались).

У моего апплета есть AID F06D617073616D2E617070. Мой домен безопасности для электронной почты – A0000000871002FF33FFFF8901010100.

Я не думаю, что эти правила могут повлиять на мои APDU, нет реальных фильтров с заголовком и маской …

Я обнаружил ошибку в своем апплете, что действительно вызвало всю проблему. Мой апплет ответил словом состояния 0x911C и никаких данных. Однако SEEK всегда возвращал 0x9000 вместо 0x911C, потому что слова состояния 0x91XX не могут использоваться при доступе через SEEK. Следующий абзац от EduardEtc с форума SEEK, и он объясняет все:

«ETSI определяет (в TS 102 221) статусное слово 91XX для использования с приложениями SIMToolKit (CAT). Любое приложение карты, которое в противном случае отправило бы 9000 в качестве SW1SW2, могло бы вернуть 91xx вместо этого, которое телефон должен интерпретировать для обработки CAT APDU. Никогда не см. 91xx, он заменяется слоем обработки CAT на 9000. ISO / IEC 7816-4 определяет SW1SW2 = 61xx для аналогичной цели. Однако в то время, когда это включено в стандарт для удовлетворения потребностей ETSI, ETSI Не дождался завершения процесса ISO и указал другую кодировку ».

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

И u не получают никаких данных ответа, потому что часть Le не установлена. CLA, INS, P1, P2, (Le), Data. Если вы устанавливаете свое поле Le на 00, вы должны получить полный ответ в виде общего количества доступных байтов. Опять же, если вы отправите количество байтов, которое вам нужно, предположите XX, тогда передайте его, и вы сможете получить этот ответ, если его больше 256, тогда будет 61 XX, XX – количество байтов ответа.