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

Muchos dispositivos con Android que ofrecen la función NFC ya son compatibles con NFC. mediante la emulación de tarjeta. En la mayoría de los casos, la tarjeta se emula usando un chip independiente en llamado elemento seguro. Muchas tarjetas SIM proporcionadas por proveedores de servicios inalámbricos contienen un Elemento seguro.

Android 4.4 y las versiones posteriores proporcionan un método adicional de emulación de tarjeta que no incluye un Elemento seguro, llamado emulación de tarjeta basada en host. Esta permite que cualquier aplicación para Android emule una tarjeta y se comunique directamente con el NFC de lectura. En este tema, se describe el funcionamiento de la emulación de tarjetas basada en el host (HCE) Android y cómo puedes desarrollar una app que emule una tarjeta NFC con este técnica.

Emulación de tarjetas con un Elemento seguro

Cuando se proporciona la emulación de tarjeta NFC con un Elemento seguro, la tarjeta que se emulado se aprovisiona en el Elemento seguro del dispositivo a través de un y mantener la integridad de su aplicación. Luego, cuando el usuario sostenga el dispositivo sobre una terminal NFC, la interfaz de NFC en el dispositivo enruta todos los datos desde el lector directamente al . En la Figura 1, se ilustra este concepto:

Figura 1: Emulación de tarjeta NFC con un Elemento seguro

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

Emulación de tarjetas basada en el host

Cuando se emula una tarjeta NFC con la emulación de tarjeta basada en host, los datos se enrutan en lugar de enrutarse a un Elemento seguro. Figura 2 se ilustra el funcionamiento de 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 NFC ofrecen compatibilidad con muchos protocolos diferentes, y hay diferentes tipos de tarjetas que puedes emular.

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

Específicamente, Android 4.4 y las versiones posteriores admiten la emulación de tarjetas basadas en la especificación ISO-DEP del foro de NFC (basada en ISO/IEC 14443-4) y el proceso Unidades de datos del protocolo de aplicaciones (APDU), según se define en el estándar ISO/IEC 7816-4 especificación. Android exige la emulación de ISO-DEP solo por encima de Nfc-A (ISO/IEC 14443-3 tipo A). Compatibilidad con Nfc-B (ISO/IEC 14443-4 tipo B) tecnología es opcional. En la figura 3, se ilustran las capas de todos estos y las especificaciones del servicio.

Servicios de HCE

La arquitectura HCE en Android se basa en Componentes Service (conocidos como HCE) Google Cloud). Una de las ventajas clave de un servicio es que se puede ejecutar en segundo plano sin ninguna interfaz de usuario. Esto es un ajuste natural para muchas aplicaciones, como tarjetas de lealtad o de transporte público, que el usuario no debería necesitar iniciar una aplicación para usar. 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, puedes iniciar IU adicionales (como notificaciones a los usuarios) desde tu servicio cuando corresponda.

Selección de servicios

Cuando el usuario acerca un dispositivo a un lector de NFC, el sistema Android debe saber con qué servicio de HCE desea comunicarse el lector de NFC. El estándar 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 para una infraestructura existente de lector de NFC, los AID que esos lectores buscar suelen ser conocidos y estar registrados de manera pública (por ejemplo, el AID de redes de pagos como Visa y Mastercard).

Si quieres implementar una nueva infraestructura de lector para tu propia aplicación, puedes debes registrar tus propios AID. El procedimiento de registro para los AID se define en la especificación ISO/IEC 7816-5. Te recomendamos que registres un AID según el número 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 configurarse como el controlador predeterminado de todos los AID para implementar un determinado y mantener la integridad de su aplicación. No se admiten algunos AID del grupo que se dirigen a otro servicio.

Una lista de los AID que se mantienen juntos se denomina grupo de AID. Para todos los AID de un AID, 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 El usuario prefirió otro servicio que solicitó uno o más AID de tu grupo. también).

En otras palabras, no hay un estado intermedio en el que algunos AID del grupo puedan enrutarse 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 servicios de HCE juntos por categoría y que, a su vez, permite al usuario establecer de forma predeterminada en el nivel de la categoría, en lugar del nivel del AID. Evita mencionar AID en las partes de la aplicación para el usuario, porque no significan nada para el usuario promedio.

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

• CATEGORY_PAYMENT (incluye aplicaciones de pagos estándares de la industria)
• CATEGORY_OTHER (para todas las demás apps de HCE)

Nota: Solo se puede habilitar un grupo de AID en la categoría CATEGORY_PAYMENT en el sistema en cualquier momento. Por lo general, esta es una aplicación que comprende los principales protocolos de pago con tarjetas de crédito y cuáles pueden funcionar en cualquier comercio.

