Benoît Ferault (Quarkslab) : “Développer une application de paiement universelle et suffisamment sécurisée est une opération complexe”

La chaîne de valeur du paiement est régie par des obligations de sécurité définies par le conseil des standards de sécurité PCI (Payment Card Industry). Quelles sont les principales normes que doit suivre l’industrie ? 

Le conseil des normes de sécurité PCI a été créé pour standardiser les exigences de sécurité des schémas de paiement. Ce forum international est notamment à l’origine de PCI DSS (Data Security Standard), une norme qui porte principalement sur les systèmes informatiques et sur quelques questions organisationnelles, pour faire en sorte que le marchand ne soit pas le maillon faible de la chaîne. Mais le conseil a formalisé d’autres types d’obligations, comme les Payment Application DSS (PA-DSS), un standard qui s’applique aux développeurs d’applications et de logiciels de paiement. En recourant à des fournisseurs tiers certifiés PA-DSS, les marchands et institutions financières qui utilisent leurs applications de paiement restent conformes à la norme PCI DSS. 

Qu’apporte la norme PCI CPOC, initialement publiée en décembre 2019 ? 

Elle s’adapte à une évolution du marché. L’industrie a poussé vers un usage croissant des cartes en sans contact [dont le plafond a été relevé à 50 euros en mai 2020, et le succès persiste depuis la fin du confinement, ndlr] et identifie une nouvelle opportunité de croissance dans la possibilité d’accepter des paiements sur mobile. En termes de sécurité, c’est un paradigme entièrement neuf, car initialement, nos smartphones n’ont pas été construits pour accepter le paiement. Plus on multiplie les fonctionnalités sur ce type d’outil, plus les canaux potentiels d’attaque sont nombreux. Or habituellement, dans l’industrie du paiement, on laisse très peu de liberté à l’utilisateur final. Toute l’infrastructure est contrôlée et il est très difficile d’accéder aux éléments qui composent cartes et terminaux de paiement pour les analyser puis ensuite tenter de les compromettre. Une application, en revanche, est plus ouverte. Cela signifie que des attaquants peuvent tout à fait prendre le temps de l’étudier pour trouver comment en détourner l’usage. 

La norme PCI DSS ne pouvait-elle pas répondre à cette problématique ? 

Non, il fallait en créer une spécifique. La première tentative a été PCI SPOC, qui demandait au commerçant d’avoir un périphérique supplémentaire, sécurisé, à brancher à la prise jack du téléphone. C’est ce que propose Square, par exemple. Ç’a été la première norme, mais cela ne correspond pas totalement à l’usage du smartphone : ce que l’industrie veut obtenir, c’est la possibilité d’effectuer et de recevoir des paiements directement sur le téléphone, sans outil supplémentaire. PCI CPOC vient résoudre cette problématique et remplir les manquements de PA-DSS en ajoutant des exigences à destination des développeurs – des acteurs comme Mobeewave, qui vient de se faire racheter par Apple. 

Qu’imposent ces nouvelles obligations ? 

Dans une solution de paiement PCI CPOC, il y a quatre éléments à prendre en compte : le smartphone, l’interface NFC, l’application et les serveurs. L’application doit lire la carte, chiffrer les données, puis les envoyer aux serveurs. Ceux-ci doivent ensuite attester de l’intégrité de l’application et de la carte : ils jouent un rôle de certification avant et pendant la transaction, ce qui les oblige à être connectés en permanence. Bref, la liste d’exigences à remplir est très complexe – on parle d’un descriptif de 162 pages, avec des précisions techniques là où PCI DSS fournissait surtout des best practices. En outre, le morcellement du marché Android complique le développement d’applications sécurisées et universelles. Donc pour le moment, seulement deux sociétés sont certifiées [Digit Secure Singapore et Mypinpad Limited, ndlr]. 

Quel rôle joue Quarkslab pour aider les développeurs d’application de paiement à se faire certifier ? 

Dans le scénario envisagé de paiements via smartphone, il suffit au commerçant de télécharger une application pour accepter les transactions. Il y a donc besoin de protéger le code de cette application, pour qu’elle ne soit ni altérée, ni usurpée, et protéger les échanges de données. Beaucoup de start-up ont commencé à offrir des solutions de paiement de ce type, sans être au fait des techniques de développement d’applications sécurisées. Elles viennent donc nous solliciter pour notre expertise en sécurité cryptographique. 

Spécialisée dans la protection du code et des données, ainsi que dans l’usage de clés de chiffrement, notre solution Epona répond bien au cas d’usage du paiement mobile. Entre autres techniques, la solution utilise par exemple l’obfuscation du code source : elle l’altère de telle manière que tout attaquant qui souhaite observer le fonctionnement d’une application de paiement aura toutes les peines du monde à le reconstituer. 

Quelles sont les limitations de PCI CPOC ? 

Dans l’état actuel du standard, les applications qui s’y conforment ne sont pas censées être reliées à des imprimantes, donc les reçus de paiement ne peuvent être que numériques. Par ailleurs, dans un souci de séparation des différentes données du consommateur (l’outil qu’il utilise, ce qui l’identifie, ce qu’il sait), elle ne permet pas d’accepter un code PIN. Cela signifie qu’en Europe, la plupart des paiements sont limités à 50 euros. L’industrie du paiement a rapidement dit que cela limitait les cas d’usage, donc le conseil travaille à une deuxième version de PCI CPOC, qui accepterait le PIN.