Une histoire du Pass Navigo sur Android, de l’Apple Wallet et des différentes solutions mobiles
Récemment, les transports publics d’Île-de-France ont annoncé la disponibilité du Pass Navigo sur smartphone… mais uniquement sur Android.
Si le dispositif n’est pas disponible sur iPhone, cela tient à des raisons de différences techniques entre les deux systèmes, ainsi qu’à des stratégies distinctes. Avant d’aborder le cas de Navigo, découvrons les solutions au service de l’identification et du paiement mobile.
Dans un article précédent, nous avons exploré ce que pourraient être les concepts d’identification et d’authentification de demain. Dans celui-ci, nous nous concentrerons sur les solutions technologiques actuelles et leaders du marché pour le mobile.
Quel est le lien entre le pass Navigo et le paiement mobile ? En fin de compte, tout est une question d’identification ! Qu’il s’agisse d’une carte de transport ou d’une carte bancaire, c’est toujours une question d’identification (par exemple, la carte bancaire est une forme d’identité qui prouve que je suis le propriétaire d’un compte bancaire utilisé pour une transaction demandée).
Lorsque nous parlons de transactions, ne nous limitons pas aux transactions financières ; parlons de transactions de données (ce qui est le cas des transactions financières).
J’espère que les spécialistes me pardonneront une fois de plus mes raccourcis pour des raisons pédagogiques 😉.
Pour de multiples raisons de sécurité, l’intégration et l’utilisation d’une carte dans un smartphone nécessitent un certain niveau de complexité. Toutes les solutions existantes ont les mêmes objectifs : établir le bon propriétaire de cette carte, prouver que cette carte est valable, sécuriser les données associées et leurs activités (la transaction, entre autres).
Toutes ces solutions partagent un fonctionnement commun : elles utilisent un élément matériel (ou logiciel, comme nous le verrons) spécifique pour atteindre ces objectifs de sécurité. Il porte un nom logique, puisqu’on l’appelle le « Secure Element ».
Vous avez peut-être déjà entendu parler du « Secure Element » grâce à Apple; nous détaillerons son fonctionnement particulier plus tard.
Sur le « Secure Element », les données de la carte sont chiffrées (mais de différentes manières selon les solutions) ; et il est utilisé à chaque transaction de données comme garant de la validité de la carte et de cette transaction.
En gros, le « Secure Element » est le « tiers de confiance » technologique.
Enfin, un « Secure Element » est isolé du reste de l’appareil pour prévenir les intrusions.”
La solution « Sim Centric »
La première solution, historique, est la « Sim Centric ». Elle fait partie d’une catégorie de solutions plus larges nommées « Universal Integrated Circuit Card (UICC) » (la carte SIM est tout simplement une « Circuit Card », une carte de circuit imprimé).
Comme son nom l’indique, cette solution utilise la carte SIM comme élément de sécurité physique. En soi, la « Sim Centric » est un bon système de sécurité, puisque la carte SIM est conçue en dehors du système matériel et du système d’exploitation.
Cependant, cette solution est en déclin en raison de complications liées à l’accord et à l’organisation entre les acteurs de la chaîne de paiement mobile. D’abord, il faut une SIM spéciale NFC. L’opérateur de téléphonie doit créer des partenariats avec l’émetteur de la carte (banque et EMVCO/Visa, Mastercard…) via un TSM (Trust Service Manager) ; en gros, c’est le système d’échange entre ces acteurs. L’opérateur de téléphonie joue un rôle majeur dans tout ce parcours.
Et c’est précisément l’une des raisons principales qui ont poussé, à l’origine, les fabricants de smartphones et les développeurs de systèmes d’exploitation mobiles comme Apple, Samsung et Google à abandonner la Sim Centric pour éviter le monopole des opérateurs.
Depuis, il est possible que de nouvelles évolutions donnent raison aux concurrents de la Sim Centric : La SIM, telle que nous la connaissions jusqu’à récemment, est peut-être en train de disparaître (salut, e-SIM !) et pourrait perdre sa caractéristique propre d’être physiquement déconnectée du système. Les autres solutions, comme vous le verrez, sont également en train de proposer des avancées techniques qui surpasseront celles de la SIM.
La solution HCE
La Host Card Emulation (HCE) utilise les mêmes principes que la Sim Centric, à ceci près qu’elle n’existe pas physiquement. Elle est remplacée par une sorte de « e-SIM » ou plutôt de Secure Element dématérialisé dans le cloud.
Cette technologie, qui n’est pas récente, a été mise en œuvre sur Android (version 4.4 à l’époque) en 2013. Par conséquent, elle n’est disponible que sur les smartphones utilisant l’OS de Google.
Toutes les données de la carte d’identification ou de paiement ne sont pas hébergées sur ce Secure Element dans le cloud. Une partie reste sur le smartphone. Ainsi, lors d’une demande de transaction de données, le système interroge les données du cloud et celles en local, puis les « assemble ». Si une partie manque, la transaction ne peut pas avoir lieu.
Bien sûr, comme avec la Sim Centric, les données de la carte sont chiffrées, que ce soit sur le serveur ou en local. Mais surtout, la HCE a amené la sécurité à un niveau jamais atteint auparavant : la tokenisation.
La tokenisation
Le terme ‘token’, ou jeton, en informatique fait référence à une représentation numérique d’un droit à utiliser un service. C’est assez similaire à l’idée des jetons que vous pourriez utiliser dans une fête foraine pour accéder à une attraction. Pourtant, je préfère traduire ‘token’ par ‘certificat’, car le droit d’utiliser un service n’est qu’un exemple parmi d’autres de ce que peut représenter un token. Il peut aussi représenter une valeur, une propriété, une signature, une identité… c’est en effet une des pierres angulaires de la technologie blockchain.
Un token est en fait un ensemble de données qui a été crypté pour empêcher des personnes ou des organisations d’accéder à des informations sensibles. Cet ensemble de données rend le token unique pour un usage spécifique.
Prenons l’exemple du paiement mobile. Dans ce cas, on crypte plusieurs types de données : celles de la carte bancaire et les détails de la transaction. Chaque fois qu’un utilisateur souhaite effectuer un paiement avec un smartphone Android (qui utilise la technologie HCE), un token est créé. Ce token est donc un élément plutôt éphémère, car il est généré à chaque transaction et ensuite supprimé. Grâce à la tokenisation, les commerçants, qu’ils soient en ligne ou en magasin, n’ont jamais accès aux informations personnelles de l’utilisateur.
Comment se déroule concrètement le parcours de paiement en HCE avec un token ?
- Premièrement, l’utilisateur ouvre l’application Google Pay.
- Ensuite, il positionne son smartphone sur le lecteur, qui peut être un TPE dans le cas d’un paiement, ou un validateur dans le cas d’une carte de transport.
- Une communication NFC s’établit alors entre les deux appareils.
- Le système se met ensuite en action pour rassembler les données de la carte, provenant du stockage local et du cloud, afin de vérifier leur authenticité.
- Une demande est envoyée à un serveur de tokenisation. Ce dernier va créer le token à partir de l’ensemble des données et de la validation de l’émetteur (banque + Visa/Mastercard) pour valider la création du token.
- La validation de la transaction est alors transmise au TPE.
- Enfin, le processus se poursuit de manière identique à un parcours bancaire classique, comme avec une carte bancaire physique.
Peut-on effectuer un paiement hors ligne, comme cela peut être le cas avec une carte bancaire, si la création du token nécessite une connexion réseau pour accéder au serveur/service de tokenisation ?
Avec la solution HCE, la réponse est oui ! En effet, lorsque le dispositif dispose d’une connexion réseau, il télécharge plusieurs tokens qui sont conservés sur le smartphone pour une utilisation hors ligne.
Il est important de souligner que la tokenisation n’est pas utilisée uniquement pour les paiements, mais s’applique à toutes les opérations d’identification via un smartphone.
C’est précisément le cas pour le pass Navigo. L’abonnement aux transports en commun parisiens n’est actuellement disponible que sur Android, car Île-de-France Mobilités n’a jusqu’à présent travaillé que sur l’intégration de ce système.
Secure Element d’Apple Wallet (et de Samsung)
Tout comme les autres solutions, celle d’Apple partage certaines caractéristiques. Nous avons toujours affaire à un Secure Element (SE), c’est-à-dire un composant informatique qui sécurise les données de la carte (de paiement, d’identification, etc.) en stockant les données chiffrées de celle-ci et en garantissant la sécurité et l’intégrité des transactions de ces informations sensibles.
À l’inverse de la HCE, le Secure Element est bel et bien physique et installé directement sur le matériel du smartphone. Si la SIM était également considérée comme un Secure Element, celle-ci était gérée par l’opérateur téléphonique et non par le fabricant du smartphone.
Avec Apple Wallet, le SE est conçu et fabriqué pour fonctionner de pair avec l’appareil. Cependant, rappelons qu’un SE doit être suffisamment isolé du reste du matériel pour éviter toute attaque. Le SE de l’iPhone est un sous-système isolé du processeur principal, selon Apple.
Il possède son propre stockage, son propre processeur, voire son propre système d’exploitation ! Bref, il a tout le nécessaire pour fonctionner en totale autonomie.
Pour pouvoir être utilisé avec le reste de l’appareil et les services d’identification, il existe des sortes de “ponts” sécurisés (chiffrés) et conçus uniquement pour les besoins de paiement et d’identification. Toutes les données ou transactions de données qui ne correspondent pas aux parcours de paiement ou d’identification et qui transitent par ces ponts ne peuvent être admises par le système.
Le SE n’est pas dématérialisé dans un cloud, ce qui élimine les possibilités d’attaques serveur.
Tout comme les autres solutions que nous avons précédemment examinées, le Secure Element utilise la tokenisation, mais à de nombreux niveaux, ce qui permet d’accroître considérablement la sécurité.
Lors de la fabrication d’un iPhone, une clé cryptographique est générée pour créer un identifiant unique lié à l’appareil et donc au Secure Element. La spécificité du token d’identification de l’appareil chez Apple est que cette clé est créée par le Secure Element pendant la fabrication de l’iPhone. Ainsi, même Apple n’y a pas accès.
Passons à présent aux détails de l’intégration et de l’utilisation de l’Apple Wallet. Notons qu’avant même d’évoquer le processus de paiement, l’étape d’enregistrement constitue déjà une solide démonstration de sécurité :
- Lors de l’enregistrement de votre carte, ses données sont chiffrées puis envoyées à un serveur spécifique d’Apple.
- Ces informations sont transférées à la banque de l’utilisateur (et à l’organisme émetteur, tel que Visa) via un réseau spécifique établi entre celle-ci et Apple. Il est donc nécessaire que la banque soit partenaire d’Apple Wallet.
- La banque valide l’authenticité de la carte.
- Une demande de création de token est envoyée à un “TSP” (Token Service Providers), un service de création de tokens. Dans le cadre du paiement, il s’agit d’un service géré par le réseau “EMVCo” (le réseau de Visa et Mastercard). Le token généré comprend les données de la carte bancaire et des identifiants uniques (des tokens dans le token, pour être précis), liés à la création du token sur le réseau EMVCo.
- Le token est envoyé à la banque, puis aux serveurs spécifiques d’Apple. Ce token ne peut pas être utilisé par Apple en cas d’attaque serveur, car il contient des données uniques du réseau EMVCo qui sont connues d’eux seuls.
- Le token est finalement envoyé à l’appareil et sauvegardé sur le Secure Element. Ce token est une signature/identité unique qui représente votre carte sur l’Apple Wallet
Comme vous pouvez le constater, les deux premières phases de tokenisation de l’Apple Wallet sont complexes. Cependant, ce n’est pas tout ! Examinons maintenant le processus de paiement ou d’identification, c’est-à-dire l’utilisation d’une carte dans l’Apple Wallet.
Le début du processus dépend bien sûr de l’utilisation. Dans un cas « physique » (paiement sur un terminal de paiement en magasin, validateur dans un transport en commun, lecteur dans un cinéma, etc.), on utilise la communication NFC entre le smartphone et le lecteur. Cette communication respecte les protocoles créés par EMVCo/Visa-Mastercard, des protocoles déjà utilisés pour le paiement sans contact des cartes bancaires.
L’Apple Wallet peut bien sûr être utilisé sur des services web et des applications mobiles.
- La première étape de l’utilisation d’une carte sur l’Apple Wallet est la vérification de l’identité du propriétaire de la carte par l’authentification biométrique (ou code PIN dans le cas d’une impossibilité de reconnaissance biométrique. Personnellement, je ne comprends pas le choix d’Apple qui est de passer d’un système hautement sécurisé comme FaceID à un simple code numérique).
- L’iPhone génère des cryptogrammes dynamiques, un élément chiffré différent d’un token mais dont les objectifs sont similaires. Ce cryptogramme intègre le token d’identité stocké et spécifique à votre iPhone et votre carte bancaire. Ainsi, le commerçant ne peut pas voir les données bancaires.
- Ces cryptogrammes sont envoyés au terminal de paiement qui fait la demande au réseau EMVCo, le réseau d’émetteur de carte.
- Le « TSP » (« Token Service Providers ») valide la véracité du token.
- Le token est partiellement déchiffré pour être validé par les banques
Pour plus de détail sur ce parcours : https://codeburst.io/how-does-apple-pay-actually-work-f52f7d9348b7
À terme, il est possible que les solutions de type Secure Element (SE) matérielles comme celle d’Apple fassent appel à la technologie de la blockchain pour certaines utilisations, comme les cryptomonnaies et les biens numériques.
Dans d’autres exemples comme les titres de transport, les cartes d’identité, les billets de cinéma, etc., le parcours est presque le même. Cependant, les acteurs changent : par exemple, le service de création de token ou les différents réseaux de traitement sont gérés par un fournisseur de services spécialisé commandé par le fournisseur de service (par exemple, le gestionnaire des transports en commun) ou par le fournisseur lui-même.
Cependant, tout ne peut pas être fait sans respecter les protocoles du portefeuille d’Apple. C’est pour cette raison que l’implémentation peut prendre du temps, car elle est conçue en partenariat entre le service et la marque à la pomme.
Si le service souhaite s’intégrer dans l’application Wallet, c’est relativement simple. Mais dans le cas d’une application séparée, c’est plus délicat et peut être source de conflit entre les fabricants de smartphones et les fournisseurs de services, comme cela a été le cas avec Navigo par exemple.
Le cas Navigo et les app wallet natives
Historiquement, les abonnements et tickets Navigo ont été intégrés en premier sur les smartphones Samsung. Le constructeur utilise une solution similaire à celle d’Apple, c’est-à-dire un Secure Element matériel propriétaire, avec quelques différences spécifiques.
Récemment, nous avons vu l’arrivée de certains titres et abonnements de transports parisiens sur d’autres smartphones Android. Comme prévu, la solution utilisée est le HCE (Host Card Emulation).
Comme nous l’avons vu précédemment, les différents systèmes proposés par les fabricants nécessitent des partenariats et l’assimilation de leurs solutions. Cependant, dans le cas de Navigo, il y a une complexité supplémentaire. Toutes les solutions décrites et leurs parcours systémiques sont valables lorsque une carte est intégrée directement dans l’application Wallet native du smartphone.
Je ne doute pas que, à moyen terme, des fournisseurs de token, des réseaux universels et interopérables seront créés pour tous les cas d’usage (paiement, transport, loisirs, abonnements, identités, etc.). Cependant, il est compliqué de vouloir faire sa propre application à côté de cela.
Pour le HCE, comme la solution est principalement liée au cloud, les liens entre une application “maison” du service et le SE (Secure Element) sont plus faciles à établir. En effet, le HCE a été créé en partie pour cela.
Pour un SE matériel comme celui d’Apple ou de Samsung, il n’y a pas d’API toutes faites permettant de créer des ponts, car chaque application a sa propre conception et son propre développement. A chaque fois qu’une application maison est créée, l’entreprise qui crée le service doit travailler avec Apple pour trouver des solutions à cette problématique.
C’est pour cette raison que l’intégration du Pass Navigo sur iPhone risque de prendre du temps. En effet, Apple et Samsung cherchent à garder le contrôle total sur la sécurité en gérant complètement le système.
D’un point de vue pragmatique, cela est tout à leur honneur. Cependant, certains d’entre vous pourraient ne pas partager la même approche.
Quant à moi, mes objectifs sont toujours orientés vers la sécurité et l’amélioration de l’expérience utilisateur.
Du point de vue de l’expérience utilisateur, il est très avantageux d’avoir tout intégré dans une seule application, avec la même ergonomie, le même fonctionnement d’une carte à une autre, un parcours fluide… C’est un argument majeur (en plus de la sécurité) pour l’utilisation d’un système fermé. D’autant plus lorsque l’on constate que l’expérience utilisateur n’est pas toujours bien prise en compte dans de nombreux services. Personnellement, je suis un grand fan des “super-apps” qui regroupent plusieurs services complémentaires.
Imaginez à quel point l’expérience serait fluide si votre carte de transport en commun, de VTC ou de vélo en libre-service était connectée à votre abonnement de théâtre. À la fin d’une pièce, l’une pourrait automatiquement envoyer des informations à l’autre pour réserver et rendre immédiatement accessible un moyen de transport…
Un autre point de vue que je tiens à souligner : vouloir créer sa propre application sans utiliser celle du smartphone est à mon avis l’expression d’un égo très européen, voire français. Si vous avez bien suivi cet article, vous aurez compris que l’argument du risque de voir ses données hébergées sur des serveurs étrangers plutôt que sur des serveurs souverains ne tient pas.
- Les données pour un Secure Element matériel sont stockées localement.
- Ces données sont représentées par un token, un certificat chiffré qu’Apple ne peut décrypter lui-même. Ce token est transféré sous cette même forme aux émetteurs de cartes bancaires et aux banques.
- En ce qui concerne les réseaux utilisés pour les transferts, ils ne relèvent pas de la responsabilité d’Apple mais de celle d’EMVCo, le réseau de Visa et Mastercard.
En conséquence, je pense que développer sa propre application représente un risque inutile pour les utilisateurs. C’est aussi un investissement financier conséquent et une importante consommation de temps. D’autant plus qu’il est inévitable de s’adapter aux systèmes des constructeurs de smartphones.
Cela dit, je ne rejette pas complètement les applications propriétaires des entreprises. En effet, elles sont utiles pour gérer les spécificités de leurs services et produits. Mais il serait préférable de laisser les systèmes de paiement et d’identification à des systèmes spécialisés dans ces domaines.
Je l’avoue, je rêve d’une Super-app Wallet ! Une application qui permettrait de gérer l’ensemble de nos besoins d’identification et d’activités connexes.
Un service unique, avec une expérience utilisateur unique et fluide, où je pourrais retrouver mes moyens de paiement, mon historique, mon budget, mes factures… mais aussi mes cartes de fidélité, mes billets de spectacle, mes offres… mes moyens d’identification et d’authentification sur des sites ou pour des produits physiques… ma clé de voiture, ma clé de maison… où chaque service apporte une expérience à la suite d’un autre service.
Et bien sûr, le tout avec la meilleure des sécurités et la plus grande des transparences, grâce à toutes les solutions que nous avons pu explorer dans cet article ; ou même des solutions novatrices comme la blockchain !
