Présentation de la technologie HCE

De nombreux appareils Android dotés de la fonctionnalité NFC prennent déjà en charge l'émulation de carte NFC. Dans la plupart des cas, la carte est émulée par une puce distincte dans l'appareil, appelée composant sécurisé. De nombreuses cartes SIM fournies par les opérateurs de téléphonie mobile contiennent également un composant sécurisé.

Android 4.4 et les versions ultérieures fournissent une méthode supplémentaire d'émulation de carte qui n'implique pas de composant sécurisé, appelée émulation de carte basée sur l'hôte. Cela permet à n'importe quelle application Android d'émuler une carte et de communiquer directement avec le lecteur NFC. Cet article décrit le fonctionnement de l'émulation de carte basée sur l'hôte (HCE) sur Android et explique comment développer une application qui émule une carte NFC à l'aide de cette technique.

Émulation de cartes avec un composant sécurisé

Lorsque l'émulation de carte NFC est fournie à l'aide d'un composant sécurisé, la carte à émuler est provisionnée dans le composant sécurisé de l'appareil via une application Android. Ensuite, lorsque l'utilisateur tient l'appareil au-dessus d'un terminal NFC, le contrôleur NFC intégré à l'appareil achemine toutes les données du lecteur directement vers l'élément sécurisé. La figure 1 illustre ce concept:

Figure 1 : Émulation de carte NFC avec un composant sécurisé.

Le composant sécurisé communique lui-même avec le terminal NFC, et aucune application Android n'est impliquée dans la transaction. Une fois la transaction terminée, une application Android peut interroger directement le composant sécurisé pour connaître l'état de la transaction et avertir l'utilisateur.

Émulation de carte basée sur l'hôte

Lorsqu'une carte NFC est émulée à l'aide d'une émulation de carte basée sur l'hôte, les données sont acheminées directement vers le processeur hôte au lieu d'être acheminées vers un élément sécurisé. La figure 2 illustre le fonctionnement de l'émulation de carte 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 vous pouvez émuler différents types de cartes.

Android 4.4 et les versions ultérieures sont compatibles avec plusieurs protocoles courants sur le marché 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 disponibles sur le marché à l'heure actuelle, y compris les appareils NFC Android fonctionnant en tant que lecteurs eux-mêmes (voir la classe IsoDep). Cela vous permet de créer et de déployer une solution NFC de bout en bout autour d'HCE à l'aide d'appareils Android uniquement.

Plus précisément, Android 4.4 et les versions ultérieures sont compatibles avec l'émulation de cartes basées sur la spécification NFC-Forum ISO-DEP (basée sur la norme ISO/CEI 14443-4) et le traitement des unités de données APDU (Application Protocol Data Units) telles que définies dans la spécification ISO/IEC 7816-4. Android exige d'émuler la norme ISO-DEP uniquement en plus de la technologie NFC-A (ISO/IEC 14443-3 Type A). La compatibilité avec la technologie Nfc-B (ISO/IEC 14443-4 Type B) est facultative. La figure 3 illustre la superposition de toutes ces spécifications.

Services HCE

L'architecture HCE d'Android est basée sur des composants Service Android (appelés services HCE). L'un des principaux avantages d'un service est qu'il peut s'exécuter en arrière-plan sans aucune interface utilisateur. Cela convient tout naturellement à de nombreuses applications HCE, telles que les cartes de fidélité ou de transport, dont l'utilisateur ne devrait pas avoir besoin pour lancer une application. Au lieu de cela, appuyer l'appareil contre le lecteur NFC lance le 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 une interface utilisateur supplémentaire (comme les notifications utilisateur) à partir de votre service, le cas échéant.

Choix du service

Lorsque l'utilisateur place un appareil sur un lecteur NFC, le système Android doit savoir avec quel service HCE le lecteur NFC souhaite communiquer. La spécification ISO/IEC 7816-4 définit une méthode de sélection d'applications, centrée sur un ID application (AID). Un AID peut comporter jusqu'à 16 octets. Si vous émulez des cartes pour une infrastructure de lecteur NFC existante, les AID que ces lecteurs recherchent sont généralement connus et enregistrés publiquement (par exemple, les AID de réseaux de paiement tels que Visa et MasterCard).

