Visão geral da emulação de cartão com base em host

Muitos dispositivos com tecnologia Android que oferecem a funcionalidade NFC já são compatíveis com emulação de cartão de 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 telefonia celular também contêm um elemento de segurança.

O Android 4.4 introduz um método adicional de emulação de cartão que não envolve um elemento de segurança, chamado de emulação de cartão com base no host. Dessa forma, os aplicativos para Android conseguem emular um cartão e se comunicar diretamente com o leitor de NFC. Este documento descreve como a emulação de cartão com base no host (HCE, na sigla em inglês) funciona no Android e como você pode desenvolver um app que emula um cartão de NFC usando essa técnica.

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

Quando a emulação de cartão de 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. Em seguida, quando o usuário segura o dispositivo sobre um terminal de NFC, o controlador de NFC no dispositivo roteia todos os dados do leitor diretamente para o elemento de segurança. A Figura 1 ilustra esse conceito.

Figura 1. Emulação de cartão de NFC com um elemento de segurança.

O próprio elemento de segurança realiza a comunicação com o terminal de NFC e nenhum aplicativo para Android está envolvido na transação. Depois que a transação for concluída, um aplicativo para Android poderá consultar o elemento de segurança diretamente para ver o status da transação e notificar o usuário.

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

Quando um cartão de NFC é emulado usando emulação de cartão com base no host, os dados são roteados para a CPU do host em que os aplicativos para Android são executados diretamente, em vez de rotear os frames do protocolo NFC para um elemento de segurança. A Figura 2 ilustra como a emulação de cartão com base no host funciona.

Figura 2. Emulação de cartão de NFC sem um elemento de segurança.

Cartões e protocolos de NFC compatíveis

Figura 3. Pilha de protocolo HCE do Android.

Os padrões de NFC são compatíveis com muitos protocolos diferentes, e há diferentes tipos de cartão que podem ser emulados.

O Android 4.4 é compatível com vários protocolos comuns no mercado atual. Muitos cartões por aproximação existentes 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 propriamente ditos (consulte a classe IsoDep). Isso permite que você crie e implante uma solução de NFC completa relacionada a HCE usando apenas dispositivos com tecnologia Android.

Especificamente, o Android 4.4 é compatível com emulação de cartões baseados na especificação NFC-Forum ISO-DEP (baseada em ISO/IEC 14443-4) e no processo de unidades de dados de protocolo de aplicativo (APDUs, na sigla em inglês) conforme definido na especificação ISO/IEC 7816-4. No Android, é obrigatório emular a ISO-DEP apenas sobre a tecnologia Nfc-A (ISO/IEC 14443-3 Tipo A). O suporte para a tecnologia Nfc-B (ISO/IEC 14443-4 Tipo B) é opcional. A sobreposição de todas essas especificações é mostrada na figura 3.

Serviços de HCE

A arquitetura HCE do Android é baseada em componentes Service para Android, conhecidos como "serviços de HCE". Uma das grandes vantagens de um serviço é a capacidade de execução 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 transporte público, com os quais o usuário não precisa iniciar o app para usá-lo. Em vez disso, tocar o dispositivo no leitor de NFC inicia o serviço correto (se já não estiver em execução) e executa a transação em segundo plano. Obviamente, você pode iniciar outra IU no serviço se necessário, como a de notificações do usuário.

Seleção de serviço

Quando o usuário toca um dispositivo em um leitor de NFC, o sistema Android precisa saber com qual serviço de HCE o leitor de NFC busca comunicação. É aí que entra a especificação ISO/IEC 7816-4: ela define uma forma de selecionar apps, centralizada 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 desses leitores normalmente 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 app, precisará registrar seus próprios AIDs. O procedimento de registro de AIDs é definido na especificação ISO/IEC 7816-5. O Google recomenda o registro de um AID conforme 7816-5 se você estiver implantando um aplicativo de HCE para Android, já que isso evitará colisões com outros apps.

Grupos de AID

