Qu'est-ce que l'émulation de carte par l'hôte sur Android ?
L'émulation de carte par l'hôte permet à une application Android de répondre elle-même à un lecteur externe, en logiciel, au lieu d'acheminer l'échange vers une puce d'élément sécurisé. Elle a supprimé le gardien matériel qui contrôlait jadis qui pouvait déployer une application de carte, et a déplacé le problème de sécurité vers le système d'exploitation et le serveur.
Ce qu'elle a remplacé
Avant l'émulation de carte par l'hôte, présenter une carte depuis un téléphone signifiait loger le justificatif dans un élément sécurisé : une puce matérielle, physiquement présente dans l'appareil ou dans la carte SIM, et contrôlée par le propriétaire de ce matériel.
Ce contrôle était l'obstacle. Une banque ou un opérateur de transport souhaitant déployer une application de carte devait négocier un accès avec un fabricant de téléphones ou un opérateur mobile, relation par relation. La technologie fonctionnait, les arrangements commerciaux ne passaient pas à l'échelle.
Comment elle fonctionne
Android achemine l'échange vers une application au lieu d'une puce. Google documente le mécanisme sous le nom d'émulation de carte par l'hôte.
Une application déclare quelles applications de carte elle sait traiter, au moyen d'identifiants que les terminaux réclament par leur nom. Quand un lecteur demande l'un d'eux, le système réveille l'application enregistrée et lui passe l'échange. L'application répond, commande après commande, en logiciel.
La conséquence est qu'aucun gardien matériel n'intervient. Tout développeur peut publier une application qui répond à un lecteur, sans demander l'autorisation d'un fabricant.
Où la sécurité est passée
Elle n'a pas disparu, elle s'est déplacée, et comprendre où fait la différence entre un usage correct et une construction fragile.
Un élément sécurisé résiste à l'extraction physique de ses clés. Une application qui s'exécute sur le processeur principal, non, et c'est pourquoi les justificatifs traités ainsi sont typiquement des jetons à courte durée de vie récupérés depuis un serveur plutôt qu'un secret permanent posé sur l'appareil. Volez le jeton, il expire. Volez l'appareil, le jeton ne vaut rien sans ce qui l'a déverrouillé.
Le modèle est donc passé de la protection d'un secret dans le matériel à la limitation de ce que vaut un secret volé. Les deux fonctionnent, et ils échouent différemment.
Quand l'employer
C'est le bon mécanisme quand vous maîtrisez les deux bouts : votre propre application sur le téléphone, vos propres lecteurs sur le terrain. Programmes de fidélité, contrôle d'accès pour un système que vous exploitez, billetterie quand vous tenez aussi les portiques.
C'est le mauvais outil pour usurper un justificatif émis par quelqu'un d'autre. Se déclarer pour traiter un identifiant ne vous donne pas les clés que détient la vraie carte, et le terminal refusera l'échange même si votre application a répondu.
Enfin, l'émulation de carte par l'hôte ouverte, accessible à toute application, est propre à Android. Depuis iOS 17.4, Apple propose un équivalent sous conditions via sa plateforme NFC and SE : une application titulaire de l'habilitation d'Apple, sous accord commercial, peut émuler des cartes, mais seulement par cette voie contrôlée et non par une voie ouverte. La voie dont vous disposez décide en général de la conception avant toute autre chose.
Questions fréquentes
L'émulation par l'hôte exige-t-elle une connexion internet ?
L'échange avec le lecteur, non, mais les implémentations qui emploient des jetons à courte durée de vie ont besoin de connectivité pour les obtenir. Que le téléphone fonctionne hors ligne dépend du nombre de jetons récupérés d'avance plutôt que du mécanisme lui-même.
Est-ce moins sûr qu'un élément sécurisé ?
C'est autrement sûr. Un élément sécurisé protège une clé permanente dans le matériel, tandis que ce modèle limite la valeur de ce qui peut être extrait. Pour bien des usages, le second suffit et se déploie infiniment plus facilement.
Puis-je l'employer pour émuler une carte MIFARE Classic ?
Non. Le mécanisme traite l'échange de commandes standard qu'emploient les applications de carte, pas les schémas propriétaires qui opèrent sous cette couche. C'est l'une des raisons pour lesquelles les systèmes bâtis sur Classic résistent aux justificatifs de téléphone.
Existe-t-il un équivalent iOS ?
Pas d'équivalent ouvert. Apple propose une voie sous conditions depuis iOS 17.4, sa plateforme NFC and SE, réservée aux applications titulaires de son habilitation sous accord commercial, et non un mécanisme général ouvert à toute application. Une conception multiplateforme ne peut pas supposer que l'approche Android ouverte se transpose.