Panoramica dell'emulazione della carta basata su host

Molti dispositivi Android che offrono la funzionalità NFC supportano già l'emulazione delle carte NFC. Nella maggior parte dei casi, la carta viene emulata da un chip separato nel dispositivo, chiamato secure element. Anche molte schede SIM fornite dagli operatori wireless contengono un Secure Element.

Android 4.4 e versioni successive offrono un ulteriore metodo di emulazione delle carte che non prevede un Secure Element, chiamato emulazione della carta basata sull'host. Ciò consente a qualsiasi applicazione Android di emulare una carta e comunicare direttamente con il lettore NFC. Questo argomento descrive come funziona l'emulazione della carta basata su host (HCE) su Android e come puoi sviluppare un'app che emula una carta NFC utilizzando questa tecnica.

Emulazione della carta con Secure Element

Quando l'emulazione della carta NFC viene fornita utilizzando un Secure Element, la carta da emulare viene sottoposta a provisioning in Secure Element sul dispositivo tramite un'applicazione Android. Quindi, quando l'utente mantiene il dispositivo su un terminale NFC, il controller NFC nel dispositivo instrada tutti i dati dal lettore direttamente all'elemento sicuro. La Figura 1 illustra questo concetto:

Figura 1. Emulazione di carte NFC con Secure Element.

Il Secure Element esegue la comunicazione con il terminale NFC e non è coinvolta nessuna applicazione Android nella transazione. Una volta completata la transazione, un'applicazione Android può richiedere direttamente lo stato della transazione al Secure Element e inviare una notifica all'utente.

Emulazione della carta basata su host

Quando una scheda NFC viene emulata mediante l'emulazione della scheda basata su host, i dati vengono instradati direttamente alla CPU host anziché a un Secure Element. La Figura 2 illustra come funziona l'emulazione della carta basata su host:

Figura 2. Emulazione di carte NFC senza Secure Element.

Protocolli e carte NFC supportati

Figura 3. Stack di protocollo HCE di Android.

Gli standard NFC supportano molti protocolli diversi e esistono diversi tipi di carte che puoi emulare.

Android 4.4 e versioni successive supportano diversi protocolli oggi comuni sul mercato. 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, inclusi i dispositivi NFC Android che funzionano come lettori (consulta la classe IsoDep). In questo modo puoi creare ed eseguire il deployment di una soluzione NFC end-to-end basata su HCE utilizzando solo dispositivi Android.

In particolare, Android 4.4 e versioni successive supporta l'emulazione di carte basate sulla specifica ISO-DEP del forum NFC (basata su ISO/IEC 14443-4) ed elabora le APDU (Application Protocol Data Unit), come definito nella specifica ISO/IEC 7816-4. Android impone di emulare l'ISO-DEP solo in aggiunta alla tecnologia Nfc-A (ISO/IEC 14443-3 Tipo A). Il supporto per la tecnologia Nfc-B (ISO/IEC 14443-4 Tipo B) è facoltativo. La Figura 3 illustra la sovrapposizione di tutte queste specifiche.

Servizi HCE

L'architettura HCE in Android si basa sui componenti Service di Android (noti come servizi HCE). Uno dei vantaggi principali di un servizio è che può essere eseguito in background senza alcuna interfaccia utente. Si tratta della scelta più naturale per molte applicazioni HCE, come carte fedeltà o tessere per il trasporto pubblico, che non devono essere usate dall'utente per lanciare un'app. Invece, se metti il dispositivo vicino al lettore NFC, viene avviato il servizio corretto, se non è già in esecuzione, ed esegue la transazione in background. Ovviamente sei libero di lanciare altre UI (ad esempio le notifiche per gli utenti) dal servizio, quando opportuno.

Selezione del servizio

Quando l'utente mette a contatto un dispositivo con un lettore NFC, il sistema Android deve sapere con quale servizio HCE il lettore NFC vuole comunicare. La specifica ISO/IEC 7816-4 definisce un modo per selezionare le applicazioni, incentrate su un ID applicazione (AID). Un AID è costituito da un massimo di 16 byte. Se stai emulando carte per un'infrastruttura di lettori NFC esistente, gli AID che quei lettori cercano sono in genere noti e registrati pubblicamente (ad esempio, gli AID di reti di pagamento come Visa e MasterCard).