Para apps de pago de circuito cerrado que solo funcionan en un comerciante (como tarjetas de valor almacenado), usa CATEGORY_OTHER. Grupos de AID en esta categoría puede estar siempre activa y NFC puede darle prioridad lectores durante la selección del AID si es necesario.

Implementa un servicio de HCE

Para emular una tarjeta NFC con la emulación de tarjeta basada en host, debes crear una Es el componente Service que controla las transacciones NFC.

Comprueba la compatibilidad con HCE

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

Implementación del servicio

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

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

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. implementar. Una de ellas, processCommandApdu(): se llama cada vez que un lector de NFC envía una unidad de datos del protocolo de aplicaciones (APDU) a tu servicio. Las APDU se definen en la especificación ISO/IEC 7816-4. 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 un dúplex medio: el lector de NFC te envía una APDU de comando y espera a que envíes una APDU de respuesta en el resultado.

Nota: La especificación ISO/IEC 7816-4 también define el concepto de varios canales lógicos, que te permite tener varias APDU paralelas intercambios en canales lógicos separados. la implementación de HCE de Android, sin embargo, admite solo un canal lógico, por lo que solo hay un intercambio de APDU de un solo subproceso.

Como se mencionó anteriormente, Android usa el AID para determinar a qué servicio de HCE debe con el que el lector quiere hablar. Por lo general, es la primera APDU que envía un lector de NFC a tu el dispositivo es una APDU SELECT AID; esta APDU contiene el AID que el lector quiere para hablar. Android extrae ese AID de la APDU y lo resuelve en una HCE. y reenvía esa APDU al servicio resuelto.

Puedes enviar una APDU de respuesta devolviendo 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 devolver una APDU de respuesta, se muestra un valor nulo. Luego, puedes hacer el trabajo necesario en otro subproceso y usar el sendResponseApdu() definido en la clase HostApduService para enviar la respuesta cuando listo.

Android sigue reenviando nuevas APDU del lector a tu servicio, hasta que sucede lo siguiente:

• El lector de NFC envía otra APDU de SELECT AID, que el SO resuelve en una o un servicio diferente.
• Deja de funcionar el vínculo de NFC entre el lector de NFC y tu dispositivo.

En ambos casos, el equipo de onDeactivated() implementación se llama con un argumento que indica cuál de los dos ocurrió.

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

Si implementas una nueva infraestructura de lectores 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 sostener el dispositivo sobre el lector de NFC durante un período breve. R el límite superior razonable es de aproximadamente 1 KB de datos, que por lo general que se intercambia 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 debes agregar algunos en la declaración del servicio, como las siguientes:

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

2. Para indicarle a la plataforma qué grupos de AID solicita este servicio, incluye lo siguiente: pañal SERVICE_META_DATA Etiqueta <meta-data> en la declaración del servicio, que apunta a un archivo XML con información adicional sobre el servicio de HCE.

3. Configura el atributo android:exported como true y solicita el el permiso android.permission.BIND_NFC_SERVICE en la declaración del servicio. El primero garantiza que las aplicaciones externas puedan vincularse al servicio. Este último exige que solo las aplicaciones externas que contienen el El permiso android.permission.BIND_NFC_SERVICE puede vincularse a tu servicio. Como android.permission.BIND_NFC_SERVICE es un permiso del sistema, este parámetro exige de manera eficaz que solo el SO Android pueda vincularse a tu servicio.

El siguiente es un ejemplo de una declaración de 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 sola declaración de grupo de AID que contiene dos AID de propiedad exclusiva:

<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 contiene una descripción fácil de usar del servicio que puedes mostrar en la IU de la app. Puedes usar el atributo requireDeviceUnlock para especificar que el se desbloquea el dispositivo antes de invocar este servicio para controlar las APDU.

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

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

Tu aplicación también debe contener la el permiso NFC para registrarse como servicio de HCE.

Resolución de conflictos de AID

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

En el caso de algunas categorías, como las de pago, es posible que el usuario pueda seleccionar una configuración en la IU de la configuración de Android. Para otras categorías, la política podría ser Preguntar al usuario qué servicio invocar en caso de conflicto Información sobre cómo consultar la política de resolución de conflictos para una categoría determinada, consulta getSelectionModeForCategory()

Comprueba si tu servicio es el predeterminado

Las aplicaciones pueden comprobar si su servicio de HCE es el predeterminado para un categoría determinada mediante el isDefaultServiceForCategory() en la API de Cloud.

Si tu servicio no es el predeterminado, puedes solicitar que lo sea mediante ACTION_CHANGE_DEFAULT

Aplicaciones de pagos

Android considera los servicios de HCE que declararon un grupo de AID con el pagos como aplicaciones de pagos. Android 4.4 y las versiones posteriores incluyen un la entrada de nivel superior del menú de Configuración llamada presionar y pay, que enumera todas aplicaciones de pago. En este menú de configuración, el usuario puede seleccionar el aplicación de pago predeterminada para invocar cuando se presiona una terminal de pago.