Si vous souhaitez déployer une nouvelle infrastructure de lecteur pour votre propre application, vous 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 AID

Dans certains cas, un service HCE peut avoir besoin d'enregistrer plusieurs AID et de le définir comme gestionnaire par défaut pour tous les AID afin de mettre en œuvre une application donnée. Certains AID du groupe envoyés à un autre service ne sont pas acceptés.

Une liste d'AID conservés ensemble s'appelle un groupe AID. Pour tous les AID d'un groupe AID, Android garantit l'une des conditions suivantes:

• 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, parce que l'utilisateur a préféré un autre service qui a demandé un ou plusieurs AID dans votre groupe).

En d'autres termes, il n'existe pas d'état intermédiaire, dans lequel certains AID du groupe peuvent être acheminés vers un service HCE et d'autres vers un autre.

Groupes et catégories AID

Vous pouvez associer chaque groupe AID à une catégorie. Cela permet à Android de regrouper les services HCE par catégorie, ce qui permet à l'utilisateur de définir des valeurs par défaut au niveau de la catégorie plutôt qu'au niveau de l'AID. Évitez de mentionner les AID dans les parties de votre application présentées aux utilisateurs, car ils n'ont aucune signification 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)

Remarque :Un seul groupe AID dans la catégorie CATEGORY_PAYMENT peut être activé dans le système à la fois. Il s'agit généralement d'une application qui comprend les principaux protocoles de paiement par carte de crédit et qui peut fonctionner chez n'importe quel marchand.

Pour les applications de paiement en boucle fermée qui ne fonctionnent que chez un seul marchand (comme les cartes de paiement), utilisez CATEGORY_OTHER. Les groupes d'AID de cette catégorie peuvent être toujours actifs et, si nécessaire, peuvent donner la priorité aux lecteurs NFC lors de la sélection des AID.

Implémenter un service HCE

Pour émuler une carte NFC à l'aide d'une é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 technologie HCE en recherchant la fonctionnalité FEATURE_NFC_HOST_CARD_EMULATION. Utilisez la balise <uses-feature> dans le fichier manifeste de votre application pour déclarer que celle-ci utilise la fonctionnalité HCE et si elle est nécessaire au fonctionnement de l'application.

Implémentation du service

Android 4.4 et les versions ultérieures offrent une classe Service pratique que vous pouvez utiliser comme base pour implémenter un service HCE: la classe HostApduService.

La première étape consiste à étendre HostApduService, comme illustré dans l'exemple de code suivant:

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 implémenter. L'un d'eux, processCommandApdu(), est appelé chaque fois qu'un lecteur NFC envoie un APDU (Application Protocol Data Unit) à votre service. Les APDU sont définies dans la spécification ISO/IEC 7816-4. Les 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 en retour.

Remarque :La spécification ISO/IEC 7816-4 définit également le concept de plusieurs canaux logiques, ce qui vous permet d'avoir plusieurs échanges APDU parallèles sur des canaux logiques distincts. Cependant, l'implémentation de la technologie HCE d'Android n'accepte qu'un seul canal logique. Il n'existe donc qu'un seul échange à thread unique des APDU.

Comme indiqué précédemment, Android utilise l'AID pour déterminer le service HCE avec lequel le lecteur souhaite communiquer. En règle générale, la première APDU qu'un lecteur NFC envoie à votre appareil est une APDU SELECT AID. Cette APDU contient l'AID avec lequel le lecteur souhaite communiquer. Android extrait cet AID de l'APDU, le résout vers un service HCE, puis le transfère au service résolu.