Se vuoi eseguire il deployment di una nuova infrastruttura di lettori per la tua applicazione, devi registrare i tuoi AID. La procedura di registrazione degli AID è definita nella 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, poiché evita collisioni con altre applicazioni.

Gruppi di AID

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

Un elenco di AID che vengono tenuti insieme è chiamato gruppo AID. Per tutti gli AID in un gruppo AID, Android garantisce uno dei seguenti requisiti:

• 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, dove alcuni AID del gruppo possono essere instradati a un servizio HCE e altri a un altro.

Gruppi e categorie di AID

Puoi associare ciascun gruppo di AID a una categoria. In questo modo Android può raggruppare i servizi HCE per categoria e, a sua volta, l'utente può impostare i valori predefiniti a livello di categoria anziché a livello di AID. Evita di menzionare gli AID in tutte le parti dell'applicazione rivolte agli utenti, perché non significano nulla per l'utente medio.

Android 4.4 e versioni successive supportano due categorie:

• CATEGORY_PAYMENT (che riguarda le app di pagamento standard di settore)
• CATEGORY_OTHER (per tutte le altre app HCE)

Nota: è possibile abilitare nel sistema un solo gruppo di AID nella categoria CATEGORY_PAYMENT alla volta. In genere, si tratta di un'app che comprende i principali protocolli di pagamento con carta di credito e può funzionare con qualsiasi commerciante.

Per le app di pagamento a circuito chiuso che funzionano solo presso un commerciante (ad esempio le carte di credito prepagate), utilizza CATEGORY_OTHER. I gruppi di AID in questa categoria possono essere sempre attivi e possono ottenere la priorità dai lettori NFC durante la selezione dell'AID, se necessario.

Implementazione di un servizio HCE

Per emulare una carta NFC utilizzando l'emulazione della carta basata sull'host, devi creare un componente Service che gestisca le transazioni NFC.

Verifica la presenza di assistenza HCE

L'applicazione può verificare se un dispositivo supporta HCE controllando la funzionalità FEATURE_NFC_HOST_CARD_EMULATION. Utilizza il tag <uses-feature> nel manifest dell'applicazione per dichiarare che l'app utilizza la funzionalità HCE e se è necessaria o meno per il funzionamento dell'app.

Implementazione dei servizi

Android 4.4 e versioni successive offrono una classe Service di comodità che puoi utilizzare come base per l'implementazione di un servizio HCE: la classe HostApduService.

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

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 implementare. Uno di questi, processCommandApdu(), viene chiamato ogni volta che un lettore NFC invia una APDU (Application Protocol Data Unit) al tuo servizio. Le APDU sono definite nella specifica ISO/IEC 7816-4. Gli APDU sono i pacchetti a livello di applicazione che vengono scambiati tra il lettore NFC e il servizio HCE. Il protocollo a livello di applicazione è half-duplex: il lettore NFC invia un comando APDU e attende che l'utente invii una risposta APDU in cambio.

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

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

Puoi inviare una risposta APDU restituendo i byte della risposta APDU 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 una risposta APDU, restituisci null. Puoi quindi eseguire il lavoro necessario su un altro thread e utilizzare il metodo sendResponseApdu() definito nella classe HostApduService per inviare la risposta al termine dell'operazione.

Android continua a inoltrare le nuove APDU dal lettore al tuo servizio, finché non si verifica una delle seguenti condizioni:

• Il lettore NFC invia un'altra APDU SELECT AID, che viene risolta dal sistema operativo a un servizio diverso.
• Il collegamento NFC tra il lettore NFC e il dispositivo è interrotto.

In entrambi i casi, l'implementazione di onDeactivated() della tua classe viene chiamata con un argomento che indica quale dei due si è verificato.

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

Se stai eseguendo il deployment di una nuova infrastruttura di lettori che controlli anche tu, puoi definire il tuo protocollo e la tua sequenza APDU. Cerca di limitare la quantità di APDU e le dimensioni dei dati da scambiare per assicurarti che gli utenti debbano tenere il proprio dispositivo vicino al lettore NFC solo per un breve periodo di tempo. Un limite superiore ragionevole corrisponde a circa 1 kB di dati, che in genere può essere scambiato entro 300 ms.

Dichiarazione del manifest del servizio e registrazione dell'AID

Devi dichiarare il servizio nel file manifest come di consueto, ma devi aggiungere anche alcuni elementi aggiuntivi alla dichiarazione del servizio:

