Panoramica dell'emulazione della carta basata su host

Molti dispositivi Android che offrono la funzionalità NFC supportano già la tecnologia NFC dell'emulazione delle schede. Nella maggior parte dei casi, la carta viene emulata da un chip separato nella chiamato secure Element. Molte schede SIM fornite da operatori wireless e un elemento di sicurezza.

Android 4.4 e versioni successive offrono un ulteriore metodo di emulazione delle schede che non prevede un elemento sicuro, chiamato emulazione delle carte basata su host. Questo consente a qualsiasi applicazione Android di emulare una carta e di comunicare direttamente con l'NFC Reader. Questo argomento descrive come funziona l'emulazione di schede basata su host (HCE) su Android e spiega come sviluppare un'app che emula una carta NFC. tecnica.

Emulazione della carta con un elemento di sicurezza

Quando l'emulazione della carta NFC viene fornita utilizzando un elemento di sicurezza, la carta da emulato viene eseguito il provisioning nell'elemento sicuro sul dispositivo tramite un'applicazione. Quindi, quando l'utente tiene il dispositivo vicino a un terminale NFC, la tecnologia NFC il controller nel dispositivo indirizza tutti i dati dal lettore direttamente alla piattaforma . La Figura 1 illustra questo concetto:

e
Figura 1. Emulazione di carte NFC con un elemento di sicurezza.

L'elemento di sicurezza stesso effettua la comunicazione con il terminale NFC e nessuna applicazione Android è coinvolta nella transazione. Al termine della transazione completi, un'applicazione Android può interrogare l'elemento secure direttamente per lo stato della transazione e avvisa l'utente.

Emulazione delle carte basata su host

Quando una carta NFC viene emulata utilizzando l'emulazione di carte basata sull'host, i dati vengono indirizzati direttamente alla CPU host anziché essere instradati a un elemento sicuro. Figura 2 illustra come funziona l'emulazione di schede basate su host:

e
Figura 2. Emulazione di carte NFC senza un elemento di sicurezza.

Carte e protocolli NFC supportati

e
Figura 3. Stack di protocolli HCE di Android.

Gli standard NFC offrono supporto per molti protocolli diversi e diversi tipi di carte che puoi emulare.

