Visão geral da emulação de cartão baseada em host

Muitos dispositivos com tecnologia Android que oferecem a funcionalidade NFC já são compatíveis com emulação de cartão NFC. Na maioria dos casos, o cartão é emulado por um chip separado no dispositivo, chamado de elemento de segurança. Muitos chips fornecidos por operadoras de celular também contêm um Elemento de segurança.

O Android 4.4 e versões mais recentes oferecem um método adicional de emulação de cartão que não envolve um elemento de segurança, chamado emulação de cartão com base no host. Dessa forma, qualquer app Android pode emular um cartão e se comunicar diretamente com o leitor de NFC. Este tópico descreve como a emulação de cartão com base em host (HCE, na sigla em inglês) funciona no Android e como você pode desenvolver um app que emula um cartão NFC usando essa técnica.

Emulação de cartão com um elemento de segurança

Quando a emulação de cartão NFC é fornecida usando um elemento de segurança, o cartão a ser emulado é provisionado no elemento de segurança no dispositivo por meio de um aplicativo para Android. Depois, quando o usuário segura o dispositivo sobre um terminal NFC, o controlador de NFC no dispositivo encaminha todos os dados do leitor diretamente para o elemento de segurança. A Figura 1 ilustra esse conceito:

Diagrama com um leitor de NFC passando por um controlador de NFC para recuperar informações de um elemento de segurança
Figura 1. Emulação de cartão de NFC com um elemento de segurança.

O próprio elemento de segurança executa a comunicação com o terminal de NFC, e nenhum app Android está envolvido na transação. Após a conclusão da transação, um app Android pode consultar o elemento de segurança diretamente para conferir o status da transação e notificar o usuário.

Emulação de cartão com base no host

Quando um cartão NFC é emulado usando emulação de cartão com base em host, os dados são roteados diretamente para a CPU do host em vez de serem roteados para um elemento de segurança. A Figura 2 ilustra como funciona a emulação de cartão com base em host:

Diagrama com um leitor de NFC passando por um controlador de NFC para extrair informações da CPU
Figura 2. Emulação de cartão de NFC sem um elemento de segurança.

Cartões e protocolos de NFC compatíveis

Diagrama mostrando a pilha de protocolo HCE
Figura 3. Pilha de protocolo HCE do Android.

Os padrões de NFC oferecem suporte a muitos protocolos diferentes, e há diferentes tipos de cartões que podem ser emulados.

O Android 4.4 e versões mais recentes oferecem suporte a vários protocolos comuns no mercado hoje. Muitos cartões por aproximação atuais já são baseados nesses protocolos, como cartões de pagamento por aproximação. Esses protocolos também são compatíveis com muitos leitores de NFC no mercado atual, incluindo dispositivos Android NFC que funcionam como leitores em si (consulte a classe IsoDep). Isso permite criar e implantar uma solução de NFC completa sobre HCE usando apenas dispositivos com tecnologia Android.

Especificamente, o Android 4.4 e versões mais recentes oferecem suporte a emulação de cartões baseados na especificação ISO-DEP da NFC-Forum (com base na ISO/IEC 14443-4) e no processamento de unidades de dados de protocolo de aplicativo (APDUs, na sigla em inglês) conforme definido na especificação ISO/IEC 7816-4. O Android determina a emulação de ISO-DEP apenas com base na tecnologia Nfc-A (ISO/IEC 14443-3 Tipo A). O suporte para a tecnologia Nfc-B (ISO/IEC 14443-4 Tipo B) é opcional. A Figura 3 ilustra a criação de camadas de todas essas especificações.

Serviços de HCE

A arquitetura de HCE no Android é baseada em componentes Service do Android, conhecidos como serviços de HCE. Uma das principais vantagens de um serviço é que ele pode ser executado em segundo plano sem nenhuma interface do usuário. Essa é uma opção natural para muitos aplicativos de HCE, como cartões de fidelidade ou de transporte público, que o usuário não precisa iniciar um app para usar. Em vez disso, tocar o dispositivo no leitor de NFC inicia o serviço correto se ele ainda não estiver em execução e executa a transação em segundo plano. Obviamente, você pode iniciar outra IU (como notificações do usuário) no seu serviço quando apropriado.

Seleção de serviço