Vous pouvez envoyer une APDU de réponse en renvoyant les octets de l'APDU de réponse à partir de processCommandApdu(). Notez que cette méthode est appelée sur le thread principal de l'application, que vous ne devez pas bloquer. Si vous ne pouvez pas calculer et renvoyer immédiatement une APDU de réponse, renvoyez la valeur "null". Vous pouvez ensuite effectuer le travail nécessaire sur un autre thread et utiliser la méthode sendResponseApdu() définie dans la classe HostApduService pour envoyer la réponse lorsque vous avez terminé.

Android continue de transférer les nouvelles APDU du lecteur à votre service, jusqu'à ce qu'une des deux conditions suivantes se produise:

• Le lecteur NFC envoie une autre APDU SELECT AID, que le système d'exploitation renvoie vers un autre service.
• La liaison NFC entre le lecteur NFC et votre appareil est rompue.

Dans les deux cas, l'implémentation onDeactivated() de votre classe est appelée avec un argument indiquant lequel des deux s'est produit.

Si vous travaillez avec une infrastructure de lecteur existante, vous devez implémenter le protocole existant au niveau de l'application que les lecteurs attendent de votre service HCE.

Si vous déployez une nouvelle infrastructure de lecteur que vous contrôlez également, vous pouvez définir votre propre protocole et séquence d'APDU. Essayez de limiter la quantité d'APDU ainsi que la taille des données à échanger: ainsi, vos utilisateurs n'auront à tenir leur appareil au-dessus du lecteur NFC que pendant une courte période. Une limite supérieure raisonnable est d'environ 1 Ko de données, qui peut généralement être échangée en 300 ms.

Déclaration du fichier manifeste du service et enregistrement d'AID

Vous devez déclarer votre service dans le fichier manifeste comme d'habitude, mais vous devez également ajouter des éléments supplémentaires à la déclaration de service:

1. Pour indiquer à la plate-forme qu'il s'agit d'un service HCE qui implémente une interface HostApduService, ajoutez un filtre d'intent pour l'action SERVICE_INTERFACE à votre déclaration de service.

2. Pour indiquer à la plate-forme les groupes d'AID demandés par ce service, incluez une balise <meta-data> SERVICE_META_DATA dans la déclaration du service, qui renvoie vers une ressource XML contenant des informations supplémentaires sur le service HCE.

3. Définissez l'attribut android:exported sur true et exigez l'autorisation android.permission.BIND_NFC_SERVICE dans votre déclaration de service. La première garantit que des applications externes peuvent être liées au service. Ce dernier garantit ensuite que seules les applications externes détenant l'autorisation android.permission.BIND_NFC_SERVICE peuvent être associées à votre service. Comme android.permission.BIND_NFC_SERVICE est une autorisation système, cela permet de s'assurer que seul l'OS Android peut être lié à 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 renvoie vers un fichier apduservice.xml. Voici un exemple d'un tel 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> contenant une description conviviale du service que vous pouvez afficher dans 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'élément <host-apdu-service> doit contenir une ou plusieurs balises <aid-group>. Chaque balise <aid-group> doit effectuer les opérations suivantes:

• Contenir un attribut android:description qui contient une description conviviale du groupe AID, pouvant être affiché dans l'interface utilisateur
• Définissez son attribut android:category pour indiquer la catégorie à laquelle appartient le groupe AID, comme les constantes de chaîne définies par CATEGORY_PAYMENT ou CATEGORY_OTHER.
• contiennent une ou plusieurs balises <aid-filter>, chacune contenant un seul AID ; Spécifiez l'AID au format hexadécimal et assurez-vous qu'il contient un nombre pair de caractères.

Votre application doit également détenir l'autorisation NFC pour s'enregistrer en tant que service HCE.

Résolution des conflits AID

Plusieurs composants HostApduService peuvent être installés sur un même appareil, et le même AID peut être enregistré par plusieurs services. Android résout les conflits AID différemment selon la catégorie à laquelle appartient l'AID. Chaque catégorie peut être associée à une règle de résolution des conflits différente.

Pour certaines catégories, telles que le paiement, l'utilisateur peut sélectionner un service par défaut dans l'interface utilisateur des paramètres Android. Pour les autres catégories, la règle peut consister à toujours demander à l'utilisateur le service à appeler en cas de conflit. Pour savoir comment interroger la règle de résolution des conflits pour une catégorie spécifique, consultez getSelectionModeForCategory().

