Idées reçues sur le fonctionnement d’Apple Pay
(birchtree.me)- Le mécanisme qui masque le vrai numéro de carte n’est pas propre à Apple Pay : c’est aussi le mode de paiement utilisé par les grands portefeuilles numériques comme Google Pay et Samsung Pay
- Le point clé est la séparation entre le FPAN, numéro de la carte physique, et le DPAN, numéro de paiement propre à l’appareil ; même avec la même carte, un iPhone et un iPad utilisent des DPAN différents
- Le DPAN peut rendre plus difficile le suivi entre plusieurs marchands, mais il reste inchangé pour les transactions ultérieures chez un même marchand et n’empêche donc pas le suivi de l’historique d’achat chez un marchand donné
- En cas de fuite des données de paiement, le DPAN est plus sûr que le FPAN, et il ne fonctionne que lorsqu’il est envoyé avec un lot cryptographique unique attaché à chaque transaction
- Apple Pay ne masque pas automatiquement les données personnelles comme le nom, l’e-mail, l’adresse de facturation ou de livraison, ni les produits achetés ; il faut partir du principe que les informations affichées sur l’écran de paiement sont transmises au marchand
Le DPAN n’est pas une fonctionnalité exclusive à Apple Pay
- Quand on dit qu’Apple Pay masque le vrai numéro de carte bancaire, le point essentiel est le DPAN
- Le FPAN est le funding primary account number de 15 à 18 chiffres imprimé sur la carte physique, et le DPAN est le device primary account number
- On peut comprendre le DPAN comme un équivalent d’un enregistrement DNS
- L’utilisateur peut accéder à un site web avec un nom de domaine sans connaître l’adresse IP réelle
- Avec la même carte, si l’on utilise Apple Pay sur un iPhone et un iPad, chaque appareil reçoit son propre numéro et utilise donc un DPAN différent
- Il est important de noter que le nom lui-même n’est pas « Apple Pay number »
- Google Pay et Samsung Pay, eux aussi grands portefeuilles numériques aux États-Unis, masquent de la même manière le vrai numéro de carte
- Les boutons Amazon Pay et Shop Pay ne sont pas techniquement des DPAN puisque le paiement est traité par une autre entreprise, mais ils empêchent eux aussi le marchand de voir le vrai FPAN
Les marchands et les banques cherchent eux aussi à réduire l’exposition du vrai numéro de carte
- Lorsqu’un marchand traite directement le vrai numéro de carte bancaire, sa prise de risque augmente fortement
- Les outils modernes d’acceptation des paiements sont conçus pour collecter les données de paiement en limitant au maximum le nombre de personnes ayant accès aux vraies informations de carte
- L’idée que les banques n’utiliseraient pas de DPAN ne correspond pas à la réalité
- Plusieurs banques comme Wells Fargo, Chase et Bank of America exploitent ou ont exploité leurs propres portefeuilles numériques, tous utilisant des DPAN pour protéger le numéro de compte ordinaire
- Paze, utilisé par les grandes banques américaines, emploie lui aussi des DPAN
- L’un des principaux arguments mis en avant par Paze est : « Paze does not share your actual card number with the merchant. »
Ce que le DPAN empêche de suivre, et ce qu’il n’empêche pas
- Dire que le DPAN change à chaque transaction n’est pas exact
- Pour des transactions successives chez un même marchand, le même DPAN est utilisé
- Cette architecture peut constituer un obstacle pour les courtiers en données qui achètent des données de transaction de plusieurs marchands afin de reconstituer les habitudes d’achat d’une personne
- En revanche, un marchand unique peut toujours consulter l’historique des transactions d’un client à partir du seul DPAN fourni par Apple Pay
- Apple Pay n’empêche pas des situations comme le cas de Target, qui avait déduit l’état d’une cliente à partir de son historique d’achats
- Les autres portefeuilles numériques ont la même limite
La protection apportée par le DPAN en cas de fuite de données
- En cas de fuite d’informations de carte de paiement, le DPAN est plus sûr que le FPAN
- En 2024, un marchand ne devrait pas manipuler directement des numéros de carte bancaire, mais un piratage d’une passerelle de paiement entraînant la fuite du DPAN et de la date d’expiration reste possible
- Un attaquant ne peut pas effectuer un paiement avec le seul DPAN divulgué
- Le DPAN ne fonctionne que lorsqu’il est soumis comme partie d’un lot cryptographique unique pour chaque transaction
- Il existe des moyens d’exécuter des paiements récurrents sur une carte collectée via Apple Pay, mais un pirate ne devrait pas pouvoir le faire
- C’est pourquoi une fuite de FPAN est bien plus dangereuse qu’une fuite de DPAN, que tous les portefeuilles numériques collectent
Apple Pay ne masque pas automatiquement les données personnelles
- L’idée selon laquelle Apple Pay masquerait automatiquement les données personnelles est inexacte
- Si l’on exécute une vraie transaction Apple Pay sur un compte marchand de test, les rapports au niveau du marchand affichent des informations comme le nom, l’e-mail, l’adresse de facturation et l’adresse du domicile
- Pour le paiement de biens physiques, les informations de livraison sont nécessaires ; le SDK Apple Pay permet donc au marchand de choisir quelles données personnelles demander au client
- Les informations produit sont également transmises à Apple Pay pour montrer ce que l’acheteur achète, et ces informations sont elles aussi transmises au marchand
- Il faut considérer que les informations affichées sur la carte Apple Pay au moment du paiement sont transmises au marchand
- Sur ce point, Apple Pay fonctionne comme les autres moyens de paiement
- Le marchand choisit de demander les données personnelles nécessaires ou souhaitées au moment du checkout
- Les autres portefeuilles numériques fonctionnent de la même façon
La protection réellement apportée par les portefeuilles numériques
- Apple Pay est un bon moyen de paiement, et Apple a contribué à populariser cette forme de portefeuille numérique
- Mais les fonctionnalités d’Apple Pay ne sont pas uniques dans l’industrie
- Le DPAN est utile pour rendre plus difficile le suivi des achats d’une même personne à travers plusieurs marchands et pour réduire le risque côté client en cas de fuite des données de carte de paiement
1 commentaires
Avis de Hacker News
J’aimerais comprendre en mode ELI5 comment Apple Pay et Google Pay fonctionnent réellement. Avant, je pensais qu’ils transmettaient simplement les informations de carte au commerçant ou au prestataire de paiement, et l’article original semble dire quelque chose de similaire, mais j’ai aussi vu que, quand j’utilise Amex avec Google Pay, certains commerçants refusent le paiement, contrairement à MasterCard.
Parfois, j’ai l’impression qu’Apple/Google agissent comme un prestataire de paiement, voire comme un moyen de paiement à part entière. Parce qu’ils collectent des données de transaction, et que les terminaux en magasin semblaient nécessiter une prise en charge spéciale pour les apps Apple/Google Pay.
Dans ce cas, quelle est la recette propriétaire propre à Apple/Google, et pourquoi est-il difficile, voire impossible, de la remplacer par une alternative open source ? Est-ce parce qu’Apple/Google sont les seuls à avoir un accès complet à la puce NFC sur iOS/Android ?
https://news.ycombinator.com/item?id=39845805
Ce qui compte, c’est le choix par défaut. On ne peut avoir qu’un seul wallet Visa ou Mastercard par défaut par appareil, et celui qui n’exige pas d’ouvrir une app avant de payer a l’avantage. Google Pay prend en charge les cartes de plusieurs banques, ce qui lui donne un gros avantage par rapport au wallet HCE d’une banque émettrice donnée.
Apple/Google interviennent comme intermédiaires lors de l’enregistrement d’une nouvelle carte sur un appareil donné, mais ils ne font pas partie du flux réel de transaction au POS.
Le commerçant doit toujours accepter le réseau de carte sous-jacent. Les versions modernes de Google Pay et Apple Pay ne sont pas des cartes proxy qui changent le réseau de carte, et sont différentes de services comme Curve.
Les terminaux hors ligne n’ont pas besoin de prise en charge particulière. Tant que le terminal n’a pas de bug, cela fonctionne partout où le système de carte sous-jacent est accepté. Les protocoles physiques et logiques sont les mêmes que pour une carte plastique et, du point de vue du terminal, la différence est presque imperceptible.
Sur le Web, c’est différent. Le site e-commerce et le prestataire de services de paiement doivent les prendre en charge explicitement.
C’est pourquoi les terminaux sans contact acceptaient généralement Apple Pay et Google Pay tels quels, sans nécessiter beaucoup de prise en charge spécifique. L’un des changements, si je me souviens bien, est que ces appareils étant considérés comme plus sûrs, les plafonds de paiement ont été relevés par rapport aux cartes sans contact.
La raison pour laquelle une implémentation open source est difficile, c’est que l’implémentation d’EMV est complexe et nécessite beaucoup de tests et de validations avec du matériel spécialisé. L’appareil doit disposer d’une zone sécurisée pour conserver les clés privées en sécurité, et l’app doit pouvoir garantir la sécurité de l’utilisateur en vérifiant qu’une authentification biométrique ou un déverrouillage par PIN a été utilisé.
De plus, pendant la configuration, il faut s’intégrer au backend de la banque émettrice de la carte afin d’obtenir les clés et informations nécessaires. Une implémentation open source devrait très probablement conclure des accords avec les banques et passer par une validation en laboratoire auprès d’organismes comme UL.
Apple Pay, Google Pay et les apps de paiement fournies par les banques confirment l’autorisation du titulaire de la carte via l’authentification biométrique, ce qui transforme certains paiements en transactions “cardholder present”.
Ainsi, certains types de chargebacks sont rejetés immédiatement, et pour d’autres, le niveau de justificatifs demandé au commerçant est réduit.
Cela fait partie des standards des réseaux de cartes, et si cela vous intéresse, vous pouvez consulter https://www.emvco.com/.
S’il n’existe pas d’option open source, c’est parce qu’il faut certifier la sécurité de l’implémentation, ce qui nécessite une entité commerciale capable de travailler avec les banques. En plus, il faut s’intégrer séparément à chaque banque, ce qui fait beaucoup trop d’interlocuteurs.
Faire fonctionner correctement une transaction de bout en bout couvrant tous les réseaux de cartes, tous les modes de paiement et tous les appareils est assez délicat. Chaque réseau de cartes a des paramètres de “payment kernel” et des exigences de certification différents.
Ou bien il peut s’agir d’une tentative d’économiser sur les frais de transaction. Amex est généralement beaucoup plus chère pour les commerçants.
https://blog.bytebytego.com/p/ep25-how-applegoogle-pay-handl...
Quand Apple Pay a commencé à être largement utilisé, je l’avais examiné assez en détail, fort de mon expérience du traitement des paiements en magasin. Ce qui m’avait le plus frappé à l’époque, c’était à quel point il était profondément ancré dans des standards du secteur
Rien, après la communication sans fil, n’était propre à Apple, et à lire cet article, il semble que ce soit toujours le cas aujourd’hui
Je me souviens que certains commerçants qui acceptaient volontairement le tap-to-pay par carte ont dû modifier leurs systèmes lorsqu’ils se sont mis à accepter, sans l’avoir voulu, le tap-to-pay d’Apple, pourtant très standard. CVS me vient particulièrement à l’esprit : ils participaient à un système de paiement concurrent et semblaient vouloir s’en servir comme élément de différenciation avec Apple Pay, en mettant en avant le fait que ce système fonctionnait en magasin
Quand le mythe selon lequel « ça ne marche qu’avec Apple Pay » a commencé à émerger récemment, je me suis demandé si quelque chose avait changé depuis la dernière fois que j’avais regardé le sujet ; je suis donc content que l’auteur ait fait une mise à jour dans ce contexte
Même sans support officiel, j’ai été assez surpris de voir qu’Apple Pay fonctionnait partout en Australie. Aux États-Unis, seuls une poignée de commerçants le prenaient en charge, mais en Australie, comme tout reposait sur des standards, 99 % des terminaux de paiement le supportaient déjà
L’état chaotique des paiements Android y a aussi contribué. Samsung Pay pouvait désigner aussi bien le NFC que l’émulation de piste magnétique. Google est notoirement mauvais en branding, et entre les différentes itérations de Wallet et Google Pay, il est encore difficile de savoir qui est quoi
Ce qui manque dans ce genre de discussion, c’est que les transactions effectuées avec des wallets comme Apple Pay, Google Pay ou Samsung Pay sont désormais aussi traçables que celles effectuées avec le numéro de carte sous-jacent
Le DPAN est propre à un appareil donné, mais aujourd’hui le prestataire de services de paiement d’un commerçant peut recevoir, dans la réponse d’autorisation du réseau de cartes, un identifiant unique appelé PAR. Cet identifiant est le même pour tous les DPAN d’une même carte et vise à rester le même pour un compte de base donné, même si le numéro de carte change
Le PAR ne permet pas à un commerçant de débiter un paiement, donc ce n’est pas un problème de sécurité, mais il ne faut pas s’attendre à ce qu’un paiement par wallet numérique soit plus privé qu’un paiement par carte classique ou par numéro de carte
https://wcapra.com/payment-account-reference-capraplus-your-...
https://www.securetechalliance.org/wp-content/uploads/EMVCo-...
L’article de Matt Birchler a ajouté un paragraphe disant : « Dans une version précédente, j’ai écrit que le DPAN changeait selon le commerçant, mais c’était une erreur. J’ai écrit trop vite, c’est ma faute. » Pourtant, le reste de l’article semble toujours supposer l’existence d’un DPAN unique par commerçant, et je ne trouve rien qui l’étaye
La propre documentation d’Apple https://support.apple.com/en-us/HT203027 indique elle aussi que le DPAN, appelé ici Device Account Number, n’est unique que par appareil. Lorsqu’une carte est ajoutée à Apple Pay, le DPAN de cet appareil est généré et ne change plus ensuite, sauf si l’on supprime la carte puis qu’on l’ajoute à nouveau
Donc, si l’on utilise la même carte sur un iPhone et une Apple Watch, les DPAN sont différents et le suivi devient plus difficile ; mais si l’on utilise la même carte sur le même appareil chez plusieurs commerçants, je pense qu’un data broker peut suivre ces transactions
Je ne comprends pas pourquoi le SSO et le paiement mobile ne sont pas des interfaces standard pour lesquelles n’importe qui pourrait créer un fournisseur. Au lieu de « Login with Google » ou « Login with Apple », ne devrait-on pas avoir « Se connecter avec mon fournisseur SSO par défaut » ? Même chose pour « Payer avec mon fournisseur de paiement par défaut »
Pire encore, les fournisseurs ou les sites ne prennent souvent en charge qu’une partie de ces fournisseurs, ce qui fait que le SSO n’est en réalité plus vraiment du SSO
Il y a sans doute des raisons, mais je n’ai pas creusé. Il me semble qu’il devrait exister une spécification commune et convenue que tous les fournisseurs suivraient ; et si ce n’est pas le cas, il est probable qu’un jour la loi l’impose
Les standards existent déjà, et en théorie, si l’on saisit son e-mail dans un formulaire de connexion, ou si le navigateur le remplit automatiquement, cela pourrait mener à la connexion OAuth du domaine concerné ; et si le serveur communique avec ce domaine pour la première fois, il pourrait même effectuer l’enregistrement du client à la volée. Je n’ai jamais vu cela utilisé en pratique, mais ce serait bien
[0] https://datatracker.ietf.org/doc/html/rfc7591
[1] https://datatracker.ietf.org/doc/html/rfc8414
On est passé de la fourniture d’un service contre une rémunération équitable à l’envoi de spam aux utilisateurs, ou à la collecte de leurs données pour leur envoyer encore plus de spam plus tard
Les standards ouverts ne sont pas ce que veulent les fournisseurs en place. Cela permettrait aux utilisateurs de passer facilement à d’autres solutions et de ne plus « s’engager »
Fait intéressant, Apple Pay a été lancé en Australie après que les grandes banques locales ont passé des années à pousser l’adoption du paiement sans contact. Ainsi, quand Apple est arrivé en réclamant des commissions à l’américaine, l’infrastructure avait déjà été déployée par les banques elles-mêmes
Les grandes banques australiennes ont résisté pendant des années à la prise en charge d’Apple Pay, mais la pression des clients est devenue trop forte et elles ont fini par céder
Aujourd’hui encore, tout le monde est très mécontent de cette situation, et si le régulateur obligeait Apple à ouvrir la puce NFC, elles abandonneraient immédiatement Apple Pay. Mais jusqu’ici, il a été difficile de trouver quelqu’un prêt à compatir aux plaintes des plus grandes banques du pays
https://www.accc.gov.au/media-release/accc-denies-authorisat...
Les banques canadiennes ont elles aussi essayé leurs propres paiements sans contact sur Android, comme TD Pay, mais personne n’en voulait. Elles ont fini par abandonner et proposer Google Pay
Je pense que cela se passera de manière similaire. Même si Apple ouvre les paiements NFC, personne n’utilisera les applis des banques et les gens préféreront les solutions prises en charge en première ligne, comme Apple Pay ou Google Pay
Il suffit de voir combien de personnes utilisent réellement Samsung Pay plutôt que Google Pay
Certains commerçants comme CVS ont désactivé le paiement par tap quand Apple Pay a été introduit
Je me demande si la partie disant que « le commerçant peut demander autant d’informations personnelles que nécessaire lors du checkout, et Apple Pay ne l’en empêche pas » s’applique aussi aux achats en magasin
Je n’ai pas besoin de donner mon nom et mon adresse pour acheter des œufs au supermarché. Apple/Google demandent-ils explicitement mon consentement lorsqu’ils partagent des informations qui ne sont clairement pas nécessaires ? Est-ce un choix du type accepter ou partir, comme des conditions d’utilisation ou une EULA sous blister ?
Je n’ai jamais utilisé ce genre de système de paiement
Les informations supplémentaires mentionnées dans l’article ne sont partagées que pour les paiements « en ligne ». Cela inclut toutefois les cas où l’on scanne un QR code avec son téléphone et où l’on paie dans Safari ou dans un App Clip, une méthode que j’ai vue dans quelques restaurants récemment
Dans ce cas, le restaurant reçoit autant d’informations qu’il en demande. Cela peut inclure le nom, l’adresse et même l’adresse e-mail. En général, cela semble être affiché dans la feuille de paiement, mais je ne l’avais pas vraiment remarqué la première fois que je l’ai utilisé dans un restaurant
Maintenant, je demande au serveur d’apporter un vrai terminal pour que je puisse faire un tap, ou je donne simplement une carte physique
C’est un peu hors sujet, mais je ne comprends toujours pas pourquoi Apple Pay ne peut pas afficher à l’écran le montant à payer avant d’autoriser la transaction
Ce n’est pas un problème d’expérience utilisateur : on dirait que l’appareil Apple ne connaît tout simplement pas ce montant. Pourquoi ?
Il m’a fallu un moment pour comprendre ça. Je ne comprenais pas comment Apple Pay pouvait fonctionner en mode avion, mais bien sûr que ça fonctionne : une carte Visa classique marche aussi très bien sans connexion Internet
Fondamentalement, c’est la même chose. C’est aussi pour ça qu’il n’y a rien de plus à « prendre en charge » si tout le monde respecte les standards. Voir le commentaire frère de jjcm : https://news.ycombinator.com/item?id=39846117
Donc je suppose que le lecteur NFC ne « diffuse » pas le montant du paiement. Les cartes en plastique n’avaient aucun moyen de traiter cette information, et l’iPhone n’a aucun moyen de la recevoir puis de dire « attends, laisse l’utilisateur valider par un swipe »
Je ne sais pas où Gruber aurait dit que « seul Apple Pay fait ça ». L’auteur semble relever quelques erreurs ou imprécisions de Gruber, et c’est apparemment tout
[Mise à jour : oups, je me suis trompé. Matt Birchler, qui travaille dans le secteur des paiements, a bien expliqué le fonctionnement, et il s’avère que les grandes banques et les émetteurs de cartes génèrent des numéros « DPAN » propres à chaque commerçant pour les transactions tap-to-pay. Je maintiens toutefois mon argument selon lequel Apple Wallet est au moins aussi sûr, sinon plus, que n’importe quelle application de paiement numérique fournie par un émetteur de carte.]
C’est le billet de Gruber, l’auteur original
Gruber a lui aussi reconnu son erreur
Gruber est ouvertement fan d’Apple, mais il était généralement rigoureux sur les faits, reconnaissait ce qu’il ne savait pas et renvoyait vers des experts du domaine
Mais depuis les mesures d’Apple liées au DMA de l’UE, il semble avoir complètement perdu son objectivité. Il fait comme s’il comprenait le texte juridique mieux que la Commission européenne, applique une approche américaine à une manière de légiférer européenne très différente, et reprend telles quelles les déclarations de mauvaise foi d’Apple
Ce changement coïncide avec l’attitude étrangement malveillante d’Apple envers l’UE, donc le problème de fond est peut-être que Gruber fait trop confiance à Apple
Il semble garder la même attitude face au procès antitrust du gouvernement américain
Pour être juste, les réseaux sociaux sont remplis de partisans d’Apple qui se prennent pour des juristes et se trompent sur presque tout, donc il lui est peut-être difficile de voir des points de vue opposés légitimes
À propos de « Apple a fait un excellent travail pour populariser ces portefeuilles numériques, mais ce qu’ils font n’a rien d’unique dans l’industrie », ma mémoire me joue peut-être des tours, mais je pense qu’Apple Pay était assez unique à son lancement. C’est pour ça qu’il était pris en charge par très peu d’endroits
Les autres systèmes de paiement mobile, par exemple les premiers Samsung Pay, envoyaient il me semble le numéro de carte tel quel au terminal
Fait intéressant, le Royaume-Uni semble encore avoir une limite de 100 £, alors qu’aux États-Unis j’ai déjà payé plus de 2 000 $ avec le sans contact sur un téléphone Android
Peut-être qu’il n’était envoyé qu’à la banque et que le commerçant ne le voyait pas, mais c’était quand même le vrai numéro. La première fois que j’ai entendu parler de l’usage d’un DPAN, c’était avec Apple
Aux États-Unis, la technologie de paiement par carte est très en retard pour diverses raisons. Quand je suis allé en Pologne avec une carte que j’utilisais depuis des années partout dans le monde, j’ai même dû apprendre une solution de contournement spéciale pour que le caissier puisse encaisser le paiement