Un gran número de dispositivos con Android que ofrecen la función NFC ya admiten la emulación de tarjetas NFC. En la mayoría de los casos, el dispositivo tiene un chip separado llamado Elemento seguro que emula la tarjeta. Muchas de las tarjetas SIM que brindan los proveedores de servicios inalámbricos también contienen un Elemento seguro.
Android 4.4 introduce un método adicional para emular tarjetas que no necesita un Elemento seguro y se llama emulación de tarjetas basada en el host. Esto permite que cualquier aplicación para Android emule una tarjeta y se comunique directamente con el lector de NFC. En este documento, se describe cómo funciona la emulación de tarjetas basada en el host (HCE) en Android y cómo usar esta técnica para desarrollar una app que emule una tarjeta NFC.
Emulación de tarjetas con un Elemento seguro
Cuando la emulación de tarjetas NFC se realiza a través de un Elemento seguro, los datos de la tarjeta que se emulará se almacenan en el Elemento seguro del dispositivo mediante una aplicación para Android. Luego, cuando el usuario acerca el dispositivo a una terminal NFC, el controlador de NFC del dispositivo enruta todos los datos del lector directamente al Elemento seguro. En la figura 1, se ilustra el concepto.
Figura 1: Emulación de tarjeta NFC con un Elemento seguro
El Elemento seguro se comunica con la terminal NFC sin que intervenga ninguna aplicación para Android en la transacción. Una vez completada la transacción, la app puede enviar una consulta directamente al Elemento seguro para conocer el estado de la transacción y comunicárselo al usuario.
Emulación de tarjetas basada en el host
Cuando se emula una tarjeta NFC mediante la emulación basada en el host, los datos se enrutan de forma directa a la CPU del host en la que se ejecutan las aplicaciones para Android; no se enrutan las tramas del protocolo NFC al Elemento seguro. En la figura 2, se ilustra cómo funciona la emulación de tarjetas basada en el host.
Figura 2: Emulación de tarjeta NFC sin un Elemento seguro
Tarjetas y protocolos NFC compatibles
Figura 3: Pila de protocolos HCE de Android
Los estándares de NFC ofrecen compatibilidad con muchos protocolos diferentes, y se pueden emular varios tipos de tarjetas.
Android 4.4 admite diversos protocolos que son comunes en el mercado actual. Muchas tarjetas que usan la tecnología sin contacto ya se basan en estos protocolos, como las tarjetas de pago sin contacto. Los protocolos también son compatibles con diferentes lectores de NFC del mercado actual, incluidos los dispositivos con NFC de Android que funcionan como lectores (consulta la clase IsoDep).
De esa forma, puedes crear e implementar una solución NFC de principio a fin en torno a HCE utilizando solo dispositivos con Android.
En particular, Android 4.4 admite la emulación de tarjetas que se basan en la especificación ISO-DEP de NFC Forum (basada en ISO/IEC 14443-4) y procesar unidades de datos de protocolo de aplicación (APDU) definidas en la especificación ISO/IEC 7816-4. Android exige la emulación de ISO-DEP solo por encima de la tecnología Nfc-A (ISO/IEC 14443-3 tipo A). La compatibilidad con la tecnología Nfc-B (ISO/IEC 14443-4 tipo B) es opcional. La superposición de todas estas especificaciones se muestra en la figura 3.
Servicios de HCE
La arquitectura HCE en Android está basada en los componentes Service de Android (conocidos como "servicios de HCE").
Una de las principales ventajas de un servicio es que se puede ejecutar en segundo plano sin una interfaz de usuario. Este es un comportamiento natural para muchas aplicaciones de HCE, como las de tarjetas de transporte público o de lealtad. En esos casos, el usuario no debería abrir la app para usarla.
En su lugar, cuando toca el lector de NFC con el dispositivo, el servicio correcto se inicia (si no estaba activo) y ejecuta la transacción en segundo plano. Por supuesto, puede iniciar IU adicionales (como notificaciones para el usuario) desde su servicio si lo cree apropiado.
Selección de servicios
Cuando el usuario toca un lector de NFC con el dispositivo, el sistema Android necesita saber con qué servicio de HCE desea comunicarse el lector de NFC. Aquí es donde entra en juego la especificación ISO/IEC 7816-4, que define una forma de seleccionar aplicaciones centrada en un ID de aplicación (AID). Un AID consta de hasta 16 bytes. Si estás emulando tarjetas para una infraestructura de lector de NFC ya existente, los AID que buscan esos lectores, a menudo, son conocidos y están registrados de manera pública (por ejemplo, los AID de redes de pagos como Visa y MasterCard).
Si quieres implementar una nueva infraestructura de lector para tu aplicación, deberás registrar AID propios. El procedimiento de registro de los AID se define en la especificación ISO/IEC 7816-5. Google recomienda registrar un AID según 7816-5 si vas a implementar una aplicación de HCE para Android, ya que evitará las colisiones con otras apps.
Grupos de AID
A veces, es posible que un servicio de HCE deba registrar varios AID para implementar una aplicación específica. Si es así, necesita asegurarse de ser el controlador predeterminado de todos estos AID (a diferencia de algunos AID del grupo que están destinados a otro servicio).
Un grupo de AID es una lista de AID que el SO debe identificar como conjunto. Android garantiza una de las siguientes opciones a todos los AID de un grupo:
- Todos los AID del grupo se enrutan a este servicio de HCE.
- No se enruta ningún AID del grupo a este servicio de HCE (por ejemplo, porque el usuario prefirió otro servicio que también solicitó uno o más AID de tu grupo).
En otras palabras, no existe un estado intermedio en el que los AID del grupo se puedan distribuir a diferentes servicios de HCE.
Grupos y categorías de AID
Cada grupo de AID puede asociarse con una categoría. Esto permite que Android agrupe los servicios de HCE por categoría y, por consiguiente, que el usuario establezca valores predeterminados en el nivel de categoría en lugar de en el nivel del AID. En general, evita mencionar los AID en cualquier sector de tu aplicación que vea el usuario promedio, ya que no representan nada para ellos.
Android 4.4 admite dos categorías: CATEGORY_PAYMENT (que cubre las apps de pagos estándares de la industria) y CATEGORY_OTHER (para todas las demás apps de HCE).
Nota: Solo se puede habilitar un grupo de AID de la categoría CATEGORY_PAYMENT por vez en el sistema. Por lo general, se tratará de una app que comprenda los principales protocolos de pagos con tarjeta de crédito y que pueda funcionar con cualquier comercio.
Para las apps de pagos de bucle cerrado que solo funcionan en un comercio (como las tarjetas de valor almacenado), debes usar CATEGORY_OTHER. Los grupos de AID de esta categoría pueden estar siempre activos y, si es necesario, obtener la prioridad de los lectores de NFC durante la selección de AID.
Cómo implementar un servicio de HCE
Para emular una tarjeta NFC mediante la emulación de tarjetas basada en host, debes crear un componente Service que maneje las transacciones con NFC.
Cómo comprobar la compatibilidad con HCE
Tu aplicación puede verificar si un dispositivo es compatible con HCE si comprueba la función FEATURE_NFC_HOST_CARD_EMULATION. Debes usar la etiqueta <uses-feature> en el manifiesto de la aplicación para declarar que usa la función HCE y si la necesita o no para funcionar.
Implementación del servicio
Android 4.4 incluye una clase Service de conveniencia que se puede usar como base para implementar un servicio de HCE: la clase HostApduService.
Por lo tanto, el primer paso es extender HostApduService.
Kotlin
class MyHostApduService : HostApduService() {
override fun processCommandApdu(commandApdu: ByteArray, extras: Bundle?): ByteArray {
...
}
override fun onDeactivated(reason: Int) {
...
}
}
Java
public class MyHostApduService extends HostApduService {
@Override
public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
...
}
@Override
public void onDeactivated(int reason) {
...
}
}
HostApduService declara dos métodos abstractos que se deben anular e implementar.
Se llama a processCommandApdu() cada vez que un lector de NFC envía una unidad de datos del protocolo de aplicación (APDU) a tu servicio. Las APDU también se definen en la especificación ISO/IEC 7816-4. Son los paquetes de nivel de aplicación que se intercambian entre el lector de NFC y tu servicio de HCE. Ese protocolo de nivel de aplicación es de dúplex medio: el lector de NFC te enviará una APDU de comando y esperará a que envíes una APDU de respuesta.
Nota: La especificación ISO/IEC 7816-4 también define el concepto de múltiples canales lógicos, en los que puedes tener múltiples intercambios de APDU paralelos en canales lógicos separados. Sin embargo, la implementación de HCE de Android admite un canal lógico único, por lo que solo se realiza un intercambio de APDU de un subproceso.
Como ya se mencionó, Android usa el AID para determinar con qué servicio de HCE se quiere comunicar el lector. Por lo general, la primera APDU que envía un lector de NFC a tu dispositivo es una APDU de comando "SELECT AID". Esta APDU contiene el AID con el que el lector se quiere comunicar. Android extrae ese AID de la APDU, lo resuelve en un servicio de HCE y luego reenvía esa APDU al servicio resuelto.
Puedes enviar una APDU de respuesta si muestras los bytes de la APDU de respuesta de processCommandApdu().
Ten en cuenta que se llamará a este método en el subproceso principal de tu aplicación, que no debe bloquearse. Entonces, si no puedes calcular y mostrar una APDU de respuesta de inmediato, muestra un valor nulo. Luego, puedes realizar el trabajo necesario en otro subproceso y usar el método sendResponseApdu() definido en la clase HostApduService para enviar la respuesta cuando hayas terminado.
Android seguirá reenviando nuevas APDU del lector a tu servicio hasta que se dé una de estas dos situaciones:
- El lector de NFC envía otra APDU "SELECT AID", que el SO resuelve en un servicio diferente.
- Deja de funcionar el vínculo de NFC entre el lector de NFC y tu dispositivo.
En ambos casos, se llama a la implementación de onDeactivated() de tu clase con un argumento en el que se indica qué sucedió.
Si estás trabajando con una infraestructura de lector existente, debes implementar el protocolo de nivel de aplicación que esperan los lectores en tu servicio de HCE.
Si vas a implementar una nueva infraestructura de lector que también controlas, puedes definir un protocolo y una secuencia de APDU propios. En general, intenta limitar la cantidad de APDU y el tamaño de los datos que deben intercambiarse. De ese modo, te asegurarás de que los usuarios solo tengan que mantener su dispositivo sobre el lector de NFC durante poco tiempo. Un límite superior razonable es de aproximadamente 1 KB de datos, una cantidad que, en general, se puede cambiar en 300 ms.
Declaración del servicio en el manifiesto y registro del AID
El manifiesto de tu servicio se declara como de costumbre, pero debes agregar algunos puntos a la declaración.
Primero, para indicarle a la plataforma que es un servicio de HCE que implementa una interfaz HostApduService, la declaración del servicio debe contener un filtro de intents para la acción SERVICE_INTERFACE.
Además, para indicarle a la plataforma qué grupos de AID solicita este servicio, se debe incluir una etiqueta SERVICE_META_DATA <meta-data> en la declaración del servicio que dirija a un recurso XML con información adicional sobre el servicio de HCE.
Por último, debes configurar el atributo android:exported como verdadero y solicitar el permiso "android.permission.BIND_NFC_SERVICE" en la declaración del servicio.
El primero garantiza que las aplicaciones externas puedan vincularse al servicio.
El segundo exige que solo las aplicaciones externas que tienen el permiso "android.permission.BIND_NFC_SERVICE" puedan vincularse. Dado que "android.permission.BIND_NFC_SERVICE" es un permiso del sistema, exige que solo el SO Android pueda vincularse a tu servicio.
A continuación, verás un ejemplo de una declaración HostApduService del manifiesto:
<service android:name=".MyHostApduService" android:exported="true"
android:permission="android.permission.BIND_NFC_SERVICE">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
</intent-filter>
<meta-data android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/apduservice"/>
</service>
Esta etiqueta de metadatos dirige a un archivo apduservice.xml. A continuación, se muestra un ejemplo de un archivo con una declaración de un solo grupo de AID que contiene dos AID de propiedad:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc"
android:requireDeviceUnlock="false">
<aid-group android:description="@string/aiddescription"
android:category="other">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</host-apdu-service>
La etiqueta <host-apdu-service> debe contener un atributo <android:description> que incluya una descripción del servicio que sea sencilla y pueda mostrarse en la IU. El atributo requireDeviceUnlock se puede usar para especificar que el dispositivo debe desbloquearse antes de que se pueda invocar el servicio para manejar APDU.
El <host-apdu-service> debe contener una o más etiquetas <aid-group>. Cada etiqueta <aid-group> debe cumplir con lo siguiente:
- Debe incluir un atributo
android:descriptionque contenga una descripción del grupo de AID sencilla y adecuada para mostrarse en la IU. - Debe tener su atributo
android:categoryestablecido para indicar la categoría a la que pertenece el grupo de AID; p. ej., las constantes de strings definidas porCATEGORY_PAYMENToCATEGORY_OTHER. - Cada
<aid-group>debe incluir una o más etiquetas<aid-filter>, y cada una de ellas contiene un AID único. El AID debe especificarse en formato hexadecimal y contener un número par de caracteres.
Por último, tu aplicación también debe tener el permiso NFC para poder registrarse como servicio de HCE.
Resolución de conflictos de AID
Se pueden instalar múltiples componentes HostApduService en un solo dispositivo y varios servicios pueden registrar el mismo AID. La plataforma de Android resuelve conflictos de AID en función de la categoría a la que pertenecen los AID. Cada categoría puede tener una política de resolución de conflictos diferente.
Por ejemplo, para algunas categorías (como los pagos), el usuario puede seleccionar un servicio predeterminado en la IU de la configuración de Android. Para otras, la política puede ser siempre preguntar al usuario qué servicio se debe invocar en caso de conflicto. Si quieres averiguar la política de resolución de conflictos de una categoría determinada, consulta la información sobre getSelectionModeForCategory().
Comprueba si tu servicio es el predeterminado
Las aplicaciones pueden verificar si tu servicio de HCE es el predeterminado para una categoría específica si usan la API de isDefaultServiceForCategory(ComponentName, String).
Si tu servicio no es el predeterminado, puedes solicitar que lo sea.
Consulta ACTION_CHANGE_DEFAULT.
Aplicaciones de pagos
Android considera como aplicaciones de pagos a los servicios de HCE que declararon un grupo de AID con la categoría "pago". La versión 4.4 de Android contiene una entrada de menú de Configuración de nivel superior, llamada "Toca y paga", que enumera todas esas aplicaciones de pagos. En este menú de configuración, el usuario puede seleccionar la aplicación de pagos predeterminada que se invocará cuando se presione una terminal de pago.
Elementos requeridos para aplicaciones de pagos
A fin de ofrecer una experiencia del usuario más atractiva visualmente, las aplicaciones de pagos con HCE deben proporcionar un elemento adicional para su servicio: un banner de servicio.
El elemento debe medir 260 x 96 dp y se puede especificar en el archivo de metadatos XML si agregas el atributo android:apduServiceBanner a la etiqueta <host-apdu-service>, que dirige al elemento de diseño. A continuación, se muestra un ejemplo:
<host-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc"
android:requireDeviceUnlock="false"
android:apduServiceBanner="@drawable/my_banner">
<aid-group android:description="@string/aiddescription"
android:category="payment">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</host-apdu-service>
Pantalla apagada y comportamiento de pantalla de bloqueo
Las implementaciones actuales de Android desactivan completamente el controlador de NFC y el procesador de la aplicación cuando la pantalla del dispositivo está apagada. Por lo tanto, los servicios de HCE no funcionarán cuando la pantalla esté apagada.
Sin embargo, los servicios de HCE pueden funcionar desde la pantalla de bloqueo: se controla mediante el atributo android:requireDeviceUnlock de la etiqueta <host-apdu-service> de tu servicio de HCE. De forma predeterminada, no será obligatorio desbloquear la pantalla y se invocará el servicio aun cuando el dispositivo esté bloqueado.
Si configuras el atributo android:requireDeviceUnlock como verdadero para tu servicio de HCE, Android solicitará al usuario que desbloquee el dispositivo cuando toque un lector de NFC que seleccione un AID resuelto en tu servicio. Después de desbloquear el dispositivo, Android mostrará un diálogo para pedirle al usuario que vuelva a presionar a fin de completar la transacción. Esto es necesario porque el usuario puede haber movido el dispositivo fuera del lector de NFC para desbloquearlo.
Coexistencia con tarjetas que tienen Elemento seguro
Esta sección está orientada a los desarrolladores que implementaron una aplicación que necesita un Elemento seguro para emular una tarjeta. La implementación de HCE de Android está diseñada para funcionar en paralelo con otros métodos de implementación de la emulación de tarjetas, incluido el uso de Elementos seguros.
Nota: Android no ofrece API para comunicarse directamente con un Elemento seguro.
Esta coexistencia se basa en un principio llamado "enrutamiento AID": el controlador de NFC mantiene una tabla de enrutamiento que consiste en una lista (finita) de reglas de enrutamiento. Cada una de ellas contiene un AID y un destino. El destino puede ser la CPU del host (donde se ejecutan las apps para Android) o un Elemento seguro conectado.
Cuando el lector de NFC envía una APDU con un "SELECT AID", el controlador de NFC la analiza y verifica si el AID coincide con cualquier AID en su tabla de enrutamiento. Si coincide, esa APDU y todas las APDU siguientes se enviarán al destino asociado con el AID hasta que se reciba otra APDU "SELECT AID" o deje de funcionar el vínculo con NFC.
Nota: Si bien la especificación ISO/IEC 7816-4 también define el concepto de "coincidencias parciales", por el momento, los dispositivos con HCE de Android no lo admiten.
Esta arquitectura se ilustra en la figura 4.
Figura 4: Funcionamiento de Android con un Elemento seguro y con la emulación de tarjetas basada en el host
Por lo general, el controlador de NFC también contiene una ruta predeterminada para las APDU. Cuando no se encuentra un AID en la tabla de enrutamiento, se utiliza la ruta predeterminada. Si bien esta configuración puede variar en función del dispositivo, los dispositivos Android deben garantizar que los AID que registra tu app se enruten correctamente al host.
Las aplicaciones para Android que implementan un servicio de HCE o que usan un Elemento seguro no necesitan configurar la tabla de enrutamiento, ya que Android lo hace automáticamente. Android solo tiene que saber cuáles son los AID que pueden manejar los servicios de HCE y cuáles puede manejar el Elemento seguro. En función de los servicios instalados y los que el usuario haya establecido como preferidos, la tabla de enrutamiento se configurará automáticamente.
Ya describimos cómo declarar AID para los servicios de HCE. En la próxima sección, se explica cómo declarar AID para aplicaciones que usan un Elemento seguro en la emulación de tarjetas.
Registro de AID con Elementos seguros
Las aplicaciones que utilizan un Elemento seguro para emular tarjetas pueden declarar un "servicio fuera del host" en su manifiesto. La declaración de dicho servicio es casi idéntica a la de un servicio de HCE. Estas son las excepciones:
- Se debe establecer en
SERVICE_INTERFACEla acción que se usa en el filtro de intents. - Se debe establecer en
SERVICE_META_DATAel atributo de nombre de los metadatos. El archivo XML de metadatos debe usar la etiqueta raíz
<offhost-apdu-service>.<service android:name=".MyOffHostApduService" android:exported="true" android:permission="android.permission.BIND_NFC_SERVICE"> <intent-filter> <action android:name="android.nfc.cardemulation.action.OFF_HOST_APDU_SERVICE"/> </intent-filter> <meta-data android:name="android.nfc.cardemulation.off_host_apdu_service" android:resource="@xml/apduservice"/> </service>
Ejemplo del archivo apduservice.xml correspondiente que registra dos AID:
<offhost-apdu-service xmlns:android="http://schemas.android.com/apk/res/android"
android:description="@string/servicedesc">
<aid-group android:description="@string/subscription" android:category="other">
<aid-filter android:name="F0010203040506"/>
<aid-filter android:name="F0394148148100"/>
</aid-group>
</offhost-apdu-service>
El atributo android:requireDeviceUnlock no se aplica a los servicios fuera del host, ya que la CPU del host no participa en la transacción y, por lo tanto, no puede evitar que el Elemento seguro ejecute transacciones cuando el dispositivo está bloqueado.
El atributo android:apduServiceBanner debe usarse para servicios fuera del host que también son aplicaciones de pagos a fin de poder seleccionarse como una aplicación de pagos predeterminada.
Invocación de servicio fuera del host
Android nunca iniciará un servicio que se declare como "fuera del host" ni se vinculará con él. Esto se debe a que el Elemento seguro es el que ejecuta las transacciones en sí, no el servicio de Android. La declaración del servicio solo permite que las aplicaciones registren los AID ya presentes en el Elemento seguro.
HCE y seguridad
La arquitectura de HCE proporciona un aspecto de seguridad básico: como tu servicio está protegido por el permiso del sistema BIND_NFC_SERVICE, solo el SO puede vincularse y comunicarse con él. Esto garantiza que cualquier APDU que recibas sea una APDU que recibió el SO desde el controlador de NFC y que cualquier APDU que envíes de vuelta solo vaya al sistema operativo, el cual, a su vez, reenviará directamente las APDU al controlador de NFC.
El aspecto fundamental restante es dónde obtienes los datos que envía tu app al lector de NFC. Esto se desacopla de forma intencional en el diseño de HCE: no le importa de dónde provienen los datos; solo se asegura de que se transporten de manera segura al controlador de NFC y al lector de NFC.
Para almacenar y recuperar de forma segura los datos que deseas enviar desde tu servicio de HCE, puedes, por ejemplo, utilizar la zona de pruebas de aplicaciones para Android, que aísla de otras apps los datos de tu app. Para obtener más detalles sobre la seguridad de Android, consulta el artículo Sugerencias de seguridad.
Parámetros y detalles del protocolo
Esta sección está orientada a los desarrolladores que desean comprender qué parámetros de protocolo utilizan los dispositivos con HCE durante las fases de anticolisión y activación de los protocolos de NFC. Esto permite construir una infraestructura de lector que sea compatible con los dispositivos Android con HCE.
Anticolisión y activación del protocolo Nfc-A (ISO/IEC 14443 tipo A)
Como parte de la activación del protocolo Nfc-A, se intercambian múltiples tramas.
En la primera parte del intercambio, el dispositivo con HCE presentará su UID; se debe suponer que los dispositivos con HCE tienen un UID aleatorio. Esto significa que, cada vez que el dispositivo toque el lector, el UID que se presente será un UID generado de forma aleatoria. Por tal motivo, los lectores de NFC no deben depender del UID de los dispositivos con HCE como una forma de autenticación o identificación.
Después, el lector de NFC puede seleccionar el dispositivo con HCE enviando un comando SEL_REQ. La respuesta SEL_RES del dispositivo con HCE tendrá al menos el sexto bit (0x20) establecido, lo que indica que el dispositivo es compatible con ISO-DEP. Ten en cuenta que también se pueden establecer otros bits en SEL_RES, lo que indica, por ejemplo, compatibilidad con el protocolo NFC-DEP (p2p). Debido a que se pueden establecer otros bits, los lectores que deseen interactuar con dispositivos con HCE deberán buscar explícitamente solo el sexto bit y
Activación de ISO-DEP
Después de activar el protocolo Nfc-A, el lector de NFC inicia la activación del protocolo ISO-DEP. Envía un comando "RATS" (solicitud de respuesta para seleccionar). El controlador NFC genera la respuesta RATS, la "ATS" (respuesta para seleccionar), y los servicios de HCE no la pueden configurar. Sin embargo, se requieren implementaciones de HCE a fin de cumplir con los requisitos de NFC Forum para la respuesta ATS, por lo que los lectores de NFC pueden contar con que estos parámetros se establezcan de acuerdo con lo que exige NFC Forum para cualquier dispositivo con HCE.
En la próxima sección, se proporcionan más detalles sobre los bytes individuales de la respuesta ATS que brinda el controlador de NFC en un dispositivo con HCE:
- TL: Es la longitud de la respuesta ATS. No debe indicar una longitud superior a 20 bytes.
- T0: Los bits 5, 6 y 7 deben establecerse en todos los dispositivos con HCE, lo que indica que TA(1), TB(1) y TC(1) están incluidos en la respuesta ATS. Los bits 1 a 4 indican el FSCI, que codifica el tamaño máximo de trama. En los dispositivos con HCE, el valor del FSCI debe ser de entre 0 h y 8 h.
- T(A)1: Define las tasas de bits entre el lector y el emulador, y si pueden ser asimétricas. No hay garantías ni requisitos de tasas de bits para los dispositivos con HCE.
- T(B)1: Los bits 1 a 4 indican el número entero del tiempo de seguridad de la trama de inicio (SFGI). En dispositivos con HCE, el SFGI debe ser <= 8 h. Los bits 5 a 8 indican el número entero de tiempo de espera de la trama (FWI) y codifican el tiempo de espera de la trama (FWT). En dispositivos con HCE, el FWI debe ser <= 8 h.
- T(C)1: El bit 5 indica compatibilidad con las funciones avanzadas del protocolo. Los dispositivos con HCE pueden o no admitir estas funciones. El bit 2 indica compatibilidad con el DID. Los dispositivos con HCE pueden o no ser compatibles con el DID. El bit 1 indica compatibilidad con la NAD. Los dispositivos con HCE no deben admitir la NAD y deben establecer el bit 1 en cero.
- Bytes históricos: Los dispositivos con HCE pueden mostrar hasta 15 bytes históricos. Los lectores de NFC que deseen interactuar con los servicios de HCE no deben hacer suposiciones sobre el contenido de los bytes históricos ni sobre su presencia.
Ten en cuenta que muchos dispositivos con HCE tal vez cumplan con los requisitos de protocolo que las redes de pagos agrupadas en EMVCo definieron en la especificación de su protocolo de comunicación sin contacto. En particular:
- El FSCI en T0 debe ser de entre 2 h y 8 h.
- T(A)1 debe establecerse en 0x80, lo que indica que solo se admite la tasa de bits de 106 kbit/s, y las tasas de bits asimétricas entre el lector y el emulador no son compatibles.
- El FWI en T(B)1 debe ser <= 7 h.
Intercambio de datos de APDU
Como se indicó anteriormente, las implementaciones de HCE solo admiten un canal lógico único. Intentar seleccionar aplicaciones en diferentes canales lógicos no funcionará en un dispositivo con HCE.