De nombreux appareils Android dotés de la fonctionnalité NFC sont déjà compatibles avec cette technologie. l'émulation de carte. Dans la plupart des cas, la carte est émulée par une puce distincte dans d'un appareil, appelé élément sécurisé. Nombreuses cartes SIM fournies par les opérateurs de téléphonie mobile contiennent également un composant sécurisé.
Android 4.4 et versions ultérieures fournissent une méthode supplémentaire d'émulation de carte qui n'implique pas de composant sécurisé, appelé émulation de carte basée sur l'hôte. Ce permet à n'importe quelle application Android d'émuler une carte et de communiquer directement avec le NFC en lecture seule. Cet article décrit le fonctionnement de l'émulation de carte basée sur l'hôte (HCE) sur Android et comment développer une application qui émule une carte NFC à l'aide de cette technique.
Émulation de carte avec un composant sécurisé
Lorsque l'émulation de carte NFC est fournie à l'aide d'un composant sécurisé, la carte à utiliser émulé est provisionné dans le composant sécurisé de l'appareil via un application. Ensuite, lorsque l'utilisateur tient l'appareil au-dessus d'un terminal NFC, le NFC le contrôleur de l'appareil achemine toutes les données du lecteur directement vers le . La figure 1 illustre ce concept:
Figure 1 : Émulation de carte NFC avec un composant sécurisé.
L'élément sécurisé effectue lui-même la communication avec le terminal NFC. qu'aucune application Android n'est impliquée dans la transaction. Une fois la transaction effectuée une application Android peut interroger directement l'élément sécurisé afin d'obtenir l'état de la transaction et notifier l'utilisateur.
Émulation de carte basée sur l'hôte
Lorsqu'une carte NFC est émulée à l'aide de l'émulation de carte basée sur l'hôte, les données sont acheminées directement au CPU hôte au lieu d'être acheminé vers un élément sécurisé. Figure 2 illustre le fonctionnement de l'émulation de cartes basée sur l'hôte:
Figure 2 : Émulation de carte NFC sans composant sécurisé.
Cartes et protocoles NFC compatibles
Figure 3 : Pile de protocoles HCE d'Android.
Les normes NFC sont compatibles avec de nombreux protocoles différents, et il existe différents types de cartes que vous pouvez émuler.
Android 4.4 et versions ultérieures sont compatibles avec plusieurs protocoles courants sur le marché.
dès aujourd'hui. De nombreuses cartes sans contact existantes
sont déjà basées sur ces protocoles,
comme les cartes de paiement sans contact. Ces protocoles sont également
compatibles avec de nombreux
Lecteurs NFC sur le marché actuel, y compris les appareils NFC Android fonctionnant comme
lecteurs eux-mêmes (consultez le IsoDep
). Vous pouvez ainsi créer et déployer une solution NFC de bout en bout
HCE avec uniquement des appareils Android.
Plus précisément, Android 4.4 et versions ultérieures sont compatibles avec l'émulation de cartes basées sur la spécification ISO-DEP du NFC-Forum (basée sur la norme ISO/IEC 14443-4) et le processus Unités de protocole d'application (APDU) telles que définies dans la norme ISO/IEC 7816-4 spécifique. Android exige d'émuler la norme ISO-DEP uniquement en plus de la couche NFC (ISO/IEC 14443-3 Type A). Compatibilité avec NFC-B (ISO/IEC 14443-4 Type B) est facultative. La figure 3 illustre la superposition de tous ces éléments. caractéristiques techniques.
Services HCE
L'architecture HCE dans Android est basée sur Android
Composants Service
(appelés HCE)
services Google Cloud). L'un des principaux avantages d'un service
est qu'il peut s'exécuter dans
sans interface utilisateur. Il s'agit d'une solution adaptée aux besoins
des applications, telles que les cartes de fidélité ou de transport, dont l'utilisateur n'a pas besoin
lancer une application à utiliser. En revanche, le fait d'appuyer l'appareil contre le lecteur NFC
au bon service s'il n'est pas déjà en cours d'exécution et exécute la transaction
en arrière-plan. Bien entendu, vous êtes libre de lancer des interfaces utilisateur supplémentaires (telles que
notifications utilisateur) de votre service, le cas échéant.
Sélection des services
Lorsque l'utilisateur place un appareil contre un lecteur NFC, le système Android doit connaître avec quel service HCE le lecteur NFC souhaite communiquer. La norme ISO/IEC 7816-4 définit une méthode de sélection des applications, centrée sur un ID d'application (AID). Un AID peut comporter jusqu'à 16 octets. Si vous émulez pour une infrastructure de lecteurs NFC existante, les AID que ces lecteurs recherchent sont généralement connues et enregistrées publiquement (par exemple, le les AID des réseaux de paiement tels que Visa et MasterCard).
Si vous souhaitez déployer une nouvelle infrastructure de lecture pour votre propre application, devez enregistrer vos propres AID. La procédure d'enregistrement des AID est définie dans la spécification ISO/IEC 7816-5. Nous vous recommandons d'enregistrer un AID conformément à la norme 7816-5. si vous déployez une application HCE pour Android, car cela évite les conflits avec d'autres applications.
Groupes d'AID
Dans certains cas, un service HCE peut avoir besoin d'enregistrer plusieurs AID et d'être défini comme le gestionnaire par défaut de tous les AID afin d'implémenter une certaine application. Certains AID du groupe vont à un autre service ne sont pas pris en charge.
Une liste d’AID qui sont conservés ensemble est appelée un groupe d’AID. Pour tous les AID d'une Groupe AID, Android garantit l'un des éléments suivants:
- Tous les AID du groupe sont acheminés vers ce service HCE.
- Aucun AID du groupe n'est acheminé vers ce service HCE (par exemple, l'utilisateur a préféré un autre service ayant demandé un ou plusieurs AID dans votre groupe .
En d'autres termes, il n'y a pas d'état entre les états, où certains AID du groupe peuvent être acheminés vers un service HCE, et certains vers un autre.
Catégories et groupes d'AID
Vous pouvez associer chaque groupe d'AID à une catégorie. Cela permet à Android de regrouper services HCE par catégorie, ce qui permet à l'utilisateur de définir les valeurs par défaut sont définies au niveau de la catégorie plutôt qu'au niveau de l'AID. Éviter de mentionner les AID dans les parties de votre application destinées aux utilisateurs, car elles ne signifient rien pour l'utilisateur moyen.
Android 4.4 et versions ultérieures sont compatibles avec deux catégories:
CATEGORY_PAYMENT
(couvrant les applications de paiement standards dans l'industrie)CATEGORY_OTHER
(pour toutes les autres applications HCE)
Implémenter un service HCE
Pour émuler une carte NFC à l'aide de l'émulation de carte basée sur l'hôte, vous devez créer un
Composant Service
qui gère les transactions NFC.
Vérifier la compatibilité HCE
Votre application peut vérifier si un appareil est compatible avec la fonctionnalité HCE en recherchant le
FEATURE_NFC_HOST_CARD_EMULATION
. Utilisez le <uses-feature>
dans le fichier manifeste de votre application pour déclarer qu'elle utilise la technologie HCE.
et si elle est nécessaire au fonctionnement de l'application.
Implémentation du service
Android 4.4 ou version ultérieure offre une classe Service
pratique que vous pouvez utiliser
pour implémenter un service HCE :
HostApduService
.
La première étape consiste à étendre HostApduService
, comme illustré dans le code suivant.
exemple:
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
déclare deux méthodes abstraites que vous devez remplacer et
mettre en œuvre. Par exemple,
processCommandApdu()
,
est appelé chaque fois qu'un lecteur NFC envoie une unité APDU (Application Protocol Data Unit)
à votre service. Les APDU sont définies dans la spécification ISO/IEC 7816-4. APDU
sont les paquets au niveau de l'application échangés entre le lecteur NFC et
à votre service HCE. Ce protocole au niveau de l'application est semi-duplex: le lecteur NFC
vous envoie une commande APDU, et attend que vous envoyiez une réponse APDU dans
retour.
Comme indiqué précédemment, Android utilise l'AID pour déterminer le service HCE
le lecteur veut s'adresser à lui. En règle générale, la première APDU qu'un lecteur NFC envoie à votre
l'appareil est un APDU SELECT AID
. cette APDU contient l'AID que le lecteur souhaite
à qui parler. Android extrait cet AID de l'APDU et le convertit en HCE.
puis transmet cette APDU
au service résolu.
Vous pouvez envoyer une APDU de réponse en renvoyant les octets de l'APDU de réponse depuis
processCommandApdu()
Notez que cette méthode est appelée sur le thread principal.
de votre application, ce que vous ne devez pas bloquer. Si vous ne pouvez pas calculer et renvoyer
une APDU de réponse immédiatement
et renvoie la valeur null. Vous pouvez ensuite effectuer
le travail nécessaire sur
un autre fil de discussion et d'utiliser
sendResponseApdu()
définie dans la classe HostApduService
pour envoyer la réponse lorsque vous
terminé.
Android continue de transférer les nouvelles APDU du lecteur vers votre service, jusqu'à ce que : l'un des événements suivants se produit:
- Le lecteur NFC envoie une autre APDU
SELECT AID
, que le système d'exploitation résout en un service différent. - Le lien NFC entre le lecteur NFC et votre appareil ne fonctionne pas.
Dans les deux cas,
onDeactivated()
est appelée avec un argument indiquant lequel des deux s'est produit.
Si vous travaillez avec une infrastructure de lecture existante, vous devez implémenter protocole existant au niveau de l'application que les lecteurs attendent dans votre service HCE.
Si vous déployez une nouvelle infrastructure de lecteurs que vous contrôlez également, vous pouvez définir votre propre protocole et votre propre séquence APDU. Essayer de limiter le nombre d'APDU et la taille des données à échanger. Ainsi, vos utilisateurs n'auront accès qu'à de maintenir son appareil au-dessus du lecteur NFC pendant une courte période. A la limite supérieure raisonnable est d'environ 1 Ko de données, ce qui peut généralement être dans un délai de 300 ms.
Déclaration du fichier manifeste de service et enregistrement AID
Vous devez déclarer votre service dans le fichier manifeste comme d'habitude, mais vous devez en ajouter d'autres éléments à la déclaration de service:
Pour indiquer à la plate-forme qu'il s'agit d'un service HCE mettant en œuvre
HostApduService
, ajoutez un filtre d'intent pourSERVICE_INTERFACE
à votre déclaration de service.Pour indiquer à la plate-forme quels groupes d'AID sont demandés par ce service, incluez un
SERVICE_META_DATA
Balise<meta-data>
dans la déclaration du service, pointant vers un fichier XML contenant des informations supplémentaires sur le service HCE.Définissez l'attribut
android:exported
surtrue
et exigez le paramètreandroid.permission.BIND_NFC_SERVICE
dans votre déclaration de service. Le premier garantit que le service peut être lié par des applications externes. Cette dernière impose alors que seules les applications externes détenant le L'autorisationandroid.permission.BIND_NFC_SERVICE
peut être liée à votre service. Commeandroid.permission.BIND_NFC_SERVICE
est une autorisation système, cette permet de s'assurer que seul le système d'exploitation Android peut s'associer à votre service.
Voici un exemple de déclaration de fichier manifeste 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>
Cette balise de métadonnées pointe vers un fichier apduservice.xml
. Voici un exemple
exemple de ce type de fichier avec une seule déclaration de groupe AID contenant deux
AID propriétaires:
<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>
La balise <host-apdu-service>
doit contenir un attribut <android:description>
.
qui contient une description conviviale du service que vous pouvez afficher
l'UI de l'application. Vous pouvez utiliser l'attribut requireDeviceUnlock
pour spécifier que
l'appareil est déverrouillé avant d'appeler ce service pour gérer les APDU.
L'<host-apdu-service>
doit contenir une ou plusieurs balises <aid-group>
. Chaque
La balise <aid-group>
est requise pour effectuer les opérations suivantes:
- Contiennent un attribut
android:description
contenant un sous-attribut convivial description du groupe AID, adaptée à l'affichage dans l'interface utilisateur. - avoir défini son attribut
android:category
pour indiquer la catégorie de l'AID ; auquel appartient le groupe, comme les constantes de chaîne définies parCATEGORY_PAYMENT
ouCATEGORY_OTHER
. - Contenir un ou plusieurs tags
<aid-filter>
, chacun contenant un seul AID. Spécifiez l'AID au format hexadécimal et assurez-vous qu'il contient un nombre pair le nombre de caractères.
Votre application doit également contenir
Autorisation NFC
de s'enregistrer en tant que
service HCE.
Résolution des conflits liés aux AID
Vous pouvez installer plusieurs composants HostApduService
sur un même appareil.
le même AID peut être enregistré par
plusieurs services. Android résout l'AID
les conflits diffèrent selon la catégorie
à laquelle appartient un AID. Chaque
peut être associée à des règles de résolution des conflits différentes.
Pour certaines catégories, comme les paiements, il est possible que l'utilisateur puisse sélectionner
dans l'interface utilisateur des paramètres Android. Pour les autres catégories, la règle peut consister
toujours demander à l'utilisateur quel service
appeler en cas de conflit. Pour plus d'informations
pour savoir comment interroger la règle de résolution des conflits pour une catégorie spécifique, consultez
getSelectionModeForCategory()
Vérifier si votre service est le service par défaut
Les applications peuvent vérifier si leur service HCE est le service par défaut
pour certaines catégories
isDefaultServiceForCategory()
API.
Si votre service n'est pas le service par défaut, vous pouvez demander à en faire le service par défaut
avec
ACTION_CHANGE_DEFAULT
Applications de paiement
Android tient compte des services HCE qui ont déclaré un groupe AID avec le paramètre payment comme applications de paiement. Android 4.4 et versions ultérieures disposent d'un entrée du menu Paramètres située en haut de l'écran, intitulée Appuyer et Pay, qui énumère de ces applications de paiement. Dans ce menu de paramètres, l'utilisateur peut sélectionner application de paiement par défaut à invoquer lorsqu'un terminal de paiement est utilisé.
Éléments requis pour les applications de paiement
Pour rendre l'expérience utilisateur plus attrayante, les applications de paiement HCE pour fournir une bannière de service.
Android 13 ou version ultérieure
Pour mieux correspondre à la liste de sélection des paiements par défaut dans l'interface utilisateur des paramètres, ajustez la de bannière à une icône carrée. Dans l'idéal, il doit être identique au conception de l'icône de lanceur d'applications. Cet ajustement crée plus de cohérence et plus claire.
Android 12 ou version antérieure
Définissez la taille de la bannière de service sur 260 x 96 dp, puis la taille de la bannière de service
dans votre fichier XML de métadonnées, en ajoutant l'attribut android:apduServiceBanner
à
Le tag <host-apdu-service>
, qui pointe vers la ressource drawable La
Voici un exemple:
<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>
Désactivation de l'écran et comportement de l'écran de verrouillage
Le comportement des services HCE varie selon la version d'Android exécutée sur l'appareil.
Android 12 ou version ultérieure
Vous pouvez activer le NFC dans les applications qui ciblent Android 12 (niveau d'API 31) ou version ultérieure.
des paiements sans avoir l'écran allumé en paramétrant
requireDeviceScreenOn
jusqu'à
false
Android 10 ou version ultérieure
Compatibilité avec les appareils équipés d'Android 10 (niveau d'API 29) ou version ultérieure
Sécurité
NFC Bien sécurisé
NFC est activé, tous les émulateurs de carte (applications hôtes et applications hors hôtes) sont
indisponible lorsque l'écran de l'appareil est éteint. Lorsque le NFC sécurisé est désactivé, l'appareil hors hôte
applications sont disponibles lorsque l'écran de l'appareil est éteint. Vous pouvez vérifier
Sécurisez la compatibilité NFC avec
isSecureNfcSupported()
Sur les appareils équipés d'Android 10 ou version ultérieure,
android:requireDeviceUnlock
à true
s'applique comme pour les appareils
équipés d'Android 9 ou version antérieure, mais uniquement si la fonctionnalité NFC sécurisée est désactivée. Autrement dit, si
Le NFC sécurisé est activé. Les services HCE ne peuvent pas fonctionner depuis l'écran de verrouillage.
quel que soit le paramètre android:requireDeviceUnlock
.
Android 9 ou version antérieure
Sur les appareils équipés d'Android 9 (niveau d'API 28) ou version antérieure, le contrôleur NFC et le processeur d'application est complètement désactivé lorsque l'écran l'appareil est éteint. Les services HCE ne fonctionnent donc pas lorsque l'écran est éteint.
Sur Android 9 ou version antérieure, les services HCE peuvent également fonctionner depuis l'écran de verrouillage.
Toutefois, cela est contrôlé par l'attribut android:requireDeviceUnlock
dans
le tag <host-apdu-service>
de votre service HCE. Par défaut, le déverrouillage de l'appareil est
n'est pas obligatoire, et votre service est appelé même si l'appareil est verrouillé.
Si vous définissez l'attribut android:requireDeviceUnlock
sur true
pour votre HCE
Android, Android invite l'utilisateur à déverrouiller son appareil
se produire:
- l'utilisateur appuie sur un lecteur NFC.
- le lecteur NFC sélectionne un AID associé à votre service.
Après le déverrouillage, Android affiche une boîte de dialogue invitant l'utilisateur à appuyer de nouveau pour pour finaliser la transaction. Cette étape est nécessaire, car il est possible que l'utilisateur ait déplacé l'appareil éloigné du lecteur NFC afin de le déverrouiller.
Coexistence avec des cartes avec composants sécurisés
Cette section s'adresse aux développeurs ayant déployé une application. qui repose sur un composant sécurisé pour l'émulation de carte. Implémentation HCE d'Android est conçu pour fonctionner en parallèle avec d'autres méthodes d'implémentation des fiches émulation, y compris l'utilisation d'éléments sécurisés.
Cette coexistence est basée sur un principe appelé routage AID. La technologie NFC le contrôleur conserve une table de routage qui consiste en une liste (finie) de routes des règles de pare-feu. Chaque règle de routage contient un AID et une destination. La destination peut soit le processeur hôte, sur lequel les applications Android sont en cours d'exécution, soit un serveur .
Lorsque le lecteur NFC envoie une APDU avec un SELECT AID
, le contrôleur NFC analyse
et vérifie si les AID correspondent à
un AID dans sa table de routage. Si
correspond, cette APDU et toutes les APDU qui la suivent sont envoyées à la destination
associé à l'AID, jusqu'à ce qu'une autre APDU SELECT AID
soit reçue ou que le NFC
le lien ne fonctionne pas.
La figure 4 illustre cette architecture:
Figure 4 : Android fonctionnant à la fois avec un composant sécurisé et une émulation de carte hôte.
Le contrôleur NFC contient généralement également une route par défaut pour les APDU. Lorsqu'un AID introuvable dans la table de routage. La route par défaut est utilisée. Bien que cette peut être différent d'un appareil à l'autre, vous devez utiliser des appareils Android pour vous assurer que les AID enregistrés par votre application sont correctement acheminés vers hôte.
Applications Android qui implémentent un service HCE ou qui utilisent un composant sécurisé n'avez pas à vous soucier de la configuration de la table de routage ; géré par Android. Android a simplement besoin de savoir quels AID peuvent être gérés. par les services HCE et ceux qui peuvent être gérés par le composant sécurisé. Le routage est configuré automatiquement en fonction des services installés et que l'utilisateur a configuré comme souhaité.
La section suivante explique comment déclarer des AID pour les applications qui utilisent un sécurisé pour l'émulation de carte.
Enregistrement de l'AID du composant sécurisé
Les applications qui utilisent un composant sécurisé pour l'émulation de cartes peuvent déclarer un service hors hôte dans leur fichier manifeste. La déclaration d'un tel service presque identique à la déclaration d'un service HCE. Les exceptions sont les ce qui suit:
- L'action utilisée dans le filtre d'intent doit être définie sur
SERVICE_INTERFACE
- L'attribut nom des métadonnées doit être défini sur
SERVICE_META_DATA
Le fichier XML de métadonnées doit utiliser la balise racine
<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>
Voici un exemple du fichier apduservice.xml
correspondant
enregistrement de deux 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'attribut android:requireDeviceUnlock
ne s'applique pas aux services hors hébergeur,
car le CPU hôte n'est pas impliqué
dans la transaction et ne peut donc pas
empêcher le composant sécurisé d'exécuter des transactions lorsque l'appareil
verrouillé.
L'attribut android:apduServiceBanner
est obligatoire pour les services hors hébergeur
Il s'agit d'applications de paiement pouvant être sélectionnées comme mode de paiement par défaut.
application.
Appel du service hors hôte
Android ne démarre jamais de service déclaré comme "hors hôte" et ne s'y lie jamais. car les transactions réelles sont exécutées par l'élément sécurisé et non par le service Android. La déclaration de service permet simplement aux applications enregistrer les AID présents sur le composant sécurisé.
HCE et sécurité
L'architecture HCE fournit un élément essentiel de la sécurité :
service est protégé par
BIND_NFC_SERVICE
l'autorisation système, seul l'OS peut s'associer à votre service et communiquer avec celui-ci.
Cela garantit que toutes les APDU que vous recevez sont bien des APDU reçues par
le système d'exploitation depuis le contrôleur NFC, et que toutes les APDU que vous renvoyez ne sont transmises
le système d'exploitation, qui à son tour transmet
directement les APDU au contrôleur NFC.
Dernière préoccupation : où vous obtenez les données envoyées par votre application au lecteur NFC. Il est intentionnellement découplé dans la conception HCE. il fait ne se soucie pas d'où viennent les données, il s'assure simplement qu'elles sont transporté vers le contrôleur NFC et vers le lecteur NFC.
Pour stocker et récupérer de manière sécurisée les données que vous souhaitez envoyer depuis votre HCE Google Cloud, vous pouvez, par exemple, utiliser le bac à sable d'application Android, isole les données de votre application des autres. Pour en savoir plus sur Android consultez nos conseils de sécurité.
Paramètres et détails du protocole
Cette section est d’intérêt pour les développeurs qui souhaitent comprendre quel protocole les paramètres utilisés par les appareils HCE lors des phases d'anti-collision et d'activation les protocoles NFC. Cela permet de créer une infrastructure de lecteurs compatible avec les appareils Android HCE.
Protocole Nfc-A (ISO/IEC 14443 de type A) anti-collision et activation
Dans le cadre de l'activation du protocole Nfc-A, plusieurs trames sont échangées.
Dans la première partie de l'échange, l'appareil HCE présente son UID. Appareils HCE doit être considéré comme ayant un UID aléatoire. Autrement dit, à chaque pression, l'UID présenté au lecteur est un UID généré de manière aléatoire. Pour cette raison, Les lecteurs NFC ne doivent pas dépendre de l'UID des appareils HCE comme forme de l'authentification ou l'identification.
Le lecteur NFC peut ensuite sélectionner l'appareil HCE en envoyant un SEL_REQ
. La réponse SEL_RES
de l'appareil HCE comporte au moins le 6e bit.
(0x20), ce qui indique que l'appareil est compatible avec ISO-DEP. Notez que
les autres bits dans
SEL_RES
peut également être défini, indiquant par exemple la compatibilité avec le NFC-DEP.
(p2p). Étant donné que d'autres bits peuvent être définis, les lecteurs souhaitant interagir avec
Les appareils HCE doivent vérifier explicitement le 6e bit uniquement et ne pas comparer
le SEL_RES
complet avec une valeur de 0x20.
Activation ISO-DEP
Une fois le protocole Nfc-A activé, le lecteur NFC lance l'authentification ISO-DEP. l'activation du protocole. Il envoie un RATS (Request for Answer To Select) . Le contrôleur NFC génère la réponse RATS, l'ATS ; l'ATS n'est pas configurable par les services HCE. Cependant, les implémentations HCE doivent respecter le forum NFC exigences pour la réponse ATS, afin que les lecteurs NFC puissent compter sur ces paramètres conformément aux exigences du forum NFC pour tous les appareils HCE.
La section ci-dessous fournit plus de détails sur les octets individuels de l'ATS. fournie par le contrôleur NFC sur un appareil HCE:
- TL: longueur de la réponse ATS. Ne doit pas indiquer une longueur supérieure à 20 octets.
- T0: les bits 5, 6 et 7 doivent être définis sur tous les appareils HCE, ce qui indique TA(1) et To(1) et TC(1) sont inclus dans la réponse de l'ATS. Les bits 1 à 4 indiquent la FSCI, coder la taille maximale du frame. Sur les appareils HCE, la valeur de FSCI doit être entre 0 h et 8 h.
- T(A)1: définit les débits entre le lecteur et l'émulateur, et s'ils peuvent être asymétrique. Il n'existe aucune condition ni garantie de débit pour les appareils HCE.
- T(B)1: les bits 1 à 4 indiquent l'entier SFGI (Start-up Frame Guard). Activé Pour les appareils HCE, le SFGI doit durer <= 8 h. Les bits 5 à 8 indiquent la trame en attente Entier "time" (FWI) et code le temps d'attente du frame (FWT). Sur les appareils HCE, FWI doit être <= 8 h.
- T(C)1: le bit 5 indique la prise en charge des fonctionnalités de protocole avancées. Appareils HCE sont susceptibles d'être compatibles ou non avec les "Fonctionnalités du protocole avancé". Le bit 2 indique la compatibilité pour DID. Les appareils HCE peuvent être compatibles ou non avec le mode DID. Le bit 1 indique la prise en charge de NAD. Les appareils HCE ne doivent pas être compatibles avec NAD et définir le bit 1 sur zéro.
- Octets historiques: les appareils HCE peuvent renvoyer jusqu'à 15 octets historiques. NFC les lecteurs prêts à interagir avec les services HCE ne doivent faire aucune supposition le contenu des octets historiques ou leur présence.
Notez que de nombreux appareils HCE sont probablement rendus conformes aux exigences du protocole. que les réseaux de paiement réunis au sein de l'EMVCo ont défini leur Protocole de communication. spécifique. En particulier :
- La FSCI à l'étape T0 doit être comprise entre 2 h et 8 h.
- T(A)1 doit être défini sur 0x80, ce qui signifie que seul le débit de 106 kbit/s est Les débits asymétriques entre le lecteur et l'émulateur ne sont pas pris en charge, compatibles.
- FWI en T(B)1 doit être <= 7 h.
Échange de données APDU
Comme indiqué précédemment, les implémentations HCE n'acceptent qu'un seul canal logique. Les tentatives de sélection d'applications sur différents canaux logiques ne fonctionnent pas un appareil HCE.