Descripción general de la emulación de tarjeta basada en el host

Muchos dispositivos con Android que ofrecen la funcionalidad NFC ya admiten la emulación de tarjetas NFC. En la mayoría de los casos, la tarjeta se emula con un chip separado en el dispositivo, llamado elemento seguro. Muchas de las tarjetas SIM que brindan los proveedores de servicios inalámbricos también contienen un Elemento seguro.

Android 4.4 y las versiones posteriores proporcionan un método adicional de emulación de tarjetas que no implica un Elemento seguro, denominado 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 tema, se describe cómo funciona la emulación de tarjetas basada en el host (HCE) en Android y cómo puedes desarrollar una app que emule una tarjeta NFC con esta técnica.

Emulación de tarjetas con un Elemento seguro

Cuando se realiza la emulación de la tarjeta NFC con un Elemento seguro, la tarjeta que se emula se aprovisiona en el Elemento seguro del dispositivo por medio de 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 este concepto:

Diagrama con el lector de NFC que pasa por un controlador NFC para recuperar información de un elemento seguro
Figura 1: Emulación de tarjeta NFC con un Elemento seguro

El Elemento seguro se comunica con la terminal de NFC y no interviene ninguna aplicación para Android en la transacción. Una vez que se completa la transacción, una aplicación para Android puede consultar directamente el Elemento seguro para conocer el estado de la transacción y notificar al usuario.

Emulación de tarjetas basada en el host

Cuando se emula una tarjeta NFC mediante la emulación de tarjetas basada en el host, los datos se enrutan directamente a la CPU del host en lugar de a un Elemento seguro. En la figura 2, se ilustra cómo funciona la emulación de tarjetas basada en el host:

Diagrama con el lector de NFC que pasa por un controlador NFC para recuperar información de la CPU
Figura 2: Emulación de tarjeta NFC sin un Elemento seguro

Tarjetas y protocolos NFC compatibles

Diagrama que muestra la pila de protocolo HCE
Figura 3: Pila de protocolos HCE de Android

Los estándares de NFC ofrecen compatibilidad con muchos protocolos diferentes, y existen diferentes tipos de tarjetas que puedes emular.

Android 4.4 y las versiones posteriores admiten varios protocolos que son comunes en el mercado actual. Muchas tarjetas sin contacto existentes ya se basan en estos protocolos, como las tarjetas de pago sin contacto. Estos protocolos también son compatibles con muchos lectores de NFC del mercado actual, incluidos los dispositivos NFC de Android que funcionan como lectores (consulta la clase IsoDep). Esto te permite compilar e implementar una solución NFC de extremo a extremo en torno a HCE utilizando solo dispositivos con Android.

Específicamente, Android 4.4 y las versiones posteriores admiten la emulación de tarjetas que se basan en la especificación ISO-DEP de NFC Forum (basada en ISO/IEC 14443-4) y procesan unidades de datos de protocolo de aplicación (APDU) como se define en la especificación ISO/IEC 7816-4. Android exige emular 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. En la Figura 3, se ilustran las capas de todas estas especificaciones.

Servicios de HCE

La arquitectura HCE en Android se basa en los componentes Service de Android (conocidos como servicios de HCE). Una de las ventajas clave de un servicio es que se puede ejecutar en segundo plano sin ninguna interfaz de usuario. Esta es una opción natural para muchas aplicaciones de HCE, como tarjetas de lealtad o de transporte público, para las que el usuario no debería tener que iniciar una app. En cambio, si presionas el dispositivo contra el lector de NFC, se inicia el servicio correcto si aún no se está ejecutando y ejecuta la transacción en segundo plano. Por supuesto, tienes la libertad de iniciar IU adicionales (como notificaciones de usuario) desde tu servicio cuando corresponda.

Selección de servicios

Cuando el usuario acerca un dispositivo a un lector de NFC, el sistema Android necesita saber con qué servicio de HCE desea comunicarse el lector de NFC. La especificación ISO/IEC 7816-4 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 existente, los AID que buscan esos lectores suelen ser conocidos y registrados de forma pública (por ejemplo, los AID de redes de pago como Visa y Mastercard).

Si quieres implementar una nueva infraestructura de lector para tu aplicación, debes registrar tus propios AID. El procedimiento de registro de los AID se define en la especificación ISO/IEC 7816-5. Te recomendamos registrar un AID según 7816-5 si implementas una aplicación de HCE para Android, ya que evita colisiones con otras aplicaciones.

Grupos de AID

En algunos casos, es posible que un servicio de HCE deba registrar varios AID y establecerse como el controlador predeterminado de todos ellos para implementar una aplicación determinada. No se admiten algunos AID del grupo que vayan a otro servicio.