Em alguns casos, um serviço de HCE pode precisar registrar vários AIDs para implementar um determinado app e precisa ter certeza de que é o gerenciador padrão de todos esses AIDs, o que não acontece com alguns AIDs do grupo que vão para outro serviço.

Um grupo de AIDs é uma lista de AIDs que precisam ser considerados como pertencentes ao SO. Para todos os AIDs em um grupo de ajuda, 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 solicitou um ou mais AIDs no seu grupo também.

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

Cada grupo de AIDs pode ser associado a uma categoria. Isso permite que o Android agrupe serviços de HCE por categoria e isso, por sua vez, permite que o usuário defina padrões no nível da categoria em vez de no nível do AID. Em geral, evite mencionar AIDs em todas as partes do seu app para os usuários: eles não significam nada para o usuário comum.

O Android 4.4 é compatível com duas categorias: CATEGORY_PAYMENT que abrange os apps de pagamento padrão do setor e CATEGORY_OTHER para todos os outros apps de HCE.

Observação: somente um grupo de AIDs na categoria CATEGORY_PAYMENT pode ser ativado no sistema a qualquer momento. Normalmente, será um app que entende os principais protocolos de pagamento por cartão de crédito e que funciona com qualquer comerciante.

Para apps de pagamento de loop fechado que funcionam somente em um comerciante, como cartões pré-pagos, use CATEGORY_OTHER. Os grupos de AID nessa categoria podem estar sempre ativos e receber prioridade dos leitores de NFC durante a seleção de AID, se necessário.

Implementação de um serviço de HCE

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

Como verificar se há suporte para HCE

Seu app pode verificar 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 seu app 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 vem com 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 é, portanto, estender 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 dois métodos abstratos que precisam ser modificados e implementados.

processCommandApdu() é chamado sempre que um leitor de NFC envia uma unidade de dados de protocolo de aplicativo (APDU, na sigla em inglês) para seu serviço. As APDUs também são definidas na especificação ISO/IEC 7816-4. 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 enviará uma APDU de comando e aguardará o envio de uma APDU de resposta no retorno.

Observação: a especificação ISO/IEC 7816-4 também define o conceito de vários canais lógicos, onde você pode ter várias trocas paralelas de APDU em canais lógicos separados. No entanto, a implementação de HCE do Android permite apenas um único canal lógico. Portanto, há apenas uma troca de APDEs de linha de execução única.

Como mencionado anteriormente, o Android usa o AID para determinar com qual serviço de HCE o leitor quer conversar. Normalmente, a primeira APDU que um leitor de NFC envia para seu dispositivo é uma APDU "SELECT AID", essa APDU contém o AID com o que o leitor busca comunicação. 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.

Você pode enviar uma APDU de resposta retornando os bytes da APDU de resposta de processCommandApdu(). Observe que esse método será chamado na linha de execução principal do seu app, que não deve ser bloqueado. Portanto, se não for possível computar 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 continuará encaminhando novas APDUs do leitor para seu serviço até que:

  1. o leitor de NFC envie outra APDU "SELECT AID", que o SO resolverá para um serviço diferente;
  2. o link de NFC entre o leitor de NFC e seu dispositivo seja quebrado.

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

Se você estiver trabalhando com a infraestrutura de leitor existente, será necessário implementar o protocolo existente no nível do aplicativo esperado pelos leitores 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 sua sequência de APDU. Em geral, tente limitar a quantidade de APDUs e o tamanho dos dados que precisam ser trocados: isso garante que os usuários só precisarão manter o dispositivo no leitor de NFC por um curto período. Um limite superior razoável é cerca de 1 KB de dados, que geralmente podem ser trocados em 300 ms.

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

Seu serviço precisa ser declarado no manifesto como de costume, mas algumas partes adicionais também precisam ser adicionadas à declaração de serviço.

Primeiro, para informar à plataforma que é um serviço de HCE que implementa a interface HostApduService, sua declaração de serviço tem que conter um filtro de intents para a ação SERVICE_INTERFACE.