Elementos requeridos para aplicaciones de pagos

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

Android 13 y versiones posteriores

Para que se ajuste mejor a la lista de selección de pagos predeterminada en la interfaz de usuario de Configuración, ajusta el requisito de banner a un ícono cuadrado. Idealmente, debería ser idéntico al diseño del ícono de selector de la aplicación. Este ajuste crea más coherencia y un 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, establece su tamaño en tu archivo en formato XML de metadatos agregando el atributo android:apduServiceBanner al La etiqueta <host-apdu-service>, que apunta al recurso de elementos de diseño El 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 orientadas a Android 12 (nivel de API 31) y versiones posteriores, puedes habilitar NFC pagos sin la pantalla del dispositivo encendida; para ello, configura requireDeviceScreenOn a false

Android 10 y versiones posteriores

Compatibilidad con dispositivos que ejecutan Android 10 (nivel de API 29) o versiones posteriores Seguridad NFC Aunque es seguro NFC está activado, todos los emuladores de tarjetas (aplicaciones host y aplicaciones fuera del host) están no disponible cuando la pantalla del dispositivo está apagada. Cuando la opción NFC seguro está desactivada, usar fuera del host aplicaciones están disponibles cuando la pantalla del dispositivo está apagada. Puedes comprobar Proteger la compatibilidad con NFC con isSecureNfcSupported()

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

Android 9 y versiones anteriores

En dispositivos con Android 9 (nivel de API 28) y versiones anteriores, el controlador NFC y el procesador de la aplicación se apagan por completo cuando la pantalla de la dispositivo está apagado. 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 lo controla el atributo android:requireDeviceUnlock en la etiqueta <host-apdu-service> de tu servicio de HCE. De forma predeterminada, el desbloqueo del dispositivo no es necesario, y tu servicio se invoca incluso si el dispositivo está bloqueado.

Si configuras el atributo android:requireDeviceUnlock como true para tu HCE Android le solicitará al usuario que desbloquee el dispositivo cuando se cumplan las siguientes condiciones: suceder:

• el usuario toca 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 que le solicita al usuario que vuelva a presionar para completar la transacción. Esto es necesario porque el usuario puede haber movido el dispositivo alejado del lector de NFC para desbloquearlo.

Coexistencia con tarjetas que tienen Elemento seguro

Esta sección está dirigida a los desarrolladores que implementaron una aplicación que depende de un Elemento seguro para la emulación de tarjetas. Implementación de HCE de Android está diseñado para funcionar en paralelo con otros métodos de implementación de tarjetas a través de la emulación de datos, incluido el uso de Elementos seguros.

Nota: Android no ofrece APIs para comunicarse directamente con un elemento en sí.

Esta coexistencia se basa en un principio denominado enrutamiento AID. El NFC el controlador mantiene una tabla de enrutamiento que consta de una lista (finita) de las reglas de firewall. Cada una de ellas contiene un AID y un destino. El destino puede puede ser la CPU del host, donde se ejecutan las apps para Android, o un servidor .

Cuando el lector de NFC envía una APDU con un SELECT AID, el controlador de NFC analiza y comprueba si coinciden con algún AID de la tabla de enrutamiento. Si coincide, esa APDU y todas las APDU siguientes se envían al destino asociado con el AID, hasta que se reciba otra APDU de SELECT AID o se envíe la el vínculo está roto.

Nota: Si bien la norma ISO/IEC 7816-4 también define el concepto de coincidencias parciales. No es compatible con los dispositivos Android con HCE.

En la figura 4, se ilustra esta arquitectura:

Figura 4: Funcionamiento de Android con elemento seguro y emulación de tarjeta de host

Por lo general, el controlador de NFC también contiene una ruta predeterminada para las APDU. Cuando un No se encuentra el AID en la tabla de enrutamiento, se utiliza la ruta predeterminada. Mientras que esta puede variar de un dispositivo a otro, los dispositivos Android son obligatorios para asegurarte de que los AID que registre tu app se enruten correctamente al host.

Aplicaciones para Android que implementan un servicio de HCE o que usan un Elemento seguro no debes preocuparte por configurar la tabla de enrutamiento. controlado por Android automáticamente. Android solo necesita saber qué AID se pueden manejar. por servicios de HCE y cuáles pueden controlarse con el Elemento seguro. La ruta una tabla se configura automáticamente según los servicios que estén instalados que el usuario configuró como preferidas.

En la siguiente sección, se explica cómo declarar AID para aplicaciones que usan un Elemento seguro para emular tarjetas.

Registro de AID con Elementos seguros