Una lista de AID que se mantienen juntos se denomina grupo de AID. Para todos los AID de un grupo, Android garantiza una de las siguientes opciones:

  • 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 algunos AID del grupo se puedan enrutar a un servicio de HCE y otros a otro.

Grupos y categorías de AID

Puedes asociar cada grupo de AID con una categoría. Esto permite que Android agrupe los servicios de HCE por categoría y, a su vez, permite que el usuario establezca valores predeterminados a nivel de categoría en lugar de a nivel del AID. Evita mencionar AID en las partes de tu aplicación que ven los usuarios, ya que no significan nada para el usuario promedio.

Android 4.4 y las versiones posteriores admiten dos categorías:

Implementa un servicio de HCE

Para emular una tarjeta NFC con 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 la HCE

Para comprobar si un dispositivo es compatible con HCE, tu aplicación puede buscar la función FEATURE_NFC_HOST_CARD_EMULATION. Usa la etiqueta <uses-feature> en el manifiesto de tu aplicación para declarar que esta usa la función HCE y si es necesaria para que funcione o no.

Implementación del servicio

Android 4.4 y las versiones posteriores proporcionan una clase Service de conveniencia que puedes usar como base para implementar un servicio de HCE: la clase HostApduService.

El primer paso es extender HostApduService, como se muestra en la siguiente muestra de código:

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 debes anular e implementar. Se llama a uno de ellos, processCommandApdu(), cada vez que un lector de NFC envía una unidad de datos de protocolo de aplicación (APDU) a tu servicio. Las APDU se definen en la especificación ISO/IEC 7816-4. Las APDU 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 envía una APDU de comando y espera a que envíes una APDU de respuesta a cambio.

Como se mencionó anteriormente, 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 SELECT AID. Esta APDU contiene el AID con el que el lector quiere comunicarse. 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 llama a este método en el subproceso principal de tu aplicación, que no debes bloquear. 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 sigue reenviando APDU nuevas del lector a tu servicio hasta que ocurra alguna de las siguientes 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 que indica cuál de los dos ocurrió.

Si trabajas con una infraestructura de lector existente, debes implementar el protocolo a nivel de aplicación existente que los lectores esperan en tu servicio de HCE.

Si implementas una nueva infraestructura de lector que también controlas, puedes definir tu propio protocolo y secuencia de APDU. Intenta limitar la cantidad de APDU y el tamaño de los datos que se intercambiarán: esto garantiza que los usuarios solo tengan que sostener su dispositivo sobre el lector de NFC durante un período breve. Un límite superior razonable es de aproximadamente 1 KB de datos, que, por lo general, se puede intercambiar en 300 ms.

Declaración del servicio en el manifiesto y registro del AID

Debes declarar tu servicio en el manifiesto como de costumbre, pero también debes agregar algunas partes adicionales a la declaración del servicio:

  1. Para indicarle a la plataforma que es un servicio de HCE que implementa una interfaz HostApduService, agrega un filtro de intents para la acción SERVICE_INTERFACE en tu declaración del servicio.

  2. Para indicarle a la plataforma qué grupos de AID solicita este servicio, incluye 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.

  3. Establece el atributo android:exported en true y solicita 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 a tu servicio. Como android.permission.BIND_NFC_SERVICE es un permiso del sistema, esto exige de manera efectiva que solo el SO Android pueda vincularse a tu servicio.

A continuación, se muestra un ejemplo de una declaración del manifiesto HostApduService:

<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 fácil de usar que se pueda mostrar en la IU de la app. Puedes usar el atributo requireDeviceUnlock para especificar que el dispositivo está desbloqueado antes de invocar este servicio para controlar las APDU.

El <host-apdu-service> debe contener una o más etiquetas <aid-group>. Cada etiqueta <aid-group> debe hacer lo siguiente:

  • Contener un atributo android:description que contenga una descripción del grupo de AID fácil de usar, adecuada para mostrarse en la IU
  • Configura su atributo android:category para indicar la categoría a la que pertenece el grupo de AID, como las constantes de string definidas por CATEGORY_PAYMENT o CATEGORY_OTHER.
  • Contener una o más etiquetas <aid-filter>, cada una de las cuales contiene un solo AID Especifica el AID en formato hexadecimal y asegúrate de que contenga una cantidad par de caracteres.

La aplicación también debe tener el permiso NFC para registrarse como un servicio de HCE.

Resolución de conflictos de AID

