Cette mission n’avait rien à voir avec PCI. Elle nous est venue grâce à PCI : l’expertise qui juge la sécurité des PIN et la cryptographie des paiements est celle qui lit un texte réglementaire sur l’authentification et dit ce qu’il signifie en pratique.
La situation
Une banque en ligne pour les petites entreprises a lancé une API entreprise : données de compte, gestion des IBAN, pièces jointes, webhooks et virements. Chaque requête portait un jeton signé avec la clé privée du client, liée à un certificat émis à l’enrôlement par l’autorité de la banque elle-même, plus un secret partagé et une empreinte de la requête. L’enrôlement lui-même exigeait la double authentification de l’application mobile de la banque.
La question de la banque, par écrit : est-ce une authentification forte du client au sens de la DSP2 ? Et sinon, est-ce au moins aussi sûr que les deux protocoles dédiés aux entreprises que le régulateur national reconnaît pour l’exemption qui permet aux utilisateurs professionnels de se passer de l’authentification forte ?
L’analyse
Les normes techniques de réglementation définissent l’authentification forte du client par ses facteurs, et nous les avons pris un par un.
- La connaissance était satisfaite. Le secret remis à l’enrôlement est quelque chose que le client sait.
- L’indépendance des facteurs était satisfaite. Compromettre l’un ne compromettait pas les autres.
- La possession ne l’était pas, et c’est tout le dossier. Un fichier de clé privée se copie librement. Une liste d’adresses IP autorisées ne lie pas la clé à une personne. Les normes mettent le devoir d’empêcher la copie à la charge de la banque, pas du client, et rien dans la conception ne l’empêchait.
- L’inhérence était absente par conception, ce qui est permis ; deux facteurs suffisent.
- Le lien dynamique, le code lié au montant et au bénéficiaire d’un paiement, n’était pas satisfait. Il n’y en avait pas.
Verdict : pas une authentification forte du client. Mais la conception était comparable, en sécurité, aux protocoles dédiés aux entreprises que le régulateur accepte, et donc alignée sur l’exemption pour les utilisateurs professionnels. L’avis a connu trois versions en quatre mois à mesure que l’analyse de la possession s’approfondissait, parce que la première lecture était trop généreuse et que nous l’avons dit.
Un jeton signé prouve que quelqu’un détient un fichier de clé. Il ne prouve pas que c’est la bonne personne.
Pourquoi cela comptait
« Comparable à un protocole exempté » et « authentification forte du client » sont deux phrases très différentes à prononcer devant un régulateur, un client ou un auditeur. La banque savait désormais laquelle elle pouvait dire, et ce qu’elle devrait changer pour dire l’autre : une clé que le client ne peut pas exporter, dans un jeton matériel ou un élément sécurisé, et un lien dynamique pour les paiements.
Elle savait aussi où se trouvait désormais son vrai contrôle. Si vous vous appuyez sur l’exemption entreprise, la sécurité de votre autorité de certification, de son processus d’enregistrement et de sa surveillance est le contrôle sur lequel tout le reste repose, et c’est cela qu’il faut tester.
Ce que l’on fait de travers
On prend une bonne cryptographie pour une authentification. Un jeton signé prouve que quelqu’un détient un fichier de clé. Il ne prouve pas que c’est la bonne personne.
On lit « possession » comme le fait de détenir un fichier. Les régulateurs le lisent comme quelque chose qui ne peut pas être dupliqué. Un fichier, par définition, le peut.
On pose la question réglementaire après le lancement. La conception était saine et le lancement fait ; la réponse ne pouvait plus changer le produit, seulement la phrase à son sujet.