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 NFC emulação de cartão de crédito. Na maioria dos casos, o cartão é emulado por um chip separado no chamado de elemento de segurança. Vários chips fornecidos por operadoras de celular também podem conter um elemento de segurança.

O Android 4.4 e versões posteriores 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 em host. Isso permite que qualquer aplicativo Android emule um cartão e se comunique diretamente com a NFC leitor de tela. Este tópico descreve como funciona a emulação de cartão com base em host (HCE, na sigla em inglês) em no Android e como desenvolver um app que emula um cartão NFC usando esse 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 do dispositivo por meio de um para o aplicativo. Então, quando o usuário segurar o dispositivo sobre um terminal NFC, o dispositivo no dispositivo roteia todos os dados do leitor diretamente para o dispositivo . 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 NFC e nenhum aplicativo Android está envolvido na transação. Depois que a transação for concluído, um aplicativo Android pode consultar o elemento de segurança diretamente para obter 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 encaminhados para um elemento de segurança. Figura 2 ilustra como funciona a emulação de cartão com base em host:

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 NFC oferecem suporte a muitos protocolos diferentes, e há diferentes tipos de cards que podem ser emulados.

O Android 4.4 e versões posteriores são compatíveis com vários protocolos comuns no mercado hoje mesmo. Muitos cartões por aproximação atuais já são baseados nesses protocolos, como cartões de pagamento sem contato. Esses protocolos também são suportados por muitos Leitores de NFC disponíveis no mercado atualmente, incluindo dispositivos Android NFC que funcionam como leitores (consulte IsoDep ). Isso permite criar e implantar uma solução NFC completa em torno HCE usando apenas dispositivos com tecnologia Android.

Especificamente, o Android 4.4 e versões mais recentes oferecem suporte à emulação de cartões baseados em a especificação e o processo do NFC-Forum ISO-DEP (baseado no ISO/IEC 14443-4) Unidades de Dados de Protocolo de Aplicativo (APDUs, na sigla em inglês), conforme definido na norma ISO/IEC 7816-4 especificação. O Android exige a emulação de ISO-DEP apenas sobre o Nfc-A (ISO/IEC 14443-3 Tipo A). Suporte para Nfc-B (ISO/IEC 14443-4 Tipo B) é opcional. A Figura 3 ilustra a disposição em camadas de todas essas especificações.

Serviços de HCE

A arquitetura HCE do Android é baseada no Android Componentes Service (conhecidos como HCE serviços). Uma das principais vantagens de um serviço é que ele pode ser executado no segundo plano sem interface do usuário. Essa é uma solução natural para muitos casos de HCE, aplicativos, 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 ainda não estiver em execução e executa a transação em segundo plano. Obviamente, você pode iniciar interfaces de usuário adicionais (como notificações ao usuário) do seu serviço quando apropriado.

Seleção de serviço

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

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

Grupos de AID

Em alguns casos, um serviço de HCE pode precisar registrar vários AIDs e ser definido como o manipulador padrão para todos os AIDs a fim de implementar uma determinada para o aplicativo. Alguns AIDs no grupo que vão para outro serviço não são suportados.

Uma lista de AIDs mantidos juntos é chamada de grupo de AIDs. Para todos os AIDs em um grupo de AIDs, o Android garante uma das seguintes opções:

• 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 o usuário preferiu outro serviço que solicitou um ou mais AIDs no seu grupo ).

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

Categorias e grupos de AID

Você pode associar cada grupo de AIDs a uma categoria. Isso permite que o Android agrupe Serviços de HCE juntos por categoria, e isso, por sua vez, permite que o usuário defina padrões no nível da categoria e não do AID. Evitar mencionar AIDs em qualquer parte do aplicativo voltada ao usuário, porque elas não significam nada para o usuário médio.

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

• CATEGORY_PAYMENT (abrangendo apps de pagamento padrão do setor)
• CATEGORY_OTHER (para todos os outros apps HCE)

.

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

Para apps de pagamento de sistema fechado que só funcionam em um comerciante (como cartões de valor armazenado), use CATEGORY_OTHER. Grupos de AID em esta categoria pode estar sempre ativa e receber prioridade por NFC leitores durante a seleção do AID, se necessário.

