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)
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.
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:
Per indicare alla piattaforma che si tratta di un servizio HCE che implementa
HostApduService
, aggiungi un filtro per intent perSERVICE_INTERFACE
alla tua dichiarazione del servizio.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.Imposta l'attributo
android:exported
sutrue
e richiedi ilandroid.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'autorizzazioneandroid.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 daCATEGORY_PAYMENT
oCATEGORY_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.
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.
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.