[Dossier paiement et identification] Une histoire du Pass Navigo sur Android, de l’Apple Wallet et des différentes solutions mobiles

Dans un précédent article, nous avons parlé de ce qui font et feraient les concepts de l’identification et l’authentification de demain.
Dans celui-ci nous nous concentrerons sur les solutions technologiques actuelles, et leader du marché, sur le mobile.

Quel rapport entre le pass Navigo et le paiement mobile? Tout n’est au final qu’un parcours d’identification!
Que ce soit une carte de transport ou une carte bancaire, il s’agit à chaque fois d’une question d’identification (carte bancaire : carte d’identité qui prouve que je suis le propriétaire d’un compte bancaire utilisé pour une transaction demandée).
Enfin quand on parle de transactions, ne nous limitons pas à des transactions financières ; mais parlons de transaction de données (ce qui est bien le cas pour une transaction financière).

J’espère que les spécialistes me pardonneront une fois de plus mes quelques raccourcis à des fins pédagogiques 😉.

Pour de multiples raisons de sécurité, intégrer et utiliser une carte dans un smartphone demande un certain niveau de complexité. Les solutions existantes ont toutes 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 : utiliser un élément hardware (ou software comme on le verra) spécifique pour remplir ces objectifs de sécurité. Son nom est logique, puisqu’on l’appelle le « Secure Element ».

Vous avez déjà dû en entendre parler grâce à Apple qui l’a un peu démocratisé via son « Secure Enclave » ; dont nous détaillerons le fonctionnement particulier plus tard.
Sur le « Secure Element » les données de la carte son chiffrées (mais de manières différentes suivant les solutions) ; et il est utilisé à chaque transaction de données en tant que 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 relativement séparé du reste de l’appareil pour éviter les intrusions.

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 Secure Element physique.

En soit, la « Sim Centric » est un bon système sécuritaire ; puisque la carte SIM est conçue en dehors du système hardware et de l’OS.
Néanmoins, la solution est en déclin car liée à des complications d’entente et d’organisation entre acteurs de la chaîne de paiement mobile.

Déjà, il faut une SIM spéciale NFC. L’opérateur téléphonique doit créer des partenariats avec l’émetteur de la carte (banque et EMVCO/Visa, Mastercard…) via un TSM (Trust Service Manager) ; en gros le système d’échange entre ces acteurs.
L’opérateur téléphonique joue un rôle majeur dans tout ce parcours.
Et c’est justement une des raisons principales qui ont poussé, à l’origine, les constructeurs de smartphone et d’OS mobile comme Apple, Samsung et Google de délaisser 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, comme on la connaissait jusqu’à peu, est peut-être en train de disparaitre (coucou la e-sim !) et n’aura plus sa caractéristique propre d’être déconnectée physiquement du système. Les autres solutions, comme vous le verrez, sont également en train de proposer des avancées techniques qui dépasseront celles de la SIM.

Solution “Sim-Centric” (“TSM” et “MNO” : l’opérateur téléphonique qui est tiers de confiance)

La HCE, pour « Host Card Emulation », utilise les mêmes principes que la Sim Centric ; sauf qu’elle n’existe pas physiquement et est remplacée par une sorte de « e-sim » ou plutôt de Secure Element ; mais dématérialisée dans le Cloud.
Cette technologie n’est pas vraiment récente puisqu’elle a été conçue sur Android (4.4 en ce temps-là) en 2013. Elle n’est donc 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 cette Secure Element dans le cloud. Une partie reste sur le smartphone.

Ainsi lors de la demande de transaction de données, le système interroge les données du cloud et celles en local et les « rassemble ». Si une partie est manquante, la transaction ne peut pas se faire.
Bien sûr, comme sur la Sim Centric, les données de la carte sont chiffrée; sur le serveur comme en local.

Surtout, la HCE a amené à un nouveau niveau de solution de sécurité jamais atteint : la tokenisation.

Solution “HCE” (avec tokenisation)

On a souvent parlé de ce concept dans les précédents articles ; mais faisons un rapide rappel du fonctionnement.