Vérifiez 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 une catégorie donnée à l'aide de l'API isDefaultServiceForCategory().

Si ce n'est pas le cas, vous pouvez demander à le définir comme service par défaut à l'aide de ACTION_CHANGE_DEFAULT.

Applications de paiement

Android considère les services HCE qui ont déclaré un groupe AID avec la catégorie payment comme applications de paiement. Android 4.4 et les versions ultérieures contiennent une entrée de menu Paramètres de premier niveau appelée Paiement sans contact, qui énumère toutes ces applications de paiement. Dans ce menu de paramètres, l'utilisateur peut sélectionner l'application de paiement par défaut à appeler lorsqu'un terminal de paiement est utilisé.

Éléments requis pour les applications de paiement

Pour offrir une expérience utilisateur plus attrayante, les applications de paiement HCE doivent 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, définissez une icône carrée sur les bannières obligatoires. Idéalement, elle doit être identique à la conception de l'icône du lanceur d'applications. Cet ajustement crée plus de cohérence et un aspect plus propre.

Android 12 ou version antérieure

Définissez la taille de la bannière de service sur 260 x 96 dp, puis définissez la taille de la bannière de service dans votre fichier XML de métadonnées en ajoutant l'attribut android:apduServiceBanner à la balise <host-apdu-service>, qui pointe vers la ressource drawable. 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>

Écran désactivé et comportement de l'écran de verrouillage

Le comportement des services HCE varie en fonction de la version d'Android exécutée sur l'appareil.

Android 12 ou version ultérieure

Dans les applications qui ciblent Android 12 (niveau d'API 31) ou version ultérieure, vous pouvez activer les paiements NFC sans que l'écran de l'appareil ne soit allumé en définissant requireDeviceScreenOn sur false.

Android 10 ou version ultérieure

Les appareils équipés d'Android 10 (niveau d'API 29) ou version ultérieure sont compatibles avec le NFC sécurisé. Lorsque le NFC sécurisé est activé, tous les émulateurs de cartes (applications hôtes et applications hors hôte) sont indisponibles lorsque l'écran de l'appareil est éteint. Lorsque le NFC sécurisé est désactivé, les applications hors hôtes sont disponibles lorsque l'écran de l'appareil est éteint. Vous pouvez vérifier la compatibilité NFC sécurisée à l'aide de isSecureNfcSupported().

Sur les appareils équipés d'Android 10 ou version ultérieure, la même fonctionnalité pour définir android:requireDeviceUnlock sur true s'applique que sur les appareils équipés d'Android 9 ou version antérieure, mais uniquement lorsque le NFC sécurisé est désactivé. Autrement dit, si le NFC sécurisé est activé, les services HCE ne peuvent pas fonctionner à partir de 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 de l'application sont complètement désactivés lorsque l'écran de l'appareil est éteint. Par conséquent, les services HCE ne fonctionnent pas lorsque l'écran est éteint.

Également sur Android 9 et versions antérieures, les services HCE peuvent fonctionner depuis l'écran de verrouillage. Toutefois, ce paramètre est contrôlé par l'attribut android:requireDeviceUnlock dans la balise <host-apdu-service> de votre service HCE. Par défaut, le déverrouillage de l'appareil n'est pas requis, et votre service est appelé même si l'appareil est verrouillé.

Si vous définissez l'attribut android:requireDeviceUnlock sur true pour votre service HCE, Android invite l'utilisateur à déverrouiller l'appareil dans les cas suivants:

• l'utilisateur tape sur un lecteur NFC.
• le lecteur NFC sélectionne un AID résolu sur votre service.

Après le déverrouillage, Android affiche une boîte de dialogue invitant l'utilisateur à appuyer à nouveau pour terminer la transaction. Cela est nécessaire, car l'utilisateur peut avoir éloigné l'appareil du lecteur NFC afin de le déverrouiller.