Se pueden instalar varios componentes de HostApduService en un solo dispositivo, y más de un servicio puede registrar el mismo AID. Android resuelve los conflictos de AID de manera diferente según la categoría a la que pertenezca un AID. Cada categoría puede tener una política de resolución de conflictos diferente.

Para algunas categorías, como los pagos, el usuario podría seleccionar un servicio predeterminado en la IU de la configuración de Android. Para otras categorías, la política puede consistir en preguntar siempre al usuario qué servicio invocar en caso de conflicto. Si quieres obtener información para consultar la política de resolución de conflictos de una categoría determinada, consulta getSelectionModeForCategory().

Comprueba si tu servicio es el predeterminado

Las aplicaciones pueden verificar si su servicio de HCE es el predeterminado para una categoría determinada mediante la API de isDefaultServiceForCategory().

Si tu servicio no es el predeterminado, puedes solicitarlo mediante ACTION_CHANGE_DEFAULT.

Aplicaciones de pagos

Android considera como aplicaciones de pagos los servicios de HCE que declararon un grupo de AID con la categoría payment. Android 4.4 y las versiones posteriores incluyen una entrada de menú de Configuración de nivel superior llamada Tocar y pagar, que enumera todas esas aplicaciones de pagos. En este menú de configuración, el usuario puede seleccionar la aplicación de pagos predeterminada que invocará cuando se presione una terminal de pago.

Elementos requeridos para aplicaciones de pagos

Para proporcionar una experiencia del usuario más atractiva visualmente, las aplicaciones de pagos con HCE deben proporcionar un banner de servicio.

Android 13 y versiones posteriores

Para que se adapte mejor a la lista de selección de pagos predeterminada en la IU de Configuración, ajusta el requisito del banner a un ícono cuadrado. Lo ideal sería que sea idéntico al diseño del ícono de selector de la aplicación. Este ajuste crea más coherencia y un aspecto más limpio.

Android 12 y versiones anteriores

Establece el tamaño del banner de servicio en 260 x 96 dp y, luego, configura el tamaño del banner de servicio en tu archivo en formato XML de metadatos agregando el atributo android:apduServiceBanner a la etiqueta <host-apdu-service>, que apunta al recurso de 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

El comportamiento de los servicios de HCE varía según la versión de Android que se ejecute en el dispositivo.

Android 12 y versiones posteriores

En las apps que se orientan a Android 12 (nivel de API 31) y versiones posteriores, puedes habilitar los pagos NFC sin que la pantalla del dispositivo esté encendida si configuras requireDeviceScreenOn como false.

Android 10 y versiones posteriores

Los dispositivos que ejecutan Android 10 (nivel de API 29) o versiones posteriores admiten NFC seguro. Mientras la NFC seguro esté activada, los emuladores de tarjetas (aplicaciones de host y aplicaciones fuera del host) no estarán disponibles cuando la pantalla del dispositivo esté apagada. Mientras la NFC seguro esté desactivada, las aplicaciones fuera del host estarán disponibles cuando la pantalla del dispositivo esté apagada. Puedes verificar la compatibilidad con NFC seguro mediante isSecureNfcSupported().

En los dispositivos que ejecutan Android 10 y versiones posteriores, se aplica la misma funcionalidad para configurar android:requireDeviceUnlock en true que en los dispositivos que ejecutan Android 9 y versiones anteriores, pero solo cuando está desactivado el NFC seguro. Es decir, si está activado NFC seguro, los servicios de HCE no podrán funcionar desde la pantalla de bloqueo, independientemente de la configuración de android:requireDeviceUnlock.

Android 9 y versiones anteriores

En los dispositivos que ejecutan Android 9 (nivel de API 28) y versiones anteriores, el controlador de NFC y el procesador de la aplicación se apagan por completo cuando se apaga la pantalla del dispositivo. Por lo tanto, los servicios de HCE no funcionan cuando la pantalla está apagada.

Además, en Android 9 y versiones anteriores, los servicios de HCE pueden funcionar desde la pantalla de bloqueo. Sin embargo, esto se controla mediante el atributo android:requireDeviceUnlock en la etiqueta <host-apdu-service> del servicio de HCE. De forma predeterminada, no es necesario desbloquear el dispositivo, y el servicio se invoca incluso si el dispositivo está bloqueado.

Si configuras el atributo android:requireDeviceUnlock como true para tu servicio de HCE, Android le solicitará al usuario que desbloquee el dispositivo cuando ocurra lo siguiente:

  • el usuario presiona un lector de NFC.
  • el lector de NFC selecciona un AID que se resuelve en tu servicio.

