L'ouverture du NFC sur les appareils iOS d'Apple représente un tournant majeur dans l'écosystème des paiements mobiles, en particulier pour les émetteurs de cartes et les fintechs qui désirent proposer des solutions alternatives à Apple Pay. Toutefois, cette opportunité comporte des défis techniques importants qu'il faut considérer, impliquant notamment des technologies comme le Secure Element (SE) et l'Host Card Emulation (HCE), ainsi que des contraintes liées aux certifications et aux accès API.
Comprendre les différences entre SE vs HCE
Dans les wallets sur mobile, deux architectures différentes sont possibles : l'utilisation du Secure Element (SE) et l'Host Card Emulation (HCE).
Le Secure Element (SE) est un composant matériel intégré dans les smartphones, conçu pour protéger les informations sensibles telles que les détails de carte et les clés cryptographiques. Les solutions basées sur le SE, comme Apple Pay, utilisent un environnement isolé du système d'exploitation et des autres applications du téléphone et résistant aux manipulations pour effectuer des transactions, garantissant un niveau de sécurité élevé. Cette technologie permet une isolation forte des données critiques.
Le Host Card Emulation (HCE) est une solution logicielle qui permet de virtualiser les fonctionnalités d'une carte de paiement sans avoir besoin de Secure Element dédié embarqué dans le smartphone. Dans une architecture HCE, les données de paiement sont gérées via des solutions cloud, et la sécurité repose principalement sur des clés temporaires (session keys) et des mécanismes de tokenisation. La tokenisation est un processus de remplacement des données sensibles, comme le numéro de carte bancaire, par un identifiant unique (token) qui ne peut être utilisé que dans un contexte spécifique. Dans le cadre du HCE, ce mécanisme permet de limiter les risques liés à la compromission des données en s'assurant que les informations stockées et transmises ne sont pas exploitables en dehors de l'environnement prévu. Les clés de session sont générées dynamiquement pour chaque transaction et renouvelées régulièrement afin de minimiser le risque de compromission. En outre, des systèmes de détection d'intrusion sont souvent utilisés pour surveiller l'intégrité des sessions HCE, garantissant une sécurité renforcée contre les attaques potentielles. Google Pay est un exemple de cette approche, qui est plus flexible mais présente potentiellement des risques plus élevés que les solutions basées sur le SE.
L’approche HCE (Host Card Emulation) est considérée comme plus flexible que les solutions basées sur le SE (Secure Element) pour plusieurs raisons :
- Déploiement facilité : Contrairement aux solutions basées sur un SE physique (comme une carte SIM ou une puce sécurisée intégrée au téléphone), le HCE ne nécessite pas de coopération avec les fabricants de matériel, les opérateurs mobiles ou les banques pour intégrer une solution de paiement. Cela permet une adoption plus rapide et une plus grande facilité de mise en œuvre.
- Compatibilité étendue : Les solutions HCE fonctionnent sur une large gamme d’appareils, indépendamment de la présence d’un SE spécifique, alors que les solutions basées sur le SE nécessitent un matériel compatible et peuvent être restreintes à certains fabricants ou opérateurs.
- Mises à jour logicielles simplifiées : Comme les données et les mécanismes de sécurité sont principalement gérés dans le cloud, il est plus facile de déployer des mises à jour de sécurité et des évolutions fonctionnelles sans dépendre de modifications matérielles ou de nouvelles cartes SIM.
- Approche basée sur le cloud : L’utilisation d’un stockage cloud pour les données de paiement et l’authentification permet une gestion centralisée et dynamique, alors que le SE repose sur un stockage local plus rigide.
Cependant, cette flexibilité a un coût en matière de sécurité : contrairement au SE, qui est un composant matériel inviolable, le HCE repose sur un environnement logiciel, potentiellement plus vulnérable aux attaques (malwares, interception de données, etc.). C’est pourquoi des mécanismes comme la tokenisation et l’utilisation de clés temporaires sont mis en place pour renforcer la sécurité.
En Europe, Apple a ouvert son NFC, mais de manière limitée à HCE, excluant le Secure Element pour les applications tierces et réservant cet accès uniquement à son service ApplePay. La sécurité est alors gérée via le Secure Enclave offrant une zone sécurisée pour le HCE, en dehors du Secure Element. Cela a un impact non négligeable sur la sécurité des solutions de paiement alternatives et peut limiter leur usage, notamment en excluant des cas comme les transactions offline, qui nécessitent la présence d'un SE pour conserver les informations qui ne peuvent être transmises aux serveurs cloud. En revanche, HCE offre des perspectives intéressantes en termes de flexibilité, d’intégration rapide et de déploiement plus étendu.
Opportunités et défis techniques pour les banques et fintechs
L'ouverture du NFC sur iOS permet à des acteurs tels que les banques, les fintechs et les prestataires de services de paiement tiers (TPP) de développer leurs propres solutions de wallets mobiles pour des paiements de proximité.
Cela ouvre également la voie à des utilisations du NFC par des solutions unifiées souveraines comme le wallet Wero de l'EPI pour les paiements instantanés (IP), l'Euro Numérique, voir des services liés à l'identité digitale et au futur wallet Européen.
Cependant, mettre en place un wallet alternatif aux principaux services xPay tels qu'Apple Pay, Google Pay, et Samsung Pay implique aussi de se conformer à plusieurs exigences de certification et de conformité à respecter dans les applications HCE pour minimiser les risques de fraudes.
Pour une application basée sur HCE, les points suivants doivent être pris en compte :
- Protection des données sensibles : Contrairement à une solution basée sur un SE, où les informations sont stokées de manière sécurisée dans un éléments matériel dédiée, une solution HCE repose sur des mécanismes logiciels et des clés de session renouvelables, partagées entre l’application clients sur l’appareil et le serveur dans le cloud. Par exemple, les données de paiement sont chiffrées en transit et en repos à l'aide de l'algorithme AES-256, et des protocoles de communication sécurisés tels que TLS 1.3 sont utilisés. Des mesures d'authentification dynamique sont appliquées pour chaque transaction, garantissant un haut niveau de sécurité. Cela inclut le chiffrage de bout en bout des données de transaction, l'authentification forte de l'utilisateur, et la gestion stricte des permissions des applications.
- Conformité et certification : Chaque application de paiement doit être certifiée, en passant des évaluations de sécurité telles que celles prévues par EMVCo et PCI, ainsi que les processus de certification imposés par les schémas de paiement comme Visa et Mastercard. Ces validations sont réalisées par des laboratoires indépendants dûment habilités. Ce sont des aspects que les banques doivent considérer pour lancer leur propre solution. À cela s’ajoutent les exigences de validation d’Apple pour la mise en ligne de cette application sur l’App Store, qui doit se conformer aux directives strictes d’Apple en matière de sécurité, de protection des données personnelles et d’expérience utilisateur. Le processus de validation inclut notamment une évaluation approfondie des mécanismes de gestion des données sensibles, des protocoles d’authentification et du respect des règles de confidentialité imposées par l’App Store.
- Gestion du Secure Element : L'accès au Secure Element est actuellement exclu par Apple pour le marché Europe, ce qui signifie que certaines fonctionnalités de sécurité additionnelles ne sont pas disponibles pour les acteurs tiers. Cela constitue une limitation majeure pour les applications qui nécessitent des transactions offline ou une isolation renforcée des données. A noter qu’Apple a ouvert l’accès au SE pour certains pays, comme les Etats-Unis, l’Angleterre, l’Australie.
- Architecture de Tokenisation : La gestion des jetons (tokenisation) est fondamentale pour minimiser le risque d'exposition des données sensibles. Les tokens sont générés, stockés et sécurisés dans des environnements dédiés qui empêchent tout accès non autorisé. Dans une architecture HCE, les tokens sont souvent stockés dans le cloud, sécurisés par des mécanismes de chiffrement avancés et accessibles via des protocoles sécurisés, tandis que dans une architecture basée sur SE, les tokens sont stockés de manière isolée dans le hardware du dispositif, garantissant ainsi un niveau de sécurité supérieur. Une intégration efficace avec un TSP (Token Service Provider) permet de réduire les vecteurs de fraude potentiels.
Opportunités et stratégies d'avenir
L'ouverture de l'accès au NFC sur iOS est une évolution attendue depuis longtemps, offrant enfin aux banques et fintechs la possibilité de proposer de nouveaux services clients indépendants et unifiés, apportant ainsi plus de diversité et d'innovation.
Bien sûr, cette gestion HCE est déjà bien connue dans le monde Android, qui l’utilise depuis plusieurs années. Mais sur iOS, la seule possibilité de faire du paiement était via ApplePay exclusivement. Cela obligeait à trouver des solutions d’interaction alternatives, comme les QRCode par exemple, lorsque la société voulait passer en dehors d’ApplePay, et éviter ainsi les fees imposés par Apple.
Pour des fournisseurs de solutions, le fait d’avoir maintenant l’accès à l’utilisation du NFC d’Apple leur permet de créer des parcours clients unifiés entre Android et iOS. Cela offre aussi la possibilité de mettre en place des interactions pour de nouveaux services sur iOS, comme l’eID (Identité Digitale), l’Euro Numerique, …
Cependant, la prise en compte des exigences techniques et de conformité associées à l'utilisation de HCE rendent nécessaire une planification minutieuse, tant concernant l'intégration dans l'environnement des SI bancaires, que la prise en compte de l'expérience client, en particulier avec l'application de la banque.
En particulier, ce n’est pas parce que les banques alimentent déjà les xPay (ApplePay, GooglePay, SamsungPay, …) avec les tokens des cartes des clients que pour autant elles sont immédiatement en mesure de gérer une application de paiement dédiée. Tous ces xPay ont été développés et sont certifiées conformément aux exigences EMV et des réseaux de carte. Elles ont passé les tests et validations par les laboratoires accrédités. Pour les banques, développer leur propre application de paiement signifie reprendre à leur charge ces travaux et responsabilités.
Un autre sujet pour les banques concerne l’intégration ou non de cette fonctionnalité de paiement avec l’application bancaire de la banque. C’est un choix très structurant, tant vis-à-vis de l’expérience utilisateur et des services additionnels, que pour les évolutions et les maintenances de la solution. Pour certaines banques, il est préférable d’avoir une application indépendante, pour d’autre, le choix est de l’intégrer dans l’application bancaire. Il y a des avantages et des inconvénients dans les deux cas, mais il faut bien les mesurer pour définir la bonne stratégie à prendre pour la banque.
Pour tirer pleinement parti de cette ouverture, les émetteurs doivent envisager de s'allier à des partenaires expérimentés, tels que des entreprises spécialisées en sécurité mobile et en tokenisation.
En particulier, l'accompagnement par des consultants experts possédant une excellente connaissance des enjeux technologiques, métiers et de conformité, combinée à une compréhension approfondie des différences entre HCE et SE, est essentiel pour élaborer des solutions de paiement, voire d’identité numérique, innovantes et qui répondent aux attentes de sécurité et d’expérience utilisateur. Les principaux sujets à considérer :
- Détails et formations sur les xPAY (SE, HCE, …)
- Formation tokenisation
- Audit et analyse de l’infrastructure technique IT spécifique pour la banque,
- Identification des écarts potentiels et recommandations,
- Analyse des opportunités et contraintes selon le type d’implémentation et d’intégration avec l’application et les services de la banque,
- Support à la recherche de partenaires potentiels (RFI-RFP)
- Analyse et définition des parcours clients adaptés pour la banque (provisionning, révocation, double-tap et FaceId, application par défaut sur iOS, …)
- Analyse des opportunités et arguments marketing client, pour une différenciation par rapport à ApplePay
- Analyse du Business Model et du retour sur investissement, en comparaison des fees d’ApplePay
- Accompagnement plan projet (POC, projet d’implémentation, déploiement, …)
Les opportunités sont immenses, mais il est crucial d'être bien accompagné et de s'assurer que les défis techniques, les certifications et les exigences de sécurité sont pleinement compris et anticipés. Agir maintenant permettra aux émetteurs de se positionner comme des leaders sur un marché des paiements de plus en plus concurrentiel.
Les experts de l’association EESTEL se tiennent à la disposition des acteurs du marché pour répondre à leur question et pour les accompagner dans leurs projets.