Un token est, en informatique, un jeton. Il s’agit bien du même objectif d’usage que le petit rond en plastique que l’on utilise dans les fêtes foraines. Un jeton est une représentation d’un droit à l’utilisation d’un service (comme l’est la voiture tamponneuse).
Personnellement, je préfère traduire « token » par « certificat ». Car le droit d’utilisation d’un service n’est qu’un cas d’usage du token parmi d’autres. Il peut représenter une valeur, une propriété, une signature, une identité… (ça ne vous rappelle pas quelque chose ? Oui, la blockchain ! L’un des grands principes de la blockchain est la tokenisation !).

Le token est un ensemble de données que l’on a chiffré pour éviter que des personnes, organisations… n’accèdent à ces données sensibles.

Cet ensemble de données font du token un élément unique dans le cas d’un usage spécifique.
Dans le cas du paiement par exemple, on chiffre plusieurs types de données : celles de la carte bancaire et les détails de la transaction.
Dès que l’on veut effectuer un paiement avec un smartphone Android, sous HCE donc, un token est créé. Il s’agit donc un composant plutôt éphémère ; puisqu’il est produit à chaque transaction puis effacé.
Le token permet aux commerçants physiques ou numériques de n’avoir accès à aucune information appartenant à l’utilisateur.

Concrètement, comme se déroule le parcours de paiement en HCE avec un token ?

  • l’utilisateur ouvre l’application Google Pay
  • il appose son smartphone sur le lecteur (un TPE dans le cas d’un paiement ; ou un validateur dans le cas d’une carte de transport)
  • il y a une communication NFC entre les deux appareils
  • le système se met en place pour rassembler les données de la carte (local + cloud) et prouver sa véracité
  • une demande est envoyée à un serveur de tokenisation qui va créer le token à partir de toutes les données + de la validation de l’émetteur (banque + visa/mastercard) pour valider la création du token
  • la validation de la transaction est envoyé au TPE
  • on passe en mode parcours bancaire classique comme avec une CB physique

Étant donné que la création du token demande une connexion réseau pour avoir accès au serveur/service de tokenisation, est-il possible de réaliser un paiement en offline comme dans certains cas avec une CB ?
Dans le cas de la solution HCE, oui ! Pour cela, le device va télécharger plusieurs token sur le smartphone tant qu’il a une connexion réseau. Ils seront gardés « en réserve » pour un usage offline.

Encore une fois on rappelle que la tokenisation ne sert pas uniquement au paiement mais à tout parcours d’identification via smartphone.
C’est exactement le cas pour le pass Navigo. L’abonnement des transports en commun Parisien n’est disponible uniquement que sur Android car Île-de-France Mobilités n’a travaillé pour l’instant que sur l’intégration de ce système.

Comme les autres solutions, celle d’Apple partage des fonctionnements communs.

On parle toujours d’un Secure Element (SE), c’est-à-dire d’un élément informatique qui sécurise les données de la carte (de paiement/identification/…) en stockant les données chiffrées de la carte et en étant garant de la sécurité et de la véracité de la transaction de ces données sensibles.
Contrairement à HCE, le Secure Element est bien physique et donc installé sur l’hardware du smartphone. Mais si la SIM était aussi considérée comme un Secure Element, cette dernière n’était pas gérée par le constructeur de smartphone mais par l’opérateur téléphonique.

Avec Apple Wallet, la SE est fabriquée et conçue pour travailler de pair avec le device. Néanmoins, rappelons qu’un SE doit être suffisamment déconnectée du reste du hardware pour éviter toutes attaques. Le SE de l’iPhone appelé « Secure Enclave » est, comme le dit Apple, un sous-système isolé du processeur principal.
Il dispose de son propre stockage, de son propre processeur… et même d’un OS ! Bref, son propre système pour travailler en totale autonomie.

Pour être utilisé avec le reste du device et les services d’identification, il existe des sortes de « ponts » sécurisés (chiffrés) et créés (programmés) uniquement pour les besoins de paiement et d’identification. Toutes données ou transactions de données ne correspondant pas aux parcours de paiement/identification qui transitent sur ces ponts, ne peuvent être admises par le système.
Le SE n’est pas dématérialisé dans un cloud, pas de possibilités d’attaques serveurs.

Comme les autres solutions vues précédemment, le Secure Enclave utilise la tokenisation ; mais sur de nombreux niveaux qui permettent d’augmenter nettement la sécurité.