Después del desbloqueo, Android muestra un diálogo en el que se le solicita al usuario que vuelva a presionar para 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 es útil para los desarrolladores que implementaron una aplicación que se basa en un Elemento seguro para la emulación de tarjetas. 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.

Esta coexistencia se basa en un principio denominado enrutamiento de AID. El controlador de NFC mantiene una tabla de enrutamiento compuesta por 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 los AID coinciden con cualquier AID en su tabla de enrutamiento. Si coincide, esa APDU y todas las APDU posteriores se envían al destino asociado con el AID, hasta que se reciba otra APDU SELECT AID o se rompa el vínculo NFC.

En la Figura 4, se ilustra esta arquitectura:

Diagrama con el lector de NFC que se comunica con un Elemento seguro y con la CPU
Figura 4: Funcionamiento de Android con un Elemento seguro y con la emulación de tarjetas de 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 ser diferente de un dispositivo a otro, 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 tienen que preocuparse por configurar la tabla de enrutamiento, ya que Android la controla automáticamente. Android solo necesita saber qué AID pueden controlar los servicios de HCE y cuáles puede controlar el Elemento seguro. La tabla de enrutamiento se configura de forma automática en función de los servicios que se instalan y los que el usuario configuró como preferidos.

En la siguiente 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 usan un Elemento seguro para la emulación de tarjetas pueden declarar un servicio fuera del host en su manifiesto. La declaración de ese servicio es casi idéntica a la de un servicio de HCE. Las excepciones son las siguientes:

  • La acción que se usa en el filtro de intents debe establecerse en SERVICE_INTERFACE.
  • El atributo de nombre de metadatos se debe establecer en SERVICE_META_DATA.
  • 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>
    

A continuación, se muestra un 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 está involucrada 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 es obligatorio para los servicios fuera del host que son aplicaciones de pagos y que se pueden seleccionar como una aplicación de pagos predeterminada.

Invocación del servicio fuera del host

Android nunca inicia un servicio que se declara "fuera del host" ni se vincula a él, ya que el Elemento seguro ejecuta las transacciones reales, y no el servicio de Android. La declaración del servicio solo permite que las aplicaciones registren los AID presentes en el Elemento seguro.

HCE y seguridad

La arquitectura HCE proporciona una pieza de seguridad central: debido a que 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 en realidad una APDU que haya recibido el SO desde el controlador de NFC y que cualquier APDU que envíes de vuelta solo vaya al SO, que, a su vez, reenviará directamente las APDU al controlador de NFC.

La última preocupación que queda 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 los datos de tu app de otras apps. Para obtener más detalles sobre la seguridad de Android, consulta Sugerencias de seguridad.

Parámetros y detalles del protocolo

Esta sección es útil para los desarrolladores que deseen comprender qué parámetros de protocolo usan los dispositivos con HCE durante las fases de anticolisión y activación de los protocolos de NFC. Esto permite crear una infraestructura de lector compatible con 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 presenta su UID; se debe suponer que los dispositivos con HCE tienen un UID aleatorio. Esto significa que, en cada toque, el UID que se presenta al lector es un UID generado de forma aleatoria. Por lo tanto, los lectores de NFC no deben depender del UID de los dispositivos con HCE como una forma de autenticación o identificación.

Luego, el lector de NFC puede seleccionar el dispositivo con HCE enviando un comando SEL_REQ. La respuesta SEL_RES del dispositivo con HCE tiene al menos el 6o bit (0x20), lo que indica que el dispositivo admite ISO-DEP. Ten en cuenta que también se pueden configurar otros bits en SEL_RES, lo que indica, por ejemplo, compatibilidad con el protocolo NFC-DEP (p2p). Dado 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 no comparar el valor de SEL_RES completo con un valor de 0x20.

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 de NFC genera la respuesta RATS, el ATS; los servicios de HCE no pueden configurar este último. Sin embargo, las implementaciones de HCE deben 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 los requisitos de NFC Forum para cualquier dispositivo con HCE.

En la siguiente sección, se proporcionan más detalles sobre los bytes individuales de la respuesta ATS proporcionada por 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 estar 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 inferior a 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 “funciones de protocolo avanzado”. 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 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 desean 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 es probable que muchos dispositivos con HCE cumplan con los requisitos de protocolo que las redes de pagos agrupadas en EMVCo especificaron en su especificación de “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 no se admiten las tasas de bits asimétricas entre el lector y el emulador.
  • El FWI en T(B)1 debe ser <= 7 h.

Intercambio de datos de APDU

Como se señaló antes, las implementaciones de HCE admiten un solo canal lógico. Intentar seleccionar aplicaciones en diferentes canales lógicos no funciona en un dispositivo con HCE.