El applet de Javacard RPDU no contiene ningún dato cuando se accede desde seek-for-android

Tengo un applet complejo de Javacard, que se desarrolla y prueba para la tarjeta inteligente ordinaria (eg NXP J3E145, T = 1). Ahora tengo que usarlo en UICC en un teléfono móvil y acceder desde mi aplicación Android. La UICC utiliza el protocolo T = 0.

Cuando me comunico a la tarjeta SIM de un lector de tarjetas ordinario (Omnikey 5321), el applet funciona bien.

Sin embargo, cuando lo muevo en mi teléfono móvil (Sony Xperia S) y enviar APDUs a través de buscar para la API de Android, algunas RPDUs no contienen ninguna parte de datos, sólo hay la palabra de estado 0x9000 y la parte de datos falta!

Estas APDU están fallando:

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) 

Estas APDU están bien:

 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) 

¿Podría ser un problema de tiempo de espera (el tiempo de procesamiento es siempre <1s)? ¿O alguna rareza T = 0?

Mi código de aplicación para Android es realmente sencillo:

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

Abra Mobile API, 4.4.2 (19).

Cualquier ayuda sería agradable, pasé dos días resolviendo este problema. Por favor salvame.

Vojta

EDITAR Mis reglas de acceso:

 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 

En la lista anterior he filtrado reglas de APDU solamente (y las reglas de NFC no anotaron en absoluto).

Mi applet tiene AYUDA F06D617073616D2E617070 Mi dominio de seguridad del emisor es A0000000871002FF33FFFF8901010100.

No creo que estas reglas puedan afectar a mi APDUs, no hay filtros reales con encabezado y máscara …

Encontré un error en mi applet, que realmente causó todo el problema. Mi applet respondió con la palabra de estado 0x911C y sin datos. Sin embargo, SEEK devolvió siempre 0x9000 en vez de 0x911C, porque las palabras de estado 0x91XX no se pueden utilizar cuando se accede a través de SEEK. El siguiente párrafo es de EduardEtc del foro SEEK y lo explica todo:

"ETSI define (en el TS 102 221) la palabra de estado 91XX para el uso con las aplicaciones de SIMToolKit (CAT) Cualquier aplicación de la tarjeta que de otra manera enviaría 9000 como SW1SW2 puede devolver 91xx en lugar de lo cual el teléfono debe interpretar para manejar CAT APDU. Nunca ver el 91xx, es reemplazado por la capa de manipulación de CAT del teléfono por 9000. ISO / CEI 7816-4 define SW1SW2 = 61xx para un propósito similar.En el momento que esto incluido en el estándar para satisfacer una necesidad de ETSI, sin embargo, ETSI No esperó a que el proceso ISO finalice y especificó una codificación diferente. "

El problema principal es con el canal lógico abierto supongo. Puede ser la tarjeta no es compatible con el canal lógico. Pruebe el canal de Open Basic.

Y u no están recibiendo ningún dato de respuesta porque, la parte Le no está configurada. CLA, INS, P1, P2, (Le), Data ..Si está configurando su campo Le a 00 debe obtener respuesta de respuesta completa como el número total de bytes disponibles. De nuevo si envías el número de bytes que necesitas, supongamos que XX lo pasa y deberías ser capaz de obtener esa respuesta, si es más de 256 entonces será 61 XX, XX indicando el número de bytes de respuesta.

FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.