Coexistence avec des fiches à composant sécurisé

Cette section intéresse les développeurs qui ont déployé une application qui repose sur un composant sécurisé pour l'émulation de cartes. L'implémentation de la technologie HCE d'Android est conçue pour fonctionner en parallèle avec d'autres méthodes d'implémentation de l'émulation de carte, y compris l'utilisation d'éléments sécurisés.

Remarque :Android ne propose pas d'API permettant de communiquer directement avec un élément sécurisé lui-même.

Cette coexistence est basée sur un principe appelé routage d'AID. Le contrôleur NFC conserve une table de routage composée d'une liste (finie) de règles de routage. Chaque règle de routage contient un AID et une destination. La destination peut être le processeur hôte, où les applications Android s'exécutent, ou un élément sécurisé connecté.

Lorsque le lecteur NFC envoie une APDU avec un SELECT AID, le contrôleur NFC l'analyse et vérifie si les AID correspondent à un AID dans sa table de routage. Si la correspondance est établie, cette APDU et toutes les APDU qui la suivent sont envoyées vers la destination associée à l'AID, jusqu'à ce qu'une autre APDU SELECT AID soit reçue ou que la liaison NFC soit interrompue.

Remarque :Bien que la norme ISO/IEC 7816-4 définisse également le concept de correspondances partielles, elle n'est pas compatible avec les appareils Android HCE.

La figure 4 illustre cette architecture:

Figure 4 : Android fonctionnant à la fois avec une émulation par composant sécurisé et par carte hôte.

Le contrôleur NFC contient généralement également une route par défaut pour les APDU. Lorsqu'un AID est introuvable dans la table de routage, la route par défaut est utilisée. Bien que ce paramètre puisse être différent d'un appareil à l'autre, les appareils Android sont nécessaires pour s'assurer que les AID enregistrés par votre application sont correctement acheminés vers l'hôte.

Les applications Android qui implémentent un service HCE ou qui utilisent un élément sécurisé n'ont pas à vous soucier de la configuration de la table de routage : elle est gérée automatiquement par Android. Android a simplement besoin de savoir quels AID peuvent être gérés par les services HCE et lesquels peuvent être gérés par le composant sécurisé. La table de routage est configurée automatiquement en fonction des services installés et des préférences configurées par l'utilisateur.

La section suivante explique comment déclarer des AID pour les applications qui utilisent un élément sécurisé pour l'émulation de carte.

Enregistrement d'AID par composant sécurisé

Les applications qui utilisent un élément sécurisé pour l'émulation de carte peuvent déclarer un service hors hôte dans leur fichier manifeste. La déclaration d'un service de ce type est presque identique à la déclaration d'un service HCE. Les exceptions sont les suivantes:

• L'action utilisée dans le filtre d'intent doit être définie sur SERVICE_INTERFACE.
• L'attribut du 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 enregistrant 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ôte, car le processeur hôte n'est pas impliqué dans la transaction et ne peut donc pas empêcher l'élément sécurisé d'exécuter des transactions lorsque l'appareil est verrouillé.

L'attribut android:apduServiceBanner est obligatoire pour les services hors hôte qui sont des applications de paiement et peut être sélectionné comme application de paiement par défaut.

Appel de service hors hôte

Android ne démarre jamais ou ne s'associe jamais à un service déclaré comme "hors hôte", 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 d'enregistrer les AID présents sur le composant sécurisé.

HCE et sécurité

L'architecture HCE fournit un élément de sécurité essentiel: comme votre service est protégé par l'autorisation système BIND_NFC_SERVICE, seul le système d'exploitation peut s'associer à votre service et communiquer avec celui-ci. Cela garantit que toute APDU que vous recevez est bien une APDU reçue par le système d'exploitation depuis le contrôleur NFC, et que toutes les APDU que vous renvoyez ne sont transmises qu'au système d'exploitation, qui les transmet à son tour directement au contrôleur NFC.

