Cette page a été traduite par l'API Cloud Translation.

Présentation de la technologie HCE

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:

Schéma montrant un lecteur NFC passant par un contrôleur NFC pour récupérer des informations à partir d'un élément sécurisé
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:

Schéma montrant un lecteur NFC passant par un contrôleur NFC pour récupérer des informations auprès du processeur
Figure 2 : Émulation de carte NFC sans composant sécurisé.

Cartes et protocoles NFC compatibles

Schéma illustrant la pile de protocoles HCE
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 pour SERVICE_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 sur true et exigez le paramètre android.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'autorisation android.permission.BIND_NFC_SERVICE peut être liée à votre service. Comme android.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 par CATEGORY_PAYMENT ou CATEGORY_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:

Schéma illustrant la communication d'un lecteur NFC avec un élément sécurisé et le processeur
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.