Além disso, para informar à plataforma quais grupos de AID são solicitados por esse serviço, uma tag SERVICE_META_DATA <meta-data> precisa ser incluída na declaração do serviço, apontando para um recurso XML com informações adicionais sobre o serviço de HCE.

Por fim, você precisa definir o atributo android:exported como verdadeiro e exigir a permissão "android.permission.BIND_NFC_SERVICE" na sua declaração de serviço. O primeiro garante que o serviço possa ser vinculado por apps externos. O segundo reforça que apenas os apps externos que contê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 reforça que somente o SO Android pode ser vinculado ao serviço.

Veja um exemplo de uma 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. Veja abaixo um exemplo desse tipo de arquivo com uma única declaração de grupo de AIDs contendo dois AIDs proprietários:

    <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> é necessária para conter um atributo <android:description> que contém uma descrição fácil de usar do serviço que pode ser exibida na IU. O atributo requireDeviceUnlock pode ser usado para especificar que o dispositivo precisa ser desbloqueado antes que esse serviço possa ser invocado para manipular APDUs.

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

  • conter um atributo android:description que contém uma descrição fácil de usar do grupo de AIDs, adequado para exibição na IU;
  • ter o atributo android:category definido para indicar a categoria à qual o grupo de AIDs pertence, por exemplo, as constantes de string definidas por CATEGORY_PAYMENT ou CATEGORY_OTHER.
  • Cada <aid-group> precisa conter uma ou mais tags <aid-filter>, cada uma contendo um único AID. O AID precisa ser especificado em formato hexadecimal e conter um número par de caracteres.

Como nota final, seu app também precisa conter a permissão NFC para poder 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. A plataforma Android resolve conflitos de AID dependendo da categoria à qual um AID pertence. Cada categoria pode ter uma política de resolução de conflitos diferente.

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

Verificar se o serviço é o padrão

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

Se o serviço não for o padrão, você poderá solicitar que ele se torne o padrão. Consulte ACTION_CHANGE_DEFAULT.

Apps de pagamento

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

Recursos obrigatórios para apps de pagamento

Para oferecer uma experiência do usuário visualmente mais atraente, os apps de pagamento de HCE são obrigados a fornecer um recurso adicional para o serviço: o chamado banner de serviço.

Esse recurso precisa ter o tamanho de 260x96 dp e pode ser especificado no arquivo de metadados XML adicionando o atributo android:apduServiceBanner à tag <host-apdu-service>, que aponta para o recurso drawable. Veja um exemplo abaixo:

    <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

As implementações atuais do Android desativam completamente o controlador de NFC e o processador do app quando a tela do dispositivo está desligada. Portanto, os serviços de HCE não funcionarão quando a tela estiver desligada.

Os serviços de HCE podem funcionar na tela de bloqueio, mas isso é controlado pelo atributo android:requireDeviceUnlock na tag <host-apdu-service> do seu serviço de HCE. Por padrão, o desbloqueio do dispositivo não é obrigatório, e seu serviço será invocado mesmo que o dispositivo esteja bloqueado.

Se você definir o atributo android:requireDeviceUnlock como "true" para o serviço de HCE, o Android solicitará que o usuário desbloqueie o dispositivo quando você tocar em um leitor de NFC que selecione um AID resolvido para seu serviço. Após o desbloqueio, o Android exibirá 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 é de interesse de desenvolvedores que implantaram um app que depende de um elemento de segurança para a emulação de cartão. A implementação de HCE do Android foi desenvolvida 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.

Observação: o Android não oferece APIs para comunicação direta com um elemento de segurança em si.

Essa coexistência baseia-se 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 aplicativos para 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 o analisa e verifica se os AIDs correspondem a qualquer AID na tabela de roteamento. Se ela corresponder, essa APDU e todas as APDUs após ela serão enviadas para o destino associado ao AID, até que outra APDU de "SELECT AID" seja recebida ou que o link de NFC seja quebrado.

Observação: embora a ISO/IEC 7816-4 defina também o conceito de “correspondências parciais”, isso não é compatível com dispositivos Android HCE.

Essa arquitetura é ilustrada na figura 4.

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 seu app sejam roteados corretamente para o host.