1. Per comunicare alla piattaforma che si tratta di un servizio HCE che implementa un'interfaccia HostApduService, aggiungi un filtro per intent per l'azione SERVICE_INTERFACE alla dichiarazione del servizio.

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

3. Imposta l'attributo android:exported su true e richiedi l'autorizzazione android.permission.BIND_NFC_SERVICE nella dichiarazione del servizio. Il primo assicura che il servizio possa essere associato ad applicazioni esterne. Quest'ultimo impone quindi che solo le applicazioni esterne che dispongono dell'autorizzazione android.permission.BIND_NFC_SERVICE possano essere associate 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ò essere associato 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 meta-dati rimanda a un file apduservice.xml. Di seguito è riportato un esempio di file di questo tipo con una singola dichiarazione di 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> contenente una descrizione facile da usare del servizio che puoi mostrare nell'interfaccia utente dell'app. Puoi utilizzare l'attributo requireDeviceUnlock per specificare che il dispositivo è sbloccato prima di richiamare questo servizio per gestire le APDU.

<host-apdu-service> deve contenere uno o più tag <aid-group>. Ogni tag <aid-group> deve:

• Contenere un attributo android:description contenente una descrizione facile da usare del gruppo AID, adatto per la visualizzazione nell'interfaccia utente.
• Avere il suo attributo android:category impostato per indicare la categoria a cui appartiene il gruppo AID, come le costanti di stringa definite da CATEGORY_PAYMENT o CATEGORY_OTHER.
• Contenere uno o più tag <aid-filter>, ciascuno dei quali contiene un singolo AID. Specifica l'AID in formato esadecimale e assicurati che contenga un numero pari di caratteri.

L'applicazione deve anche disporre dell'autorizzazione NFC per registrarsi come servizio HCE.

Risoluzione dei conflitti AID

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

Per alcune categorie, ad esempio i pagamenti, l'utente potrebbe essere in grado di selezionare un servizio predefinito nell'interfaccia utente delle impostazioni di Android. Per altre categorie, il criterio potrebbe chiedere sempre all'utente quale servizio richiamare in caso di conflitto. Per informazioni su come eseguire query sulle norme per la risoluzione dei conflitti per una determinata categoria, consulta getSelectionModeForCategory().

Controllare se il servizio è l'impostazione predefinita

Le applicazioni possono verificare se il loro servizio HCE è quello predefinito per una determinata categoria utilizzando l'API isDefaultServiceForCategory().

Se il servizio non è quello predefinito, puoi richiederne lo stato predefinito utilizzando ACTION_CHANGE_DEFAULT.

Applicazioni di pagamento

Android considera i servizi HCE che hanno dichiarato un gruppo di AID con la categoria pagamento come applicazioni di pagamento. Android 4.4 e versioni successive contengono una voce di menu Impostazioni di primo livello chiamata tocca e paga, che enumera tutte le applicazioni di pagamento. In questo menu delle impostazioni, l'utente può selezionare l'applicazione di pagamento predefinita da richiamare quando viene toccato un terminale di pagamento.

Asset obbligatori per le applicazioni di pagamento

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

Android 13 e versioni successive

Per adattarsi meglio all'elenco di selezione dei pagamenti predefinito nell'interfaccia utente Impostazioni, modifica il requisito del banner impostandolo su un'icona quadrata. Idealmente, dovrebbe essere identico al design dell'icona in Avvio applicazioni. Questo aggiustamento crea più coerenza e un aspetto più chiaro.

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 al tag <host-apdu-service>, che indirizza alla risorsa disegnabile. Di seguito è riportato 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>

Spegnimento dello schermo e comportamento della schermata di blocco

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

Android 12 e versioni successive

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

Android 10 e versioni successive