Quando o usuário toca em um dispositivo em um leitor de NFC, o sistema Android precisa saber com qual serviço de HCE o leitor de NFC quer se comunicar. A especificação ISO/IEC 7816-4 define uma maneira de selecionar aplicativos com base em um ID do aplicativo (AID, na sigla em inglês). Um AID consiste em até 16 bytes. Se você estiver emulando cartões para uma infraestrutura de leitor de NFC, os AIDs que esses leitores procuram geralmente são bem conhecidos e registrados publicamente (por exemplo, os AIDs de redes de pagamento como Visa e MasterCard).

Se você quiser implantar uma nova infraestrutura de leitor para seu próprio aplicativo, registre seus próprios AIDs. O procedimento de registro de AIDs é definido na especificação ISO/IEC 7816-5. Recomendamos o registro de um AID conforme o 7816-5 se você estiver implantando um aplicativo de HCE para Android, porque isso evita colisões com outros apps.

Grupos de AID

Em alguns casos, um serviço de HCE pode precisar registrar vários AIDs e ser definido como o gerenciador padrão de todos eles para implementar um determinado aplicativo. Não há suporte para alguns AIDs no grupo que vão para outro serviço.

Uma lista de AIDs que são mantidas juntas é chamada de grupo de AIDs. Para todos os AIDs em um grupo de AIDs, o Android garante um dos seguintes itens:

  • Todos os AIDs no grupo são roteados para esse serviço de HCE.
  • Nenhum AID no grupo é roteado para esse serviço de HCE (por exemplo, porque o usuário preferiu outro serviço que também solicitou um ou mais AIDs no seu grupo).

Em outras palavras, não há estado intermediário, em que alguns AIDs no grupo podem ser roteados para um serviço de HCE e outros para outro.

Categorias e grupos de AID

Você pode associar cada grupo de AID a uma categoria. Isso permite que o Android agrupe serviços de HCE por categoria, o que permite que o usuário defina padrões no nível da categoria em vez do nível do AID. Evite mencionar AIDs em qualquer parte do app voltada ao usuário, porque eles não significam nada para o usuário comum.

O Android 4.4 e versões mais recentes oferecem suporte a duas categorias:

Implementar um serviço de HCE

Para emular um cartão NFC usando a emulação de cartão com base em host, você precisa criar um componente Service que processe as transações NFC.

Verificar a compatibilidade com HCE

O aplicativo pode conferir se um dispositivo é compatível com HCE, verificando o recurso FEATURE_NFC_HOST_CARD_EMULATION. Use a tag <uses-feature> no manifesto do aplicativo para declarar que ele usa o recurso HCE e se ele é necessário para o app funcionar ou não.

Implementação do serviço

O Android 4.4 e versões mais recentes oferecem uma classe de conveniência Service que pode ser usada como base para a implementação de um serviço de HCE: a classe HostApduService.

A primeira etapa é estender HostApduService, conforme mostrado no exemplo de código abaixo:

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 dois métodos abstratos que você precisa substituir e implementar. Um desses métodos, processCommandApdu(), é chamado sempre que um leitor de NFC envia uma unidade de dados do protocolo de aplicativo (APDU, na sigla em inglês) ao seu serviço. As APDUs são definidas na especificação ISO/IEC 7816-4. As APDUs são os pacotes no nível do aplicativo trocados entre o leitor de NFC e seu serviço de HCE. Esse protocolo no nível do aplicativo é half-duplex: o leitor de NFC envia uma APDU de comando e espera que você envie uma APDU de resposta em resposta.

Como mencionado anteriormente, o Android usa o AID para determinar com qual serviço de HCE o leitor quer falar. Normalmente, a primeira APDU que um leitor de NFC envia para seu dispositivo é uma APDU SELECT AID. Essa APDU contém o AID com que o leitor quer se comunicar. O Android extrai esse AID da APDU, o resolve para um serviço de HCE e, em seguida, encaminha essa APDU para o serviço resolvido.

É possível enviar uma APDU de resposta retornando os bytes da APDU de resposta de processCommandApdu(). Esse método é chamado na linha de execução principal do aplicativo, a qual não pode ser bloqueada. Se não for possível calcular e retornar uma APDU de resposta imediatamente, retorne nulo. Você pode fazer o trabalho necessário em outra linha de execução e usar o método sendResponseApdu() definido na classe HostApduService para enviar a resposta quando terminar.

