L’authentification forte du client sous la DSP2 demande deux facteurs sur trois : quelque chose que le client sait, quelque chose qu’il a, quelque chose qu’il est. La connaissance et l’inhérence sont à peu près comprises. Le facteur qui nous revient pour avis écrit, encore et encore, est la possession, parce que les normes techniques de réglementation le définissent par une propriété que la plupart des implémentations n’ont pas. Ce que le client « a » doit être quelque chose qui ne peut pas être copié sans que la banque s’en aperçoive.
Cette seule phrase élimine plus de conceptions qu’on ne le croit.
Ce que demandent réellement les normes
Les normes techniques de réglementation sur l’authentification forte disent trois choses de la possession. Chaque facteur doit être indépendant, de sorte que la compromission de l’un n’entraîne pas celle d’un autre. L’élément de possession doit reposer sur des mesures qui empêchent sa réplication. Et pour un paiement, le code d’authentification doit être lié dynamiquement au montant et au bénéficiaire, pour qu’un code capturé pour un virement ne puisse pas en approuver un autre.
L’avis de l’Autorité bancaire européenne sur les éléments de l’authentification forte dit comment la possession peut être démontrée : un mot de passe à usage unique généré par un appareil, ou une signature numérique produite par une clé détenue sur l’appareil, entre autres. Un appareil démontre la possession quand la banque peut dire que cet appareil, et non une copie de ses données, a produit la réponse.
C’est là que se loge l’essentiel de la difficulté.
Ce qui n’est pas une possession
Un code SMS prouve que quelqu’un peut lire les messages envoyés à un numéro. Les normes acceptent la carte SIM comme élément de possession dans son principe, avec la réserve que la banque doit traiter l’échange de SIM et la portabilité du numéro. En pratique, c’est le choix acceptable le plus faible, et le plus souvent contourné.
Un fichier de clé protégé par mot de passe prouve que quelqu’un détient le fichier. Les fichiers se copient. Le devoir d’empêcher la réplication incombe à la banque, et rien dans un fichier ne l’empêche. Nous avons remis à une banque challenger un avis écrit exactement en ce sens : une cryptographie soignée, des requêtes signées, des certificats émis à l’enrôlement, et pourtant pas de possession, parce que la clé privée vivait dans un fichier. Cette histoire fait l’objet d’une étude de cas à part.
Un identifiant d’appareil n’est pas non plus une possession. Identifiants publicitaires, empreintes d’appareil, jetons d’installation : tous peuvent être lus et rejoués. Les fermes d’émulateurs le font à grande échelle, présentant des centaines d’« appareils » plausibles à un serveur d’authentification qui vérifie des identifiants plutôt que des clés.
Ce qui en est une
Une clé privée générée dans le matériel sécurisé de l’appareil, jamais exportée, utilisée pour signer un défi choisi par le serveur. Sur les appareils Apple, c’est la Secure Enclave. Sur Android, c’est le keystore adossé au matériel, avec StrongBox quand l’appareil en dispose. Les clés qui y sont créées ne peuvent être lues ni par l’application, ni par le système d’exploitation, ni par quelqu’un qui a copié l’image du téléphone. L’application demande au matériel de signer ; le matériel signe ; la clé n’apparaît jamais dans une mémoire que l’application peut voir.
Lier l’appareil, c’est donc ceci : à l’enrôlement, l’application génère une paire de clés dans le matériel sécurisé, la clé publique est enregistrée au nom du client, et dès lors chaque authentification est une signature sur un défi frais du serveur. Pour un paiement, le défi inclut le montant et le bénéficiaire, ce qui donne la liaison dynamique par le même mécanisme.
Deux détails décident si cela tient.
L’attestation. Le serveur doit pouvoir vérifier que la clé a bien été générée dans un matériel sécurisé, sur un vrai appareil, par votre application. Les deux plateformes le permettent : l’attestation de clés Android et Play Integrity, App Attest et DeviceCheck chez Apple. Sans attestation, un émulateur peut présenter une clé logicielle et prétendre qu’elle est protégée par le matériel. Avec, la prétention est une chaîne de certificats que vous pouvez vérifier.
Le cycle de vie. Un nouveau téléphone, c’est une nouvelle clé, et l’ancienne doit être révoquée. Le ré-enrôlement sur un nouvel appareil est lui-même une opération sensible et exige sa propre authentification forte, par un facteur que l’attaquant qui a volé un mot de passe n’a pas. Si le ré-enrôlement est possible avec un mot de passe et un code SMS, la clé matérielle ne protège rien : l’attaquant enrôle simplement son propre téléphone.
Le piège d’ingénierie
Les frameworks multiplateformes sont l’endroit où de bonnes conceptions échouent en silence. Le matériel sécurisé n’est accessible que par du code natif, et les enveloppes génériques de keychain ou de keystore livrées avec React Native, Flutter et leurs semblables ne placent pas toujours la clé là où vous le croyez. Une clé dans le keychain ordinaire reste un fichier que le système protège, ce qui vaut mieux que rien et n’est pas ce que décrivent les normes. Si votre application est multiplateforme, le module qui génère et utilise la clé doit être natif, doit demander explicitement un stockage adossé au matériel, et doit faire échouer l’enrôlement si l’appareil ne peut pas le fournir.
Testez-le. Enrôlez-vous sur un émulateur et sur un appareil rooté, et vérifiez que le serveur refuse. Extrayez le matériel de clé d’une sauvegarde d’appareil et vérifiez qu’il n’y est pas. La preuve que la possession est réelle est un test qui a essayé de la copier et n’a pas pu.
La possession, ce n’est pas posséder un appareil. C’est détenir une clé qui ne peut pas être copiée sans que la banque s’en aperçoive.
L’autre façon d’échouer : l’enrôlement
Une conception cryptographiquement juste peut quand même bloquer de vrais clients, et les régulateurs y tiennent aussi. Une que nous avons observée du côté du client : une application bancaire professionnelle qui enrôlait un nouveau téléphone en envoyant un SMS, sauf qu’elle ne pouvait pas envoyer vers des numéros étrangers ; puis proposait un courrier avec un code à l’adresse enregistrée, sauf que l’adresse au dossier avait des années de retard ; puis plantait pendant la tentative avec un numéro local emprunté. Quatre mois sans carte utilisable, pendant que la même banque authentifiait le même client au téléphone, de vive voix, plusieurs fois par semaine.
La leçon n’est pas que l’authentification de la banque était faible. La méthode dans l’application, une fois enrôlée, fonctionnait. La leçon est que l’enrôlement et la récupération font partie de la conception de l’authentification, et qu’ils ont été construits après coup. L’enrôlement a besoin de plus d’une voie, chacune aussi forte que la méthode qu’elle déverrouille, et aucune ne doit dépendre d’un seul réseau téléphonique national ou de données d’adresse que personne n’a vérifiées depuis l’ouverture du compte.
Ce que l’on fait de travers
On prend l’appareil pour le facteur. Le facteur, c’est la clé. Un appareil avec une clé copiable est un mot de passe avec des étapes en plus.
On saute l’attestation. Le serveur croit ce que l’application dit de la clé, et un émulateur dit la même chose.
On sécurise l’authentification et on laisse la récupération faible. L’attaquant n’attaque pas la signature. Il enrôle un nouveau téléphone.
On pose la question réglementaire après le lancement, quand la réponse ne peut plus changer que la phrase que l’on dit du produit, pas le produit.