A la fabrication d’un iPhone, une clé cryptographique est générée pour représenter un identifiant unique lié au device et donc au Secure Enclave. La spécificité d’un token d’id du device chez Apple, est que cette clé est créée par le Secure Enclave pendant la fabrication de l’iPhone. Ainsi, même Apple ne peut y avoir accès.

Passons maintenant au détail du parcours d’intégration et d’utilisation de l’Apple Wallet.

Avant de parler du paiement, celui de l’enrôlement est aussi une démonstration de sécurité :

  • lors de l’enregistrement de votre carte, les données de celles-ci sont chiffrées et envoyées à un serveur spécifique d’Apple
  • elles sont transférées à la banque de l’utilisateur (+ l’organisme émetteur comme Visa) via un réseau spécifique créé entre elle et Apple (d’où la nécessite que la banque soit partenaire d’Apple Wallet)
  • la banque valide la véracité de la carte
  • une demande de création de token est envoyé à un « TSP » (« Token Service Providers » ou un service de création de token. Dans le cas du paiement il s’agit d’un service géré par le réseau « EMVCo » (le réseau de Visa et Mastercard). Le token intègre les données de la CB et des identifiantes uniques (des tokens dans des tokens plus exactement) 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 être utilisé par Apple en cas d’attaque serveur puisqu’il possède des données uniques du réseau EMVCo que seuls eux connaissent
  • le token est envoyé au device et sauvegardé sur le Secure Element. Ce token est une signature/identité unique qui représente votre carte sur l’Apple Wallet
Enrôlement de la carte [source : Prashant Ram — https://bit.ly/3eZiUaN]

Comme le voyez, les deux premières phases de tokenisation de l’Apple Wallet sont complexes.
Mais ce n’est pas terminé ! Passons au parcours de paiement ou d’identification, l’utilisation d’une carte dans Apple Wallet.

Le début du parcours dépend bien sûr de l’usage. Dans un cas « physique » (paiement sur TPE en magasin, validateur dans un transport en commun, lecteur dans un cinéma…) on utilisera la communication NFC entre le smartphone et le lecteur. Cette communication respecte des protocoles créés par EMVCo/Visa-Mastercard ; 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 1ère étape de l’utilisation d’une carte sur l’Apple Wallet est la preuve d’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 propre à votre iPhone et votre CB. Ainsi le marchand ne peut pas voir les données bancaires
  • ils sont envoyés au TPE 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
  • il est déchiffré en partie pour être validé par les banques

Pour plus de détail sur ce parcours : https://codeburst.io/how-does-apple-pay-actually-work-f52f7d9348b7

Paiement avec Appel Wallet [source : Prashant Ram — https://bit.ly/3eZiUaN]

A terme, peut-être que les solutions SE hardware comme celle d’Apple utiliseront une technologie blockchain pour certains usages comme les crypto-monnaies et les biens numériques…

Dans d’autres exemples comme les titres de transport, les cartes d’identité, les places de cinéma… le parcours est quasiment le même. Mais les acteurs changent : comme le service de création de token ou les différents réseaux de traitement qui sont gérés par un prestataire spécialisé commandé par le fournisseur de service (ex : le gérant des transports en commun) ou par le fournisseur lui-même.

Mais tout ne peut pas être fait sans respect des protocoles du Wallet 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.
C’est relativement simple si le service veut s’intégrer dans l’application Wallet. Mais dans le cas d’une application séparée, c’est délicat et source de conflit entre les constructeurs de smartphone et les fournisseurs de service ; comme avec Navigo…

©IDF Mobilités

Historiquement, les abonnements et tickets Navigo ont été portés en premier sur les smartphones Samsung. Le constructeur utilise le même type de solution qu’Apple (avec quelques petites différences « maison ») ; c’est-à-dire un Secure Element hardware propriétaire.

Récemment, nous avons vu l’arrivée de (certains) titres et abonnements des transports parisiens sur les autres smartphones Android. Pas de surprise, la solution employée est la HCE.

Comme nous l’avons vu plus haut, les différents systèmes proposés par les constructeurs nécessitent des partenariats et l’assimilation de leurs solutions.

Sauf que dans le cas de Navigo il faut ajouter une complexité supplémentaire. Toutes les solutions décrites et leurs parcours systémiques sont valables dans le cas où une carte est intégrée directement dans l’application Wallet native du smartphone.
Si pour ce fonctionnement je ne doute pas que des prestataires de token, des réseaux universels et interopérables soient créés à moyen terme pour tous les cas d’usages (ex : paiement, transport, loisir, abonnement, identité…) , il est par contre compliqué de s’en passer et de vouloir faire sa propre application de son côté.

Pour HCE, comme la solution est majoritairement lié au cloud, les ponts entre une application « maison » du service et le SE (Secure Element) sont plus faciles. A vrai dire, HCE a été créé en partie pour ça.

Pour un SE hardware à la sauce Apple ou Samsung, les ponts n’ont pas d’API (petites applications prête à l’emploi pour connecter deux systèmes/services numériques) toutes faites. Car chaque application à sa propre conception et son propre développement.
A chaque production d’une application maison, l’entreprise créatrice du service doit s’entendre et travailler avec Apple sur les résolutions à cette problématique.

C’est pour cette raison que voir son Pass Navigo sur iPhone va demander pas mal de temps.
Surtout qu’Apple et Samsung veulent garder au maximum la main sur la sécurité via un contrôle et une gestion complète (fermé) du système.

D’un point de vue pragmatique, c’est tout à leur honneur. Seulement certains d’entre vous ne partagent pas la même approche.

Quant à moi, je sers toujours les mêmes objectifs : la sécurité et l’expérience utilisateur.

Pour l’UX avoir tout dans la même application, avec le même fonctionnement d’une carte à une autre, la même ergonomie, un parcours fluide… est un argument majeur (en plus de celui de la sécurité) à l’utilisation du système fermé. Surtout quand on voit comment l’UX est mal intégré et mal pris en compte dans un (trop) gros nombre de services. Je ne cache pas mon intérêt pour ce que l’on appelle les « super-apps » qui associent des services complémentaires.

Imaginez la fluidité du parcours si votre carte de transport en commun ou de VTC ou de vélo en libre-service était connectée à celle de votre abonnement de théâtre. L’une pouvant envoyer automatiquement les informations à l’autre lorsque la pièce se termine ; et ainsi réserver et rendre immédiatement accessible le moyen de transport…

Autre partie pris de ma part : je pense que vouloir créer sa propre application et sans utiliser celle du device est l’expression d’un égo très Européen, voire Français.

Si vous avez bien suivi cet article, l’excuse du risque d’avoir les données hébergées sur des serveurs étrangers plutôt que souverains ne marche pas.

1. Les données pour un SE hardware sont sauvegardées en locales

2. Elles sont représentées par un token ; un certificat chiffré que même Apple ne peut décrypter et est transféré sous cette même forme aux émetteurs de carte bancaire et aux banques

3. Quant aux réseaux utilisés pour les transferts, ils ne sont pas à la charge d’Apple mais du EMVCo, le réseau des cartes bancaires Visa, Mastercard…

J’estime donc que développer sa propre application est un risque non nécessaire pour les utilisateurs. C’est aussi un important engagement financier et une perte de temps conséquente.
Surtout que dans tous les cas, il faudra bien s’adapter aux systèmes des constructeurs.
Attention, je ne rejette pas entièrement les applications « maison » des entreprises; car elles servent aux spécificités de leurs services et leurs produits. Laissons le paiement et l’identification à des systèmes dont c’est la spécialité…

J’avoue je rêve d’une Super-app Wallet! Une application qui permettrait de gérer tous ses besoins d’identifications et d’activités liées.
Un service unique, avec une UX unique et fluide, où je pourrai retrouver mes moyens de paiement, mon historique, mon budget, ms factures… mais aussi mes supports de fidélité, mes tickets de spectacles, mes offres… mes moyens d’identification et d’authentification sur des sites ou des produits physiques… ma clé de voiture, ma clé de maison… où chaque service apporte une expérience à la suite d’autre service.
Mais bien sûr avec la meilleure des sécurités et la plus grande des transparences grâce à toutes les solutions que nous avons pu voir dans cet article; ou même des nouvelles comme la blockchain!

--

--

Consultant Digital Senior | Experience and Innovation Designer

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Julien Ducerf

Julien Ducerf

343 Followers

Consultant Digital Senior | Experience and Innovation Designer