La dernière préoccupation consiste à récupérer les données que votre application envoie au lecteur NFC. Elle est intentionnellement dissociée dans la conception HCE. L'origine des données n'est pas importante, mais elle s'assure simplement qu'elles sont transmises en toute sécurité 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 à partir de votre service HCE, vous pouvez, par exemple, vous appuyer sur le bac à sable d'application Android, qui isole les données de votre application des autres applications. Pour en savoir plus sur la sécurité d'Android, consultez les conseils de sécurité.

Paramètres et détails du protocole

Cette section est intéressante pour les développeurs qui souhaitent comprendre les paramètres de protocole utilisés par les appareils HCE pendant les phases d'anti-collision et d'activation des protocoles NFC. Cela permet de créer une infrastructure de lecteur compatible avec les appareils HCE Android.

Anti-collision et activation du protocole Nfc-A (ISO/IEC 14443 type A)

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, qui doit être considéré comme ayant un UID aléatoire. Cela signifie qu'à chaque appui, 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 d'authentification ou d'identification.

Le lecteur NFC peut ensuite sélectionner l'appareil HCE en envoyant une commande SEL_REQ. La réponse SEL_RES de l'appareil HCE comporte au moins 6 bits (0x20), ce qui indique que l'appareil est compatible avec la norme ISO-DEP. Notez que d'autres bits de SEL_RES peuvent également être définis, ce qui indique par exemple la compatibilité avec le protocole NFC-DEP (p2p). Étant donné que d'autres bits peuvent être définis, les lecteurs qui souhaitent interagir avec les appareils HCE doivent rechercher explicitement le 6e bit uniquement, et ne pas comparer le SEL_RES complet avec une valeur de 0 x 20.

Activation ISO-DEP

Une fois le protocole Nfc-A activé, le lecteur NFC lance l'activation du protocole ISO-DEP. Il envoie une commande RATS (Request for Answer To Select). Le contrôleur NFC génère la réponse RATS (l'ATS). Celui-ci n'est pas configurable par les services HCE. Toutefois, les implémentations HCE doivent respecter les exigences NFC Forum pour la réponse ATS, afin que les lecteurs NFC puissent compter sur la définition de 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 la réponse 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 que TA(1), To(1) et TC(1) sont inclus dans la réponse ATS. Les bits de 1 à 4 indiquent la FSCI, en codant la taille maximale de trame. Sur les appareils HCE, la valeur de FSCI doit être comprise 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étriques. Les appareils HCE ne sont soumis à aucune exigence ni garantie en matière de débit.
• T(B)1: les bits 1 à 4 indiquent l'entier de temps de la protection de trame au démarrage (SFGI). Sur les appareils HCE, la SFGI doit être inférieure ou égale à 8 h. Les bits 5 à 8 indiquent l'entier du temps d'attente de frame (FWI) et codent le temps d'attente des frames (FWT). Sur les appareils HCE, la durée d'exposition FWI doit être inférieure ou égale à 8 h.
• T(C)1: le bit 5 indique la compatibilité avec les "fonctionnalités avancées du protocole". Les appareils HCE peuvent être compatibles ou non avec les "fonctionnalités avancées du protocole". Le bit 2 indique la prise en charge de DID. Les appareils HCE peuvent être compatibles ou non avec le DID. Le bit 1 indique la compatibilité avec la NAD. Les appareils HCE ne doivent pas être compatibles avec la NAD et définir le bit 1 sur zéro.
• Octets historiques: les appareils HCE peuvent afficher jusqu'à 15 octets historiques. Les lecteurs NFC disposés à interagir avec les services HCE ne doivent émettre aucune hypothèse concernant le contenu des octets historiques ni leur présence.

Notez que de nombreux appareils HCE sont probablement conformes aux exigences de protocole spécifiées par les réseaux de paiement unis dans EMVCo dans leur spécification "Protocole de communication sans contact". En particulier :

• La FSCI dans 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 accepté. Les débits asymétriques entre le lecteur et l'émulateur ne sont pas acceptés.
• FWI dans 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. Toute tentative de sélection d'applications sur différents canaux logiques ne fonctionne pas sur un appareil HCE.