I dispositivi con Android 10 (livello API 29) o versioni successive supportano la tecnologia NFC sicura. Quando la tecnologia NFC sicura è attiva, tutti gli emulatori di carte (applicazioni host e applicazioni esterne all'host) non sono disponibili quando lo schermo del dispositivo è disattivato. Quando la tecnologia NFC sicuro è disattivata, le applicazioni esterne all'host sono disponibili quando lo schermo del dispositivo è disattivato. Puoi verificare il supporto della tecnologia NFC sicuro utilizzando isSecureNfcSupported().

Sui dispositivi con Android 10 e versioni successive, viene applicata la stessa funzionalità per impostare android:requireDeviceUnlock su true che per i dispositivi con Android 9 e versioni precedenti, ma soltanto quando la funzionalità NFC sicuro è disattivata. In altre parole, se la tecnologia NFC sicuro è attiva, i servizi HCE non possono funzionare dalla schermata di blocco indipendentemente 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 di applicazioni vengono disattivati completamente quando lo schermo del dispositivo è spento. Di conseguenza, i servizi HCE non funzionano quando lo schermo è spento.

Sempre su Android 9 e versioni precedenti, i servizi HCE possono funzionare dalla schermata di blocco. Tuttavia, ciò è controllato dall'attributo android:requireDeviceUnlock nel tag <host-apdu-service> del 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 il servizio HCE, Android chiede all'utente di sbloccare il dispositivo quando si verifica quanto segue:

• l'utente tocca un lettore NFC.
• il lettore NFC seleziona un AID che è risolto nel 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 allontanato il dispositivo dal lettore NFC per sbloccarlo.

Coesistenza con schede Secure Element

Questa sezione è interessante per gli sviluppatori che hanno eseguito il deployment di un'applicazione che si basa su un Secure Element per l'emulazione della carta. L'implementazione HCE di Android è progettata per funzionare in parallelo con altri metodi di implementazione dell'emulazione delle schede, tra cui l'uso di Secure Element.

Nota: Android non offre API per la comunicazione diretta con un Secure Element.

Questa coesistenza si basa su un principio chiamato Routing AID. Il controller NFC conserva una tabella di routing composta da un elenco (finito) di regole di routing. 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 elemento sicuro collegato.

Quando il lettore NFC invia un'APDU con un SELECT AID, il controller NFC la analizza e verifica se gli AID corrispondono a qualsiasi AID nella tabella di routing. Se corrisponde, l'APDU e tutte le APDU che lo seguono vengono inviati alla destinazione associata all'AID fino a quando non viene ricevuta un'altra APDU SELECT AID o il collegamento NFC non viene interrotto.

Nota: sebbene 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:

Figura 4. Android con emulazione Secure Element e scheda host.

In genere il controller NFC contiene anche un percorso predefinito per le APDU. Se non viene trovato un AID nella tabella di routing, viene utilizzata la route predefinita. Anche se questa impostazione può essere diversa da dispositivo a dispositivo, i dispositivi Android sono necessari per garantire che gli AID registrati dalla tua app vengano indirizzati correttamente all'host.

Le app Android che implementano un servizio HCE o che utilizzano un Secure Element non devono preoccuparsi di configurare la tabella di routing, che viene gestita automaticamente da Android. Android deve semplicemente sapere quali AID possono essere gestiti dai servizi HCE e quali possono essere gestiti da Secure Element. La tabella di routing viene configurata automaticamente in base ai servizi installati e a quelli configurati dall'utente come preferiti.

La seguente sezione spiega come dichiarare gli AID per le applicazioni che utilizzano un Secure Element per l'emulazione della carta.

Registrazione di Secure Element AID

Le applicazioni che utilizzano un Secure Element per l'emulazione della carta possono dichiarare un servizio off-host nel file manifest. La dichiarazione di tale servizio è quasi identica alla dichiarazione di un servizio HCE. Le eccezioni sono le seguenti:

• L'azione utilizzata nel filtro per intent deve essere impostata su SERVICE_INTERFACE.
• L'attributo del nome dei metadati 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 che registra 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, pertanto, non può impedire al Secure Element di eseguire transazioni quando il dispositivo è bloccato.

L'attributo android:apduServiceBanner è obbligatorio per i servizi esterni all'host che sono applicazioni di pagamento e che devono essere selezionabili come applicazione di pagamento predefinita.

Chiamata a servizio off-host

Android non si avvia o non si associa mai a un servizio dichiarato come "off-host", perché le transazioni effettive vengono eseguite dall'elemento secure e non dal servizio Android. La dichiarazione del servizio consente semplicemente alle applicazioni di registrare gli AID presenti nel Secure Element.

HCE e sicurezza

L'architettura HCE fornisce una singola parte di sicurezza di base: poiché il servizio è protetto dall'autorizzazione di sistema di BIND_NFC_SERVICE, solo il sistema operativo può collegarsi al servizio e comunicarlo. In questo modo si garantisce che l'APDU ricevuta sia in realtà una APDU ricevuta dal sistema operativo dal controller NFC e che qualsiasi APDU che invii venga inviata solo al sistema operativo, che a sua volta inoltra direttamente le APDU al controller NFC.

L'ultimo problema riguarda il luogo in cui ricevi i dati che l'app invia al lettore NFC. Questo è intenzionalmente disaccoppiato nel design HCE; non importa da dove provengono i dati, ma garantisce solo che siano trasportati in sicurezza al controller NFC e al lettore NFC.

Per archiviare e recuperare in modo sicuro i dati che vuoi inviare dal servizio HCE, puoi, ad esempio, utilizzare Android Application Sandbox, che isola i dati della tua app da altre app. Per ulteriori dettagli sulla sicurezza di Android, leggi Suggerimenti per la sicurezza.

Parametri e dettagli del protocollo

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

Protocollo Nfc-A (ISO/IEC 14443 tipo A) anticollisione e attivazione

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

Nella prima parte dello scambio, il dispositivo HCE presenta il proprio UID; si presume che i dispositivi HCE abbiano un UID casuale. Ciò significa che a ogni tocco, l'UID presentato al lettore è un UID generato casualmente. Per questo motivo, i lettori NFC non dovrebbero dipendere dall'UID dei dispositivi HCE come forma di autenticazione o identificazione.

Il lettore NFC può quindi selezionare il dispositivo HCE inviando un comando SEL_REQ. Nella risposta SEL_RES del dispositivo HCE è impostato almeno il sesto bit (0x20), che indica che il dispositivo supporta ISO-DEP. Tieni presente che è possibile impostare anche altri bit in SEL_RES, indicando ad esempio il supporto del protocollo NFC-DEP (p2p). Poiché è possibile impostare altri bit, i lettori che vogliono interagire con i dispositivi HCE devono controllare esplicitamente solo il sesto bit e non confrontare il valore SEL_RES completo con un valore pari a 0x20.

Attivazione ISO-DEP

Una volta attivato il protocollo Nfc-A, il lettore NFC avvia l'attivazione del protocollo ISO-DEP. Invia un comando RATS (Request for Answer To Select). Il controller NFC genera la risposta RATS, l'ATS; quest'ultimo non è configurabile dai servizi HCE. Tuttavia, le implementazioni HCE devono soddisfare i requisiti del forum NFC per la risposta ATS, in modo che i lettori NFC possano contare su questi parametri impostati in conformità con i requisiti del forum NFC per qualsiasi dispositivo HCE.

La sezione seguente fornisce ulteriori dettagli sui singoli byte della risposta ATS fornita dal controller NFC su un dispositivo HCE:

• TL: durata della risposta ATS. Non deve indicare una lunghezza superiore a 20 byte.
• T0: i bit 5, 6 e 7 devono essere impostati su tutti i dispositivi HCE, il che indica che TA(1), TB(1) e TC(1) sono inclusi nella risposta ATS. I bit da 1 a 4 indicano FSCI, codificando la dimensione massima del fotogramma. Sui dispositivi HCE, il valore di FSCI deve essere compreso tra 0 e 8 h.
• T(A)1: definisce le velocità in bit tra lettore ed emulatore e se possono essere asimmetriche. Non sono previsti requisiti per la velocità in bit o garanzie per i dispositivi HCE.
• T(B)1: i bit da 1 a 4 indicano lo Start-up Frame Guard Time Integer (SFGI). Sui dispositivi HCE, il valore SFGI deve essere <= 8 ore. I bit da 5 a 8 indicano il numero intero di tempo di attesa in frame (FWI) e codificano il tempo di attesa frame (FWT). Sui dispositivi HCE, il valore FWI deve essere <= 8 ore.
• T(C)1: il bit 5 indica il supporto per le "funzionalità Advanced Protocol". I dispositivi HCE potrebbero supportare o meno le "funzionalità Advanced Protocol". Il bit 2 indica il supporto per DID. I dispositivi HCE potrebbero supportare o meno il rilevamento DID. Il bit 1 indica il supporto per NAT. 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. I lettori NFC disposti a interagire con i servizi HCE non devono fare ipotesi sui contenuti dei byte storici o sulla 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 nella specifica "Contactless Communication Protocol". In particolare:

• Il valore FSCI in T0 deve essere compreso tra 2 h e 8 h.
• T(A)1 deve essere impostato su 0x80, il che significa che è supportata solo la velocità in bit di 106 kbit/s e che le velocità in bit asimmetriche tra lettore ed emulatore non sono supportate.
• 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 su un dispositivo HCE.