Android 4.4 e versioni successive supporta diversi protocolli comuni sul mercato oggi stesso. Molte carte contactless esistenti si basano già su questi protocolli, come le carte di pagamento contactless. Questi protocolli sono supportati anche da molti Lettori NFC oggi disponibili sul mercato, compresi i dispositivi Android NFC che funzionano come gli stessi lettori (consulta le IsoDep . Ciò consente di creare e implementare una soluzione NFC end-to-end HCE che utilizza solo dispositivi basati su Android.

In particolare, Android 4.4 e versioni successive supporta l'emulazione di schede basate su la specifica ISO-DEP dell'NFC-Forum (basata su ISO/IEC 14443-4) e il processo Application Protocol Data Unit (APDU) come definito nella norma ISO/IEC 7816-4 e la specifica del prodotto. Android impone l'emulazione di ISO-DEP solo sopra l'NFC-A (ISO/IEC 14443-3 Tipo A). Supporto per Nfc-B (ISO/IEC 14443-4 Tipo B) tecnologia è facoltativa. La figura 3 illustra la sovrapposizione di tutti questi elementi specifiche.

Servizi HCE

L'architettura HCE in Android è basata su Android Componenti di Service (noti come HCE) Google Cloud). Uno dei principali vantaggi di un servizio è che può essere eseguito senza alcuna interfaccia utente. Si tratta di una soluzione naturale per molte HCE come carte fedeltà o carte del trasporto pubblico, di cui l'utente non dovrebbe avere bisogno avviare un'app da utilizzare. Se metti il dispositivo a contatto con il lettore NFC, il servizio corretto se non è già in esecuzione ed esegue la transazione in background. Ovviamente puoi avviare altre UI (come notifiche utente) dal tuo servizio quando opportuno.

Selezione del servizio

Quando l'utente mette un dispositivo a contatto con un lettore NFC, il sistema Android deve con quale servizio HCE il lettore NFC vuole comunicare. ISO/IEC 7816-4 specifica un modo per selezionare le applicazioni, incentrato su un ID applicazione (AID). Un AID può contenere fino a 16 byte. Se stai emulando carte per un'infrastruttura di lettori NFC esistente, gli AID che tali lettori cercano sono in genere note e registrate pubblicamente (ad esempio, AID delle reti di pagamento come Visa e MasterCard).

Se vuoi eseguire il deployment di una nuova infrastruttura di lettori per la tua applicazione, registrare il proprio AID. La procedura di registrazione per gli AID è definita la specifica ISO/IEC 7816-5. Ti consigliamo di registrare un AID come da 7816-5 se esegui il deployment di un'applicazione HCE per Android, perché evita collisioni con altre applicazioni.

Gruppi AID

In alcuni casi, un servizio HCE potrebbe dover registrare più AID ed essere impostato come il gestore predefinito per tutti gli AID al fine di implementare un un'applicazione. Alcuni AID del gruppo che passano a un altro servizio non sono supportati.

Un elenco di AID riuniti è chiamato gruppo AID. Per tutti gli AID in un Gruppo AID, Android garantisce una delle seguenti opzioni:

• Tutti gli AID del gruppo vengono instradati a questo servizio HCE.
• Nessun AID nel gruppo viene instradato a questo servizio HCE (ad esempio, perché l'utente ha preferito un altro servizio che ha richiesto uno o più AID nel tuo gruppo ).

In altre parole, non esiste uno stato intermedio, in cui alcuni AID del gruppo possono a un servizio HCE e altri a un altro.

Gruppi e categorie di AID

Puoi associare ogni gruppo AID a una categoria. In questo modo Android può raggruppare i servizi HCE insieme per categoria e questo, a sua volta, consente all'utente di impostare valori predefiniti a livello di categoria anziché a livello di AID. Evita di menzionare gli AID in qualsiasi parte dell'applicazione rivolta all'utente, perché non significano nulla per l'utente medio.

Android 4.4 e versioni successive supportano due categorie:

• CATEGORY_PAYMENT (relative alle app di pagamento standard del settore)
• CATEGORY_OTHER (per tutte le altre app HCE)

di Gemini Advanced.

Nota: è possibile attivare un solo gruppo AID della categoria CATEGORY_PAYMENT in il sistema in qualsiasi momento. In genere, si tratta di un'app conosce i principali protocolli di pagamento con carta di credito e può funzionare con commerciante.

Per le app di pagamento a circuito chiuso che funzionano solo per un commerciante (come le carte con valore monetario), usa CATEGORY_OTHER. Gruppi AID in questa categoria può essere sempre attiva e può essere data la priorità tramite NFC lettori durante la selezione dell'AID, se necessario.

Implementazione di un servizio HCE

Per emulare una carta NFC utilizzando l'emulazione di carte basata sull'host, devi creare un'opzione Componente Service che gestisce le transazioni NFC.

Verificare il supporto dell'HCE

La tua applicazione può verificare se un dispositivo supporta la tecnologia HCE controllando la presenza del FEATURE_NFC_HOST_CARD_EMULATION funzionalità. Utilizza la <uses-feature> nel manifest dell'applicazione per dichiarare che l'app utilizza il protocollo HCE e se è necessario per il funzionamento dell'app.

Implementazione del servizio

Android 4.4 e versioni successive offre una lezione Service di convenienza che puoi utilizzare come base per l'implementazione di un servizio HCE: HostApduService.

Il primo passaggio consiste nell'estensione di HostApduService, come mostrato nel seguente codice esempio:

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 dichiara due metodi astratti che devi sostituire e da implementare. Uno di questi, processCommandApdu(), viene chiamato ogni volta che un lettore NFC invia un'Application Protocol Data Unit (APDU) al tuo servizio. Le APDU sono definite nella specifica ISO/IEC 7816-4. APDU sono i pacchetti a livello di applicazione che vengono scambiati tra il lettore NFC del tuo servizio HCE. Il protocollo a livello di applicazione è Half-duplex: il lettore NFC. ti invia un comando APDU e attende che tu invii una risposta APDU in per tornare indietro.

Nota: la specifica ISO/IEC 7816-4 definisce anche il concetto di più canali logici, che consentono di avere più APDU paralleli scambi su canali logici separati. l'implementazione HCE di Android, ma supporta un solo canale logico, quindi c'è scambio di APDU a thread unico.

Come accennato in precedenza, Android utilizza l'AID per determinare quale servizio HCE deve lettore vuole parlare. In genere, la prima APDU che un lettore NFC invia al tuo il dispositivo è un APDU SELECT AID; questo APDU contiene l'AID che il lettore vuole con cui parlare. Android estrae questo AID dall'APDU e lo risolve in un HCE e poi inoltra l'APDU al servizio risolto.

Puoi inviare un'APDU di risposta restituendo i byte dell'APDU della risposta da processCommandApdu(). Tieni presente che questo metodo viene chiamato nel thread principale dell'applicazione, che non dovresti bloccare. Se non riesci a calcolare e restituire immediatamente un APDU di risposta, restituirà null. Puoi quindi svolgere le operazioni necessarie in un altro thread e utilizza sendResponseApdu() definito nella classe HostApduService per inviare la risposta quando fatto.

Android continua a inoltrare le nuove APDU dal lettore al servizio finché si verifica quanto segue:

• Il lettore NFC invia un'altra APDU SELECT AID, che il sistema operativo risolve in una un servizio diverso.
• Il collegamento NFC tra il lettore NFC e il dispositivo non funziona.

In entrambi i casi, il nome del corso onDeactivated() viene richiamata con un argomento che indica quale dei due si è verificato.

Se utilizzi un'infrastruttura di lettori esistente, devi implementare il parametro protocollo esistente a livello di applicazione che i lettori si aspettano nel tuo servizio HCE.

Se esegui il deployment di una nuova infrastruttura di lettori che puoi controllare, puoi definire il tuo protocollo e la sequenza APDU. Cerca di limitare il numero di APDU e la dimensione dei dati da scambiare: in questo modo gli utenti avranno solo di tenere il dispositivo vicino al lettore NFC per un breve periodo di tempo. R ragionevole è di circa 1 kB di dati, che in genere possono essere scambiato entro 300 ms.

Dichiarazione relativa al file manifest del servizio e registrazione AID

Devi dichiarare il servizio nel file manifest come di consueto, ma devi aggiungerne alcuni anche alcune parti aggiuntive della dichiarazione relativa al servizio:

1. Per indicare alla piattaforma che si tratta di un servizio HCE che implementa HostApduService, aggiungi un filtro per intent per SERVICE_INTERFACE alla tua dichiarazione del servizio.

2. Per indicare alla piattaforma i gruppi di AID richiesti da questo servizio, includi un SERVICE_META_DATA <meta-data> nella dichiarazione del servizio, che rimanda a un file XML risorsa con informazioni aggiuntive sul servizio HCE.

3. Imposta l'attributo android:exported su true e richiedi il android.permission.BIND_NFC_SERVICE nella tua dichiarazione del servizio. La prima garantisce che il servizio possa essere associato ad applicazioni esterne. Quest'ultimo impone quindi che solo le applicazioni esterne L'autorizzazione android.permission.BIND_NFC_SERVICE può essere associata al tuo servizio. Poiché android.permission.BIND_NFC_SERVICE è un'autorizzazione di sistema, questa applica in modo efficace che solo il sistema operativo Android può collegarsi al tuo servizio.

Di seguito è riportato un esempio di dichiarazione del file manifest 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>

Questo tag di metadati rimanda a un file apduservice.xml. Di seguito è riportato un esempio di un file di questo tipo con una singola dichiarazione del gruppo AID contenente due AID proprietari:

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

Il tag <host-apdu-service> deve contenere un attributo <android:description> che contenga una descrizione semplice del servizio che puoi mostrare l'interfaccia utente dell'app. Puoi utilizzare l'attributo requireDeviceUnlock per specificare che il dispositivo viene sbloccato prima che tu richiami questo servizio per gestire le APDU.

<host-apdu-service> deve contenere uno o più tag <aid-group>. Ciascuna Il tag <aid-group> è necessario per:

• Contenere un attributo android:description che contiene un descrizione del gruppo AID, idoneo alla visualizzazione nell'interfaccia utente.
• L'attributo android:category deve essere impostato per indicare la categoria dell'AID a cui appartiene un gruppo, come le costanti stringa definite da CATEGORY_PAYMENT o CATEGORY_OTHER.
• Contenere uno o più tag <aid-filter>, ognuno dei quali contiene un singolo AID. Specifica l'AID in formato esadecimale e assicurati che contenga un numero di caratteri.

La tua applicazione deve contenere anche Autorizzazione NFC per la registrazione come servizio HCE.

Risoluzione dei conflitti di AID

È possibile installare più componenti di HostApduService su un singolo dispositivo e lo stesso AID può essere registrato da più di un servizio. Android risolve l'AID conflitti in modo diverso a seconda della categoria a cui appartiene un AID. Ciascuna potrebbero avere norme diverse per la risoluzione dei conflitti.

Per alcune categorie, come i pagamenti, gli utenti potrebbero essere in grado di selezionare un'impostazione predefinita nell'interfaccia utente delle impostazioni di Android. Per altre categorie, le norme potrebbero prevedere chiedi sempre all'utente quale servizio richiamare in caso di conflitto. Per informazioni su come eseguire query sul criterio di risoluzione dei conflitti per una determinata categoria, consulta getSelectionModeForCategory()

Verificare se il servizio è quello predefinito

Le applicazioni possono verificare se il proprio servizio HCE è quello predefinito per una determinata categoria utilizzando isDefaultServiceForCategory() tramite Google Cloud CLI o tramite l'API Compute Engine.

Se il tuo servizio non è quello predefinito, puoi richiederlo utilizzando ACTION_CHANGE_DEFAULT

Applicazioni di pagamento

Android prende in considerazione i servizi HCE che hanno dichiarato un gruppo AID con il payment come applicazioni di pagamento. Android 4.4 e versioni successive contiene un voce di menu Impostazioni di primo livello denominata tocca e pay, che elenca tutte le tali applicazioni di pagamento. In questo menu delle impostazioni, l'utente può selezionare applicazione di pagamento predefinita da richiamare quando viene toccato un terminale di pagamento.

Asset richiesti per le applicazioni di pagamento

Per offrire un'esperienza utente più accattivante, le applicazioni di pagamento HCE per fornire un banner del servizio.

Android 13 e versioni successive

Per adattarlo meglio all'elenco di selezione dei pagamenti predefinito nell'interfaccia utente delle Impostazioni, modifica le requisito del banner a un'icona quadrata. Idealmente, dovrebbe essere identico al icona di avvio applicazioni. Questo aggiustamento crea maggiore coerenza e un look più pulito.

Android 12 e versioni precedenti

Imposta le dimensioni del banner di servizio su 260 x 96 dp, quindi imposta le dimensioni del banner di servizio nel file XML dei metadati aggiungendo l'attributo android:apduServiceBanner a il tag <host-apdu-service>, che punta alla risorsa drawable. La Ecco un esempio:

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

Comportamento schermo spento e blocco schermo

Il comportamento dei servizi HCE varia in base alla versione di Android in esecuzione su del dispositivo.

Android 12 e versioni successive

Nelle app destinate ad Android 12 (livello API 31) e versioni successive, puoi attivare NFC. i pagamenti senza lo schermo del dispositivo attivo impostando Da requireDeviceScreenOn a false.

Android 10 e versioni successive

Supporto per dispositivi con Android 10 (livello API 29) o versioni successive Sicuro NFC. Durante la sicurezza L'NFC è attivo, tutti gli emulatori di carte (applicazioni host e applicazioni esterne all'host) non è disponibile quando lo schermo del dispositivo non è attivo. Quando l'opzione NFC sicuro è disattivata, fuori dall'host sono disponibili anche quando lo schermo del dispositivo non è attivo. Puoi verificare Supporto NFC sicuro con isSecureNfcSupported()

Sui dispositivi con Android 10 e versioni successive, la stessa funzionalità per l'impostazione Da android:requireDeviceUnlock a true si applica come per i dispositivi con Android 9 e versioni precedenti, ma solo quando l'opzione NFC sicuro è disattivata. Ossia, se L'opzione NFC sicuro è attiva, i servizi HCE non possono funzionare dalla schermata di blocco a prescindere dall'impostazione di android:requireDeviceUnlock.

Android 9 e versioni precedenti

Sui dispositivi con Android 9 (livello API 28) e versioni precedenti, il controller NFC e il processore dell'applicazione viene spento quando lo schermo è spento. Di conseguenza, i servizi HCE non funzionano quando lo schermo non è attivo.

Sempre su Android 9 e versioni precedenti, i servizi HCE possono funzionare dalla schermata di blocco. Tuttavia, ciò è controllato dall'attributo android:requireDeviceUnlock in il tag <host-apdu-service> del tuo servizio HCE. Per impostazione predefinita, lo sblocco del dispositivo è non richiesto e il servizio viene richiamato anche se il dispositivo è bloccato.

Se imposti l'attributo android:requireDeviceUnlock su true per HCE Android chiede all'utente di sbloccare il dispositivo quando: avvengono nel seguente modo:

• l'utente tocca un lettore NFC.
• il lettore NFC seleziona un AID già associato al tuo servizio.

Dopo lo sblocco, Android mostra una finestra di dialogo che chiede all'utente di toccare di nuovo per completare la transazione. Questa operazione è necessaria perché l'utente potrebbe aver spostato allontana il dispositivo dal lettore NFC per poterlo sbloccare.

Coesistenza con le schede Secure Element

Questa sezione è di interesse per gli sviluppatori che hanno eseguito il deployment di un'applicazione che si basa su un Secure Element per l'emulazione delle carte. Implementazione HCE di Android è progettato per funzionare in parallelo con altri metodi di implementazione della scheda dell'emulazione, compreso l'uso di elementi sicuri.

Nota: Android non offre API per comunicare direttamente con un dell'elemento stesso.

Questa coesistenza si basa su un principio chiamato routing AID. NFC mantiene una tabella di routing composta da un elenco (finito) di routing le regole del caso. Ogni regola di routing contiene un AID e una destinazione. La destinazione può essere la CPU host su cui sono in esecuzione le app Android o un .

Quando il lettore NFC invia una APDU con un SELECT AID, il controller NFC analizza e verifica se l'AID corrisponde a un AID nella relativa tabella di routing. Se corrisponde, l'APDU e tutte le APDU che lo seguono vengono inviati alla destinazione associato all'AID, fino a quando non riceverà un'altra APDU SELECT AID o l'NFC il link non funziona.

Nota: sebbene lo standard ISO/IEC 7816-4 definisca anche il concetto di corrispondenze parziali, questa funzionalità non è supportata dai dispositivi Android HCE.

La Figura 4 illustra questa architettura:

e
Figura 4. Android che utilizza l'emulazione di Secure Element e di schede host.

Il controller NFC in genere contiene anche un percorso predefinito per gli APDU. Quando AID non trovato nella tabella di routing; viene utilizzata la route predefinita. Anche se questo l'impostazione potrebbe essere diversa da un dispositivo all'altro, sono necessari dispositivi Android per assicurarti che gli AID registrati dalla tua app vengano indirizzati correttamente al .

App per Android che implementano un servizio HCE o che utilizzano un Secure Element non devi preoccuparti di configurare la tabella di routing: gestita dal Android automaticamente. Android deve solo sapere quali AID possono essere gestiti dai servizi HCE e quali possono essere gestiti dall'elemento sicuro. Il percorso viene configurata automaticamente in base ai servizi installati che l'utente ha configurato come preferito.

La sezione seguente spiega come dichiarare gli AID per le applicazioni che utilizzano un Secure Element per emulazione delle carte.

Registrazione AID Secure Element

Le applicazioni che utilizzano un Secure Element per l'emulazione di carte possono dichiarare un off-host service nel file manifest. La dichiarazione relativa a tale servizio è quasi identica alla dichiarazione di un servizio HCE. Le eccezioni sono che segue:

• L'azione utilizzata nel filtro per intent deve essere impostata su SERVICE_INTERFACE
• L'attributo nome meta-data deve essere impostato su SERVICE_META_DATA

• Il file XML di metadati deve utilizzare il tag principale <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>
  

Di seguito è riportato un esempio del file apduservice.xml corrispondente registrare due 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>

L'attributo android:requireDeviceUnlock non si applica ai servizi esterni all'host, perché la CPU host non è coinvolta nella transazione e quindi non può impedisce all'elemento sicuro di eseguire transazioni quando il dispositivo viene bloccato.

L'attributo android:apduServiceBanner è obbligatorio per i servizi esterni all'host che sono applicazioni di pagamento selezionabili come metodo di pagamento predefinito un'applicazione.

Chiamata al servizio fuori dall'host

Android non si avvia o non si collega mai a un servizio dichiarato come "off-host" perché le transazioni effettive vengono eseguite dall'elemento sicuro e non il servizio Android. La dichiarazione del servizio consente semplicemente alle applicazioni di registrare gli AID presenti sull’elemento di sicurezza.

HCE e sicurezza

L'architettura HCE offre una componente di sicurezza fondamentale: è protetto dal BIND_NFC_SERVICE autorizzazione di sistema, solo il sistema operativo può associarsi al tuo servizio e comunicare con quest'ultimo. Ciò garantisce che qualsiasi APDU ricevuto sia effettivamente un APDU ricevuto il sistema operativo dal controller NFC e che ogni APDU che invii venga il sistema operativo, che a sua volta inoltra direttamente le APDU al controller NFC.

L'ultimo problema riguarda il recupero dei dati inviati dall'app al lettore NFC. Questo viene intenzionalmente disaccoppiato nel design HCE. sì non importa da dove provengono i dati, si assicura solo che siano al sicuro viene inviato al controller NFC per poi inviarlo al lettore NFC.

Per archiviare e recuperare in modo sicuro i dati che vuoi inviare da HCE puoi fare affidamento, ad esempio, sulla sandbox delle applicazioni per Android, isola i dati dell'app da altre app. Per maggiori dettagli su Android sicurezza, leggi Suggerimenti per la sicurezza.

Parametri e dettagli del protocollo

Questa sezione è di interesse per gli sviluppatori che vogliono capire quale protocollo parametri utilizzati dai dispositivi HCE durante le fasi di anticollisione e attivazione del i protocolli NFC. Ciò consente di creare un'infrastruttura di lettura compatibile con i dispositivi Android HCE.

Anti-collisione e attivazione del protocollo Nfc-A (ISO/IEC 14443 tipo A)

Nell'ambito dell'attivazione del protocollo Nfc-A, vengono scambiati più frame.

Nella prima parte della sostituzione, il dispositivo HCE presenta il proprio UID; Dispositivi HCE si presume che abbia un UID casuale. Ciò significa che a ogni tocco l'UID presentato al lettore è un UID generato in modo casuale. Per questo motivo, I lettori NFC non devono dipendere dall'UID dei dispositivi HCE come forma di l'autenticazione o l'identificazione.

Il lettore NFC può successivamente selezionare il dispositivo HCE inviando un SEL_REQ . La risposta SEL_RES del dispositivo HCE ha almeno il 6° bit (0x20) impostato, che indica che il dispositivo supporta ISO-DEP. Tieni presente che gli altri bit in è possibile impostare anche SEL_RES, che indica, ad esempio, il supporto per NFC-DEP (p2p). Dato che possono essere impostati altri bit, i lettori che vogliono interagire I dispositivi HCE devono verificare esplicitamente solo il sesto bit e non confrontare il SEL_RES completo con un valore di 0x20.

Attivazione del servizio ISO-DEP

Dopo l'attivazione del protocollo Nfc-A, il lettore NFC avvia il processo ISO-DEP l'attivazione del protocollo. Invia un RATS (richiesta di risposta da selezionare) . Il controller NFC genera la risposta RATS, ovvero ATS; l'ATS non è configurabili dai servizi HCE. Tuttavia, le implementazioni HCE devono rispettare l'NFC Forum requisiti per la risposta ATS, in modo che i lettori NFC possano contare su questi parametri essere impostati in conformità ai requisiti dell'NFC Forum per qualsiasi dispositivo HCE.

La sezione che segue fornisce ulteriori dettagli sui singoli byte dell'ATS. risposta fornita dal controller NFC su un dispositivo HCE:

• TL: durata della risposta ATS. Non deve indicare una lunghezza superiore a 20 byte.
• T0: su tutti i dispositivi HCE devono essere impostati i bit 5, 6 e 7, indicando TA(1), TB(1) e TC(1) sono inclusi nella risposta ATS. I bit da 1 a 4 indicano l'FSCI, codificando la dimensione massima del fotogramma. Sui dispositivi HCE, il valore di FSCI deve essere tra 0 h e 8 h.
• T(A)1: definisce la velocità in bit tra il lettore e l'emulatore e indica se possono essere asimmetrico. Non esistono requisiti di velocità in bit né garanzie per i dispositivi HCE.
• T(B)1: i bit da 1 a 4 indicano il numero intero di guardia del frame di avvio (SFGI). Attivato Dispositivi HCE, il valore SFGI deve essere <= 8 ore. I bit da 5 a 8 indicano il frame in attesa tempo intero (FWI) e codifica il tempo di attesa frame (FWT). Sui dispositivi HCE, FWI deve essere <= 8 h.
• T(C)1: il bit 5 indica il supporto per "Funzionalità avanzate di protocollo". Dispositivi HCE potrebbero supportare o meno le funzionalità Advanced Protocol. Il bit 2 indica un supporto per DID. I dispositivi HCE potrebbero supportare o meno il DID. Il bit 1 indica il supporto di ND. I dispositivi HCE non devono supportare NAD e impostare il bit 1 su zero.
• Byte storici: i dispositivi HCE possono restituire fino a 15 byte storici. Near Field Communication (NFC) lettori disposti a interagire con i servizi HCE non devono fare ipotesi i contenuti dei byte storici o la loro presenza.

Tieni presente che molti dispositivi HCE sono probabilmente resi conformi ai requisiti di protocollo che le reti di pagamento unite in EMVCo hanno specificato nel loro " Communication Protocol e la specifica del prodotto. In particolare:

• Il valore FSCI in T0 deve essere compreso tra 2 h e 8 h.
• T(A)1 deve essere impostato su 0x80, indicando che solo la velocità in bit di 106 kbit/s è e le velocità in bit asimmetriche tra lettore ed emulatore non sono supportate supportati.
• Il valore FWI in T(B)1 deve essere <= 7h.

Scambio di dati APDU

Come indicato in precedenza, le implementazioni HCE supportano un solo canale logico. Il tentativo di selezionare le applicazioni su canali logici diversi non funziona un dispositivo HCE.