Aplicativos para 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 é cuidada automaticamente pelo Android. O Android só precisa saber quais AIDs podem ser gerenciados pelos serviços de HCE e quais podem ser gerenciados pelo elemento de segurança. Com base nos serviços instalados e nos configurados como preferencial pelo usuário, a tabela de roteamento é configurada automaticamente.

Já descrevemos como declarar AIDs para serviços de HCE. A seção a seguir explica como declarar AIDs para aplicativos que usam um elemento de segurança para a emulação de cartões.

Registro do AID do elemento de segurança

Os apps que usam um elemento de segurança para emulação de cartão podem declarar o chamado "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:

  • A ação usada no filtro de intents 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>

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 precisa ser usado para serviços fora do host que são apps de pagamento, bem como para serem selecionáveis como um app de pagamento padrão.

Invocação de serviço fora do host

O próprio Android nunca será iniciado ou vinculado a um serviço declarado como fora do host. Isso ocorre porque as transações reais são executadas pelo elemento de segurança e não pelo próprio serviço do Android. A declaração de serviço só permite que os apps registrem AIDs presentes no elemento de segurança.

HCE e segurança

A própria arquitetura de HCE fornece uma proteção essencial: como seu serviço é protegido pela permissão de sistema BIND_NFC_SERVICE, somente o SO pode se vincular ao seu serviço e se comunicar com ele. 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 retornará apenas ao SO, que, por sua vez, encaminhará diretamente as APDUs ao controlador de NFC.

A parte principal é onde você recebe os dados que o app envia para o leitor de NFC. Isso é desacoplado intencionalmente no design de HCE: não importa de onde os dados vêm, isso apenas garante que eles sejam transportados com segurança para o controlador de NFC e para o leitor de NFC.

Para armazenar e recuperar com segurança os dados que você quer enviar do serviço de HCE, é possível, por exemplo, confiar no sandbox do aplicativo para Android, que isola os dados do seu app de outros apps. Para mais detalhes sobre a segurança do Android, leia Dicas de segurança.

Parâmetros de protocolo e detalhes

Esta seção é de interesse dos desenvolvedores que querem entender quais parâmetros de protocolo os dispositivos HCE usam durante as fases de anticolisão e ativação dos protocolos de 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 apresentará o UID. Os dispositivos HCE precisam ter um UID aleatório. Isso significa que, a cada toque, o UID apresentado ao leitor será um UID gerado aleatoriamente. Por isso, os leitores de NFC não devem depender do UID de dispositivos HCE como uma 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 terá pelo menos o sexto bit (0x20) definido, indicando que o dispositivo é compatível com ISO-DEP. Observe que outros bits no 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 precisarão verificar explicitamente o sexto bit e não compararão o SEL_RES completo com um valor de 0x20.

Ativação de ISO-DEP

Depois que o protocolo Nfc-A é ativado, a ativação do protocolo ISO-DEP é iniciada pelo leitor de NFC. Ele envia um comando de solicitação de resposta para seleção (RATS, na sigla em inglês). A resposta de RATS, o ATS, é completamente gerada pelo controlador de NFC e não pode ser configurada pelos serviços de HCE. No entanto, as implementações de HCE são necessárias para satisfazer os requisitos do Fórum de NFC para a resposta ATS, de modo que 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 com mais de 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 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 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". Dispositivos HCE podem ou não ser compatíveis com "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 os serviços de HCE não devem supor o conteúdo dos bytes históricos ou a presença deles.

Muitos dispositivos HCE provavelmente são compatíveis com os requisitos de protocolo especificados nas redes de pagamento unidas pelo EMVCo 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 é aceita, e taxas de bits assimétricas entre leitor e emulador não são permitidas.
  • O FWI em T(B)1 precisa ser <= 7h.

Troca de dados da APDU

Como observado anteriormente, as implementações de HCE são compatíveis com apenas um único canal lógico. A tentativa de selecionar apps em canais lógicos diferentes não funcionará em um dispositivo HCE.