O Android continua encaminhando novas APDUs do leitor para seu serviço até que uma das seguintes situações aconteça:

  • O leitor de NFC envia outra APDU SELECT AID, que o SO resolve para um serviço diferente.
  • o link de NFC entre o leitor de NFC e seu dispositivo seja quebrado.

Em ambos os casos, a implementação de onDeactivated() da classe é chamada com um argumento indicando qual dos dois aconteceu.

Se você estiver trabalhando com a infraestrutura de leitor atual, será necessário implementar o protocolo existente no nível do aplicativo que os leitores esperam no serviço de HCE.

Se você estiver implantando uma nova infraestrutura de leitor que também controla, poderá definir seu próprio protocolo e sequência de APDU. Tente limitar a quantidade de APDUs e o tamanho dos dados a serem trocados. Isso garante que os usuários precisem manter o dispositivo sobre o leitor de NFC por um curto período. Um limite superior razoável tem cerca de 1 KB de dados, que geralmente pode ser trocado em até 300 ms.

Declaração de manifesto de serviço e registro de AID

É necessário declarar o serviço no manifesto como de costume, mas também é necessário adicionar mais algumas partes à declaração de serviço:

  1. Para informar à plataforma que é um serviço de HCE que implementa uma interface HostApduService, adicione um filtro de intent para a ação SERVICE_INTERFACE à declaração de serviço.

  2. Para informar à plataforma quais grupos de AIDs são solicitados por esse serviço, inclua uma tag <meta-data> SERVICE_META_DATA na declaração do serviço, apontando para um recurso XML com mais informações sobre o serviço de HCE.

  3. Defina o atributo android:exported como true e exija a permissão android.permission.BIND_NFC_SERVICE na declaração de serviço. O primeiro garante que o serviço possa ser vinculado por apps externos. O segundo garante que apenas apps externos que têm a permissão android.permission.BIND_NFC_SERVICE podem se vincular ao serviço. Como android.permission.BIND_NFC_SERVICE é uma permissão do sistema, isso implementa efetivamente que apenas o SO Android pode se vincular ao serviço.

Confira a seguir um exemplo de declaração de manifesto 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>

Essa tag de metadados aponta para um arquivo apduservice.xml. Confira a seguir um exemplo desse arquivo com uma única declaração de grupo de AIDs contendo dois AIDs reservados:

<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>

A tag <host-apdu-service> precisa conter um atributo <android:description> com uma descrição fácil de usar do serviço que você pode mostrar na interface do app. É possível usar o atributo requireDeviceUnlock para especificar que o dispositivo será desbloqueado antes de invocar esse serviço para processar as APDUs.

O <host-apdu-service> precisa conter uma ou mais tags <aid-group>. Cada tag <aid-group> é necessária para fazer o seguinte:

  • conter um atributo android:description que contenha uma descrição fácil de usar do grupo de AIDs, adequados para exibição na interface;
  • Ter o atributo android:category definido para indicar a categoria a que o grupo de AID pertence, como as constantes de string definidas por CATEGORY_PAYMENT ou CATEGORY_OTHER.
  • conter uma ou mais tags <aid-filter>, cada uma com um único AID; Especifique o AID no formato hexadecimal e verifique se ele contém um número par de caracteres.

O app também precisa conter a permissão NFC para se registrar como um serviço de HCE.

Resolução de conflitos de AID

Vários componentes HostApduService podem ser instalados em um único dispositivo, e o mesmo AID pode ser registrado por mais de um serviço. O Android resolve conflitos de AID de maneira diferente, dependendo da categoria a que um AID pertence. Cada categoria pode ter uma política de resolução de conflitos diferente.

Para algumas categorias, como pagamento, o usuário pode selecionar um serviço padrão na interface de configurações do Android. Para outras categorias, a política pode ser sempre perguntar ao usuário qual serviço invocar em caso de conflito. Para mais informações sobre como consultar a política de resolução de conflitos de uma determinada categoria, consulte getSelectionModeForCategory().

Verificar se o serviço é o padrão

Os aplicativos podem verificar se o serviço de HCE é o padrão para uma determinada categoria usando a API isDefaultServiceForCategory().

Se o serviço não for o padrão, solicite que ele se torne padrão usando ACTION_CHANGE_DEFAULT.