Implementar um serviço de HCE

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

Verificar o suporte a HCE

Seu aplicativo pode verificar se um dispositivo é compatível com HCE verificando a presença FEATURE_NFC_HOST_CARD_EMULATION . Usar o <uses-feature> no manifesto do aplicativo para declarar que ele usa a HCE recurso e se ele é necessário para o funcionamento do aplicativo.

Implementação do serviço

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

A primeira etapa é estender HostApduService, conforme mostrado no código abaixo. amostra:

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

Observação :a especificação ISO/IEC 7816-4 também define o conceito de múltiplas canais lógicos, o que permite que você tenha várias APDUs paralelas em canais lógicos separados. com a implementação HCE do Android, oferece suporte a apenas um canal lógico, então há apenas uma troca de APDUs com um único thread.

Como mencionado anteriormente, o Android usa o AID para determinar qual serviço de HCE o o leitor quer falar. Normalmente, a primeira APDU que um leitor de NFC envia para o o dispositivo for uma APDU SELECT AID; essa APDU contém o AID que o leitor deseja conversar. O Android extrai esse AID da APDU e o resolve para uma HCE e depois encaminha essa APDU para o serviço resolvido.

Você pode enviar uma APDU de resposta retornando os bytes da APDU de resposta do processCommandApdu(): Esse método é chamado na linha de execução principal do seu aplicativo, o que não deve ser bloqueado. Se não for possível calcular e retornar uma APDU de resposta imediatamente, retorna nulo. Você pode então fazer o trabalho necessário outra linha de execução e usar o sendResponseApdu() definido na classe HostApduService para enviar a resposta quando você estiver feito.

O Android continua encaminhando novas APDUs do leitor para seu serviço até que do seguinte acontece:

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

Em ambos os casos, o método onDeactivated() é chamado com um argumento indicando qual dos dois aconteceu.

Se você estiver trabalhando com uma infraestrutura de leitor existente, deverá implementar o protocolo existente no nível do aplicativo que os leitores esperam no seu serviço HCE.

Se você estiver implantando uma nova infraestrutura de leitores que você também controla, você pode definir seu próprio protocolo e sequência de APDU. Tentar limitar a quantidade de APDUs e o tamanho dos dados a serem trocados: isso garante que seus usuários tenham para manter o dispositivo sobre o leitor de NFC por um curto período. Um o limite superior razoável é de 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

Você precisa declarar o serviço no manifesto como de costume, mas precisa adicionar algumas partes adicionais da declaração do serviço:

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

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

3. Defina o atributo android:exported como true e exija a android.permission.BIND_NFC_SERVICE na declaração do serviço. O primeiro garante que o serviço possa ser vinculado por apps externos. O segundo aplica que apenas os aplicativos externos que contêm a A permissão android.permission.BIND_NFC_SERVICE pode se vincular ao seu serviço. Como android.permission.BIND_NFC_SERVICE é uma permissão do sistema, ela garante que apenas o SO Android possa 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 exemplo desse tipo de 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>. que contém 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 seja desbloqueado antes que você invoque esse serviço para lidar com APDUs.

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

• Conter um atributo android:description que contenha um atributo descrição do grupo de AIDs, adequada para exibição na interface.
• Ter o atributo android:category definido para indicar a categoria do AID grupo pertence, como as constantes de string definidas por CATEGORY_PAYMENT ou CATEGORY_OTHER.
• Conter uma ou mais tags <aid-filter>, cada uma contendo um único AID. Especifique o AID em formato hexadecimal e certifique-se de que ele contenha uma sequência de caracteres.

Seu aplicativo também precisa conter o Permissão do 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. o mesmo AID pode ser registrado por mais de um serviço. O Android resolve o AID entra em conflito de maneira diferente, dependendo da categoria à qual o AID pertence. Cada podem ter uma política de resolução de conflitos diferente.

Para algumas categorias, como pagamento, o usuário pode selecionar um padrão na IU de configurações do Android. Para outras categorias, a política pode ser sempre pergunte ao usuário qual serviço invocar em caso de conflito. Para 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 um determinada categoria usando o isDefaultServiceForCategory() API.

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