Las aplicaciones que usan un Elemento seguro para emular tarjetas pueden declarar un servicio fuera del host en su manifiesto. La declaración de un servicio de este tipo casi idéntica a la declaración de un servicio de HCE. Las excepciones son las siguientes: sigue:

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

El siguiente es un ejemplo del archivo apduservice.xml correspondiente registrar 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. debido a que la CPU del host no participa en la transacción y, por lo tanto, no puede evitarán que el Elemento seguro ejecute transacciones cuando el dispositivo esté bloqueado.

El atributo android:apduServiceBanner es obligatorio para los servicios fuera del host que sean aplicaciones de pago y que se puedan seleccionar como forma de pago predeterminada y mantener la integridad de su aplicación.

Invocación de servicios fuera del host

Android nunca inicia un servicio que se declara como “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 simplemente permite que las aplicaciones registra los AID presentes en el Elemento seguro.

HCE y seguridad

La arquitectura de HCE proporciona una pieza fundamental de seguridad: porque su servicio está protegido por la BIND_NFC_SERVICE permiso del sistema, solo el SO puede vincularse y comunicarse con él. Esto garantiza que cualquier APDU que recibas sea realmente una APDU que recibió el SO desde el controlador NFC, y que cualquier APDU que devuelvas solo vaya a que, a su vez, reenvía las APDU al controlador de NFC.

El último problema restante es de dónde obtienes los datos que envía tu app al lector de NFC. Esto está desacoplado intencionalmente en el diseño de HCE. hace no le importa de dónde provienen los datos, solo se asegura de que estén al controlador de NFC y al lector de NFC.

Para almacenar y recuperar de forma segura los datos que deseas enviar desde tu HCE de aplicaciones, puedes utilizar la zona de pruebas de aplicaciones de Android, que aísla los datos de tu app de otras apps. Para obtener más información sobre Android seguridad, consulta el artículo Sugerencias de seguridad.

Parámetros y detalles del protocolo

Esta sección está dirigida a los desarrolladores que quieren comprender qué protocolo parámetros que usan los dispositivos con HCE durante las fases anticolisión y de activación del los protocolos NFC. Esto permite crear una infraestructura de lectores y son compatibles 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. Dispositivos con HCE que 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 este motivo, 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 SEL_REQ. kubectl. La respuesta SEL_RES del dispositivo con HCE tiene al menos el 6o bit. (0x20), lo que indica que el dispositivo es compatible con ISO-DEP. Ten en cuenta que otros bits de También se puede configurar SEL_RES, lo que indica, por ejemplo, la compatibilidad con NFC-DEP (p2p). Como se pueden configurar otros bits, los lectores que quieran interactuar Los dispositivos con HCE deben comprobar explícitamente solo el sexto bit y no comparar el 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 ISO-DEP activación del protocolo. Envía una solicitud de respuesta para seleccionar (RATS) kubectl. el controlador NFC genera la respuesta RATS, el ATS; el ATS no es que los servicios de HCE pueden configurar. Sin embargo, las implementaciones de HCE deben cumplir con los requisitos del Foro de NFC. requisitos para la respuesta ATS, de modo que los lectores de NFC puedan contar con estos parámetros se configure de acuerdo con los requisitos del foro de NFC para cualquier dispositivo con HCE.

En la siguiente sección se proporcionan más detalles sobre los bytes individuales del ATS, proporcionada por el controlador 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 se deben configurar en todos los dispositivos con HCE, lo que indica TA(1) y TB(1) y TC(1) se incluyen en la respuesta de ATS. Los bits 1 a 4 indican el FSCI, que codifique el tamaño máximo de fotograma. En los dispositivos con HCE, el valor del FSCI debe ser entre 0 h y 8 h.
• T(A)1: Define las tasas de bits entre el lector y el emulador, y si se pueden asimétrica. 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). Activada dispositivos con HCE, el SFGI debe ser igual o inferior a 8 h. Los bits 5 a 8 indican la trama en espera (FWI) y codifica el tiempo de espera de la trama (FWT). En dispositivos con HCE, FWI debe ser <= 8 h.
• T(C)1: El bit 5 indica compatibilidad con las funciones avanzadas del protocolo. Dispositivos con HCE pueden o no admitir “funciones avanzadas de protocolo”. El bit 2 indica compatibilidad para 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. NFC los lectores que estén dispuestos a interactuar con los servicios de HCE no deben hacer suposiciones el contenido de los bytes históricos o su presencia.

Ten en cuenta que muchos dispositivos con HCE probablemente cumplan con los requisitos del protocolo. que las redes de pagos unidas en EMVCo hayan especificado en su lista de protocolo de comunicación" especificación. 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 es la tasa de bits de 106 kbit/s. y las tasas de bits asimétricas entre el lector y el emulador no son compatibles no es compatible.
• El FWI en T(B)1 debe ser <= 7 h.

Intercambio de datos de APDU

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