Javacard 애플릿 RPDU에는 seek-for-android에서 액세스 할 때 아무런 데이터도 포함되어 있지 않습니다.

Question

복잡한 Javacard 애플릿이 있으며 일반 스마트 카드 (예 : NXP J3E145, T = 1) 용으로 개발되고 테스트되었습니다. 이제는 UICC에서 휴대 전화로 사용하고 Android 앱에서 액세스해야합니다. UICC는 T = 0 프로토콜을 사용합니다.

일반 카드 판독기 (Omnikey 5321)에서 SIM 카드와 통신 할 때 애플릿이 정상적으로 작동합니다.

그러나 모바일 폰 (Sony Xperia S)으로 이동하고 seek-for-android API를 통해 APDU를 보내면 일부 RPDU에는 데이터 부분이 포함되지 않으며 상태 단어 0x9000과 데이터 부분 만 있습니다. 누락!

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 초입니다) 시간 제한 문제가 될 수 :

이 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를 확인입니까? 아니면 T = 0 이상한가?

내 안드로이드 응용 프로그램 코드는 정말 간단하다 :

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

오픈 모바일 API, 4.4.2 (19).

도움이 될 것입니다.이 문제를 해결하는 데 2 ​​일을 보냈습니다. 제발, 나를 구 해주십시오.

보이 타

편집 내 액세스 규칙 : 목록에서

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 My Issuer 보안 도메인은 A0000000871002FF33FFFF8901010100입니다.

나는

Answer 1

내 애플릿에 오류가있어서 전체적인 문제가 발생했습니다. 애플릿이 상태 워드 0x911C로 응답했고 데이터가 없습니다. 그러나 SEEK는 상태 단어 0x91XX가 SEEK를 통해 액세스 할 때 사용할 수 없기 때문에 항상 0x911C 대신 0x9000을 반환했습니다. 다음 단락은 SEEK 포럼의 EduardEtc이며 모든 것을 설명합니다.

"ETSI는 SIMToolKit (CAT) 응용 프로그램과 함께 사용하기위한 상태 단어 91XX를 정의합니다 (TS 102 221에서).그렇지 않으면 9000을 SW1SW2로 보내는 모든 카드 응용 프로그램은 91xx를 반환 할 수 있습니다. 대신 전화가 CAT APDU를 처리하도록 해석해야합니다. 따라서 전화 응용 프로그램은 91xx를 결코 보지 못할 것이며, 그것은 9000에 의해 전화의 CAT 취급 층으로 대체됩니다. ISO/IEC 7816-4는 유사한 목적으로 SW1SW2 = 61xx를 정의합니다. 그러나 이것이 ETSI의 요구를 충족시키기위한 표준에 포함 된 시점에서 ETSI는 ISO 프로세스가 완료되고 다른 인코딩을 지정할 때까지 기다리지 않았습니다. "

Answer 2

가장 큰 문제는 내가 생각 열기 논리 채널입니다 ... 이러한 규칙은 헤더와 마스크 실제 필터가없는, 내 APDU의 영향을 미칠 수 있다고 생각하지 않습니다. 카드가 논리 채널을 지원하지 않을 수 있습니다. Open Basic 채널을 사용해보십시오.

및 Le 부분이 설정되어 있지 않기 때문에 u에 응답 데이터가 없습니다. CL 필드, INS 필드, P1, P2, (Le), 데이터 .. Le 필드를 00으로 설정하면 총 백 바이트 응답을 사용할 수 있습니다. 다시 바이트 수를 보내면 XX라고 가정하고 넘겨 주면 응답을받을 수 있어야합니다. 256 이상이면 61 바이트, XX는 응답 바이트 수를 나타냅니다.