Apps de pagamento

O Android considera serviços de HCE que declararam um grupo de AIDs com a categoria de pagamento como apps de pagamento. O Android 4.4 e versões mais recentes contêm uma entrada de menu Configurações de nível superior chamada Toque e pague, que enumera todos esses apps de pagamento. Neste menu de configurações, o usuário pode selecionar o aplicativo de pagamento padrão a ser invocado quando um terminal de pagamento for tocado.

Recursos obrigatórios para apps de pagamento

Para proporcionar uma experiência do usuário visualmente mais atraente, os apps de pagamento de HCE precisam fornecer um banner de serviço.

Android 13 e versões mais recentes

Para ajustar melhor a lista de seleção de pagamento padrão na interface de configurações, ajuste o requisito do banner para um ícone quadrado. O ideal é que ele seja idêntico ao design do ícone na tela de início do aplicativo. Esse ajuste cria mais consistência e uma aparência mais limpa.

Android 12 e versões anteriores

Defina o tamanho do banner de serviço como 260 x 96 dp. Em seguida, defina o tamanho do banner de serviço no arquivo XML de metadados adicionando o atributo android:apduServiceBanner à tag <host-apdu-service>, que aponta para o recurso drawable. Confira um exemplo:

<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>

Tela desativada e comportamento da tela de bloqueio

O comportamento dos serviços de HCE varia de acordo com a versão do Android em execução no dispositivo.

Android 12 e versões mais recentes

Em apps direcionados ao Android 12 (nível 31 da API) e versões mais recentes, é possível ativar pagamentos NFC sem a tela do dispositivo ativada, definindo requireDeviceScreenOn como false.

Android 10 e versões mais recentes

Dispositivos com o Android 10 (API de nível 29) ou versões mais recentes são compatíveis com a NFC segura. Enquanto a NFC segura estiver ativada, todos os emuladores de cartão (aplicativos host e aplicativos fora do host) ficarão indisponíveis quando a tela do dispositivo estiver desativada. Enquanto a NFC segura estiver desativada, os aplicativos fora do host estarão disponíveis quando a tela do dispositivo estiver desativada. Você pode verificar o suporte a NFC segura usando isSecureNfcSupported().

Em dispositivos com Android 10 e versões mais recentes, a mesma funcionalidade para definir android:requireDeviceUnlock como true se aplica aos dispositivos com Android 9 e versões anteriores, mas apenas quando a NFC segura está desativada. Ou seja, se a NFC segura estiver ativada, os serviços de HCE não poderão funcionar na tela de bloqueio, independentemente da configuração de android:requireDeviceUnlock.

Android 9 e versões anteriores

Em dispositivos com o Android 9 (nível 28 da API) e versões anteriores, o controlador de NFC e o processador do aplicativo são desligados completamente quando a tela do dispositivo é desligada. Portanto, os serviços de HCE não funcionam quando a tela está desligada.

Também no Android 9 e versões anteriores, os serviços de HCE podem funcionar na tela de bloqueio. No entanto, isso é controlado pelo atributo android:requireDeviceUnlock na tag <host-apdu-service> do serviço de HCE. Por padrão, o desbloqueio do dispositivo não é obrigatório, e o serviço é invocado mesmo se o dispositivo estiver bloqueado.

Se você definir o atributo android:requireDeviceUnlock como true para seu serviço de HCE, o Android vai solicitar que o usuário desbloqueie o dispositivo quando o seguinte acontecer:

  • o usuário toca em um leitor de NFC.
  • o leitor de NFC seleciona um AID que é resolvido para o seu serviço.

Após o desbloqueio, o Android mostra uma caixa de diálogo solicitando que o usuário toque novamente para concluir a transação. Isso é necessário porque o usuário pode ter movido o dispositivo para longe do leitor de NFC para desbloqueá-lo.

Coexistência com cartões de elemento de segurança

Esta seção é interessante para desenvolvedores que implantaram um aplicativo que depende de um elemento de segurança para a emulação de cartão. A implementação de HCE do Android foi projetada para funcionar em paralelo com outros métodos de implementação de emulação de cartão, incluindo o uso de elementos de segurança.

Essa coexistência é baseada em um princípio chamado roteamento de AID. O controlador de NFC mantém uma tabela de roteamento que consiste em uma lista (finita) de regras de roteamento. Cada regra de roteamento contém um AID e um destino. O destino pode ser a CPU do host, em que os apps Android estão em execução, ou um elemento de segurança conectado.