Apps de pagamento

O Android considera serviços de HCE que declararam um grupo de AIDs com a payment como apps de pagamento. O Android 4.4 e versões mais recentes contêm um entrada do menu Configurações de nível superior chamada tap & pay, que enumera todos esses aplicativos de pagamento. Nesse menu de configurações, o usuário pode selecionar a opção aplicativo de pagamento padrão a ser invocado quando um terminal de pagamento é tocado.

Recursos obrigatórios para apps de pagamento

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

Android 13 e versões mais recentes

Para se adequar melhor à lista de seleção de pagamento padrão na interface de configurações, ajuste o requisito de banner para um ícone quadrado. O ideal é que ela seja idêntica à design de ícone na tela de início do aplicativo. Esse ajuste cria mais consistência um visual mais limpo.

Android 12 e versões anteriores

Definir o tamanho do banner de serviço como 260x96 dp e, em seguida, definir o tamanho do banner de serviço no arquivo XML de metadados adicionando o atributo android:apduServiceBanner a tag <host-apdu-service>, que aponta para o recurso drawable. A 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 executada no o dispositivo.

Android 12 e versões mais recentes

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

Android 10 e versões mais recentes

Dispositivos com suporte ao Android 10 (nível 29 da API) ou mais recente Seguro NFC Enquanto está seguro A NFC está ativada, todos os emuladores de cartões (aplicativos host e apps fora do host) estão ficará indisponível quando a tela do dispositivo estiver desligada. Enquanto a NFC segura estiver desativada, fora do host aplicativos ficam disponíveis quando a tela do dispositivo está desligada. É possível verificar Suporte a NFC segura usando isSecureNfcSupported()

Em dispositivos com o Android 10 e versões mais recentes, a mesma funcionalidade para configurar O android:requireDeviceUnlock a true se aplica aos dispositivos executando o Android 9 e versões anteriores, mas somente quando a NFC segura estiver desativada. Ou seja, se A NFC segura está ativada, os serviços de HCE não funcionam 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 NFC e o processador do aplicativo são desligados completamente quando a tela do dispositivo estiver desligado. Portanto, os serviços de HCE não funcionam quando a tela está desligada.

Além disso, 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 a 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 é invocado mesmo se o dispositivo estiver bloqueado.

Se você definir o atributo android:requireDeviceUnlock como true para sua HCE serviço, o Android solicita que o usuário desbloqueie o dispositivo quando: acontecer:

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

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

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

Esta seção é do interesse de desenvolvedores que implantaram um aplicativo que depende de um elemento de segurança para a emulação de cartão. Implementação de HCE do Android foi desenvolvido para funcionar em paralelo com outros métodos de implementação de cartões incluindo o uso de elementos de segurança.

Observação: o Android não oferece APIs para se comunicar diretamente com um provedor o próprio elemento.

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

Quando o leitor de NFC envia uma APDU com um SELECT AID, o controlador de NFC analisa e verifica se os AIDs correspondem a algum AID em sua tabela de roteamento. Se corresponde, que a APDU e todas as APDUs seguintes são enviadas para o destino associado ao AID, até que outra APDU SELECT AID seja recebida ou a NFC link está corrompido.

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

A Figura 4 ilustra essa arquitetura:

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 O AID não é encontrado na tabela de roteamento. A rota padrão é usada. Embora isso pode ser diferente para cada dispositivo, é necessário usar dispositivos Android para garantir que os AIDs registrados pelo seu app sejam roteados corretamente para o host.

Aplicativos Android que implementam um serviço de HCE ou que usam um elemento de segurança não se preocupe em configurar a tabela de roteamento. que é gerenciado pela o Android automaticamente. O Android só precisa saber quais AIDs podem ser tratados pelos serviços de HCE e quais podem ser tratados pelo elemento de segurança. O roteamento é configurada automaticamente com base nos serviços instalados e que o usuário configurou como preferencial.

A seção a seguir explica como declarar AIDs para aplicativos que usam uma 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 uma serviço off-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 da seguinte forma:

• A ação usada no filtro de intent precisa ser definida como SERVICE_INTERFACE
• O atributo de nome de metadados deve 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>
  

Este é um exemplo do arquivo apduservice.xml correspondente registrar 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 for bloqueada.

O atributo android:apduServiceBanner é obrigatório para serviços fora do host que são aplicativos de pagamento e podem ser selecionados como pagamento padrão para o aplicativo.

Invocação de serviço fora do host

O Android nunca inicia nem é vinculado 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 o serviço do Android. A declaração do serviço apenas permite que os aplicativos registrar os AIDs presentes no elemento de segurança.

HCE e segurança

A arquitetura HCE oferece uma parte essencial da segurança: como seus é protegido pela BIND_NFC_SERVICE permissão do sistema, somente o SO pode se vincular ao serviço e se comunicar com ele. Isso garante que qualquer APDU recebida seja realmente uma APDU recebida pelo o sistema operacional do controlador de NFC e que qualquer APDU enviada vá apenas para que, por sua vez, encaminha diretamente as APDUs para o controlador de NFC.

A última preocupação é com a localização dos dados que o app envia ao leitor de NFC. Isso é intencionalmente desacoplado no design de HCE; ele faz não importa de onde vêm os dados, ele apenas garante que estão em segurança transportado 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 seu HCE você pode, por exemplo, confiar no Sandbox de aplicativos do Android, que isola os dados do seu app de outros apps. Para mais detalhes sobre o Android, da segurança, leia as Dicas de segurança.

Parâmetros de protocolo e detalhes

Esta seção é interessante para desenvolvedores que querem entender qual protocolo parâmetros que os dispositivos HCE usam durante as fases de anticolisão e ativação do 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 apresenta seu UID; Dispositivos HCE deve 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 devem depender do UID de dispositivos HCE como uma forma de ou identificação pessoal.

Em seguida, o leitor de NFC pode selecionar o dispositivo HCE enviando um SEL_REQ kubectl. A resposta SEL_RES do dispositivo HCE tem pelo menos o 6o bit (0x20), indicando que o dispositivo é compatível com ISO-DEP. Observe que outras partes o SEL_RES também pode ser definido, indicando, por exemplo, a compatibilidade com o protocolo NFC-DEP (p2p). Como outros bits podem ser definidos, os leitores que desejam interagir Os dispositivos HCE devem verificar explicitamente apenas o sexto bit e não comparar. a SEL_RES completa com um valor de 0x20.

Ativação de ISO-DEP

Depois que o protocolo Nfc-A é ativado, o leitor de NFC inicia a operação ISO-DEP com a ativação do protocolo. Ele envia uma solicitação de resposta para seleção (RATS, na sigla em inglês) kubectl. O controlador de NFC gera a resposta RATS, a ATS; o ATS não é pode ser configurado por serviços HCE. No entanto, as implementações de HCE devem atender ao Fórum NFC para a resposta ATS, de modo que os leitores de NFC possam contar com esses parâmetros 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 do arquivo ATS resposta 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 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 do FSCI deve ser entre 0h e 8h.
• T(A)1: define as taxas de bits entre o leitor e o emulador, e se elas podem ser assimétrica. 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). Ativado Dispositivos HCE, o SFGI precisa ser <= 8h. Os bits 5 a 8 indicam o frame em espera time Integer (FWI) e codifica o tempo de espera do frame (FWT). Em dispositivos HCE, FWI deve 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 compatibilidade para DID. Os dispositivos HCE podem ou não ser compatíveis com DID. O bit 1 indica suporte a 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. NFC os leitores 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.

Muitos dispositivos HCE provavelmente são compatíveis com os requisitos de protocolo que as redes de pagamentos unidas na EMVCo especificaram nos seus "Por aproximação protocolo de comunicação" especificação. Especificamente, as seguintes:

• O FSCI em T0 precisa estar entre 2h e 8h.
• T(A)1 deve ser definido como 0x80, indicando que apenas a taxa de bits de 106 kbit/s é e as taxas de bits assimétricas entre o leitor e o emulador não são suporte.
• 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 aplicativos em canais lógicos diferentes não funciona um dispositivo HCE.