Quando o leitor de NFC envia uma APDU com um SELECT AID, o controlador de NFC a analisa e verifica se os AIDs correspondem a algum AID na sua tabela de roteamento. Se corresponder, essa APDU e todas as APDUs a seguir serão enviadas ao destino associado ao AID, até que outra APDU SELECT AID seja recebida ou o link NFC seja corrompido.

A Figura 4 ilustra essa arquitetura:

Diagrama com o leitor de NFC se comunicando com um elemento de segurança e a CPU
Figura 4. Android operando com emulação de cartão de host e elemento de segurança.

O controlador de NFC normalmente também contém uma rota padrão para APDUs. Quando um AID não é encontrado na tabela de roteamento, a rota padrão é usada. Embora essa configuração possa ser diferente de dispositivo para dispositivo, os dispositivos Android precisam garantir que os AIDs registrados pelo app sejam roteados corretamente para o host.

Os aplicativos Android que implementam um serviço de HCE ou que usam um elemento de segurança não precisam se preocupar com a configuração da tabela de roteamento, que é processada pelo Android automaticamente. O Android só precisa saber quais AIDs podem ser processados pelos serviços de HCE e quais podem ser processados pelo elemento de segurança. A tabela de roteamento é configurada automaticamente com base nos serviços instalados e nos configurados como preferidos pelo usuário.

A seção a seguir explica como declarar AIDs para aplicativos que usam um elemento de segurança para emulação de cartão.

Registro do AID do elemento de segurança

Os aplicativos que usam um elemento de segurança para emulação de cartão podem declarar um serviço fora do host no manifesto. A declaração de tal serviço é quase idêntica à declaração de um serviço de HCE. As exceções são as seguintes:

  • A ação usada no filtro de intent precisa ser definida como SERVICE_INTERFACE.
  • O atributo de nome de metadados precisa ser definido como SERVICE_META_DATA.
  • O arquivo XML de metadados precisa usar a tag raiz <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>
    

Confira a seguir um exemplo do arquivo apduservice.xml correspondente que registra dois AIDs:

<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>

O atributo android:requireDeviceUnlock não se aplica a serviços fora do host, porque a CPU do host não está envolvida na transação e, portanto, não pode impedir que o elemento de segurança execute transações quando o dispositivo estiver bloqueado.

O atributo android:apduServiceBanner é necessário para serviços fora do host que são apps de pagamento e podem ser selecionados como um app de pagamento padrão.

Invocação de serviço fora do host

O Android nunca inicia ou se vincula a um serviço declarado como "fora do host" porque as transações reais são executadas pelo elemento de segurança, e não pelo serviço do Android. A declaração de serviço apenas permite que os aplicativos registrem os AIDs presentes no elemento de segurança.

HCE e segurança

A arquitetura HCE fornece uma parte principal de segurança: como seu serviço é protegido pela permissão do sistema BIND_NFC_SERVICE, apenas o SO pode se vincular e se comunicar com o serviço. Isso garante que qualquer APDU recebida seja, na verdade, uma APDU recebida pelo SO do controlador de NFC e que qualquer APDU enviada de volta só vá para o SO, que, por sua vez, encaminha diretamente as APDUs para o controlador de NFC.

A última preocupação é onde você recebe os dados que o app envia ao leitor de NFC. Isso é intencionalmente dissociado no design de HCE. Não importa de onde os dados vêm, apenas garante que eles sejam transportados com segurança para o controlador de NFC e para o leitor de NFC.

Para armazenar e extrair com segurança os dados que você quer enviar do serviço de HCE, pode, por exemplo, usar o sandbox do aplicativo Android, que isola os dados do seu app de outros. Para saber mais sobre a segurança do Android, leia Dicas de segurança.

Parâmetros de protocolo e detalhes

Esta seção é de interesse de desenvolvedores que querem entender quais parâmetros de protocolo os dispositivos HCE usam durante as fases de anticolisão e ativação dos protocolos NFC. Isso permite criar uma infraestrutura de leitor que é compatível com dispositivos Android HCE.

Anticolisão e ativação do protocolo Nfc-A (ISO/IEC 14443 tipo A)

Como parte da ativação do protocolo Nfc-A, vários frames são trocados.

Na primeira parte da troca, o dispositivo HCE apresenta o UID. Os dispositivos HCE precisam ter um UID aleatório. Isso significa que, a cada toque, o UID apresentado ao leitor é um UID gerado aleatoriamente. Por isso, os leitores de NFC não podem depender do UID de dispositivos HCE como forma de autenticação ou identificação.

Em seguida, o leitor de NFC pode selecionar o dispositivo HCE enviando um comando SEL_REQ. A resposta SEL_RES do dispositivo HCE tem pelo menos o 6o bit (0x20) definido, indicando que o dispositivo é compatível com ISO-DEP. Outros bits em SEL_RES também podem ser definidos, indicando, por exemplo, suporte para o protocolo NFC-DEP (p2p). Como outros bits podem ser definidos, os leitores que quiserem interagir com dispositivos HCE precisam verificar explicitamente apenas o 6o bit e não comparar o SEL_RES completo com um valor de 0x20.

Ativação de ISO-DEP

Depois que o protocolo Nfc-A é ativado, o leitor de NFC inicia a ativação do protocolo ISO-DEP. Ele envia um comando "Solicitação de resposta para seleção" (RATS, na sigla em inglês). O controlador de NFC gera a resposta RATS, o ATS. O ATS não é configurável pelos serviços de HCE. No entanto, as implementações de HCE precisam atender aos requisitos do NFC Forum para a resposta ATS. Assim, os leitores de NFC podem contar com esses parâmetros definidos de acordo com os requisitos do Fórum de NFC para qualquer dispositivo HCE.

A seção abaixo fornece mais detalhes sobre os bytes individuais da resposta ATS fornecida pelo controlador de NFC em um dispositivo HCE:

  • TL: comprimento da resposta ATS. Não pode indicar um comprimento maior que 20 bytes.
  • T0: os bits 5, 6 e 7 precisam ser definidos em todos os dispositivos HCE, indicando que TA(1), TB(1) e TC(1) são incluídos na resposta ATS. Os bits 1 a 4 indicam o FSCI, codificando o tamanho máximo do frame. Em dispositivos HCE, o valor de FSCI precisa estar entre 0h e 8h.
  • T(A)1: define taxas de bits entre o leitor e o emulador, e se eles podem ser assimétricas. Não existem requisitos ou garantias de taxa de bits para dispositivos HCE.
  • T(B) 1: os bits 1 a 4 indicam o inteiro de tempo de ativação do frame de inicialização (SFGI, na sigla em inglês). Em dispositivos HCE, o SFGI precisa ser <= 8h. Os bits 5 a 8 indicam o número inteiro de tempo de espera do frame (FWI, na sigla em inglês) e codificam o tempo de espera do frame (FWT, na sigla em inglês). Em dispositivos HCE, o FWI precisa ser <= 8h.
  • T(C) 1: o bit 5 indica suporte para "Recursos avançados do protocolo". Os dispositivos HCE podem ou não oferecer suporte a "Recursos avançados do protocolo". O bit 2 indica suporte para DID. Os dispositivos HCE podem ou não ser compatíveis com DID. O bit 1 indica suporte para NAD. Dispositivos HCE não devem ser compatíveis com NAD e definir o bit 1 como zero.
  • Bytes históricos: os dispositivos HCE podem retornar até 15 bytes históricos. Os leitores de NFC dispostos a interagir com serviços de HCE não devem fazer suposições sobre o conteúdo dos bytes históricos ou a presença deles.

Observe que muitos dispositivos HCE provavelmente são compatíveis com os requisitos de protocolo que as redes de pagamentos unidas no EMVCo especificaram na especificação do "Protocolo de comunicação por aproximação". Especificamente, as seguintes:

  • O FSCI em T0 precisa estar entre 2h e 8h.
  • T(A)1 precisa ser definido como 0x80, indicando que apenas a taxa de bits de 106 kbit/s é compatível e não há suporte a taxas de bits assimétricas entre o leitor e o emulador.
  • O FWI em T(B)1 precisa ser <= 7h.

Troca de dados da APDU

Como observado anteriormente, as implementações de HCE oferecem suporte a apenas um único canal lógico. A tentativa de selecionar apps em canais lógicos diferentes não funciona em um dispositivo HCE.