Janvier 2013
Le terme « paiement mobile » décrit de manière abstraite le processus de transfert d’argent d’un payeur vers un bénéficiaire à l’aide d’un téléphone mobile. Avant d’entrer dans les détails des éléments qui peuvent constituer une stratégie de sécurité pour un tel système, il faut d’abord distinguer deux concepts de sécurité fondamentalement différents, que j’appellerai on-the-device et in-the-cloud.
La sécurité sur la puce contre la sécurité dans le cloud
Les deux approches se distinguent essentiellement par la manière et l’endroit où les informations sensibles relatives au donneur d’ordre du paiement sont stockées. Les instruments de paiement classiques, comme les cartes, ont été inventés longtemps avant l’apparition des téléphones mobiles ou encore des smartphones et se basent sur un élément intégré dans la carte, sous forme de bande magnétique ou de puce, garantissant l’authenticité et l’intégrité de l’opération de paiement. Une évolution naturelle et logique serait de transposer ce même mécanisme, qui a déjà fait ses preuves pendant des dizaines d’années, sur le téléphone mobile. On implanterait donc une telle puce (p.ex. du type EMV), dans ce contexte souvent appelée secure element, sur le téléphone ou sur la carte SIM pour protéger les clés de cryptage utilisées pour l’initiation d’un paiement électronique. La sécurité des données sensibles est donc assurée par le téléphone lui-même, on peut donc parler d’un concept on-the-device.
La nécessité de la présence d’un tel secure element représente pourtant un frein considérable à l’adoption de systèmes de paiement mobile basés sur des technologies du type NFC, surtout parce que le modèle économique pour les différents intervenants (banques, émetteurs de cartes, acquéreurs de transactions, intégrateurs techniques, constructeurs de téléphones, opérateurs mobiles…) n’est pas encore clairement défini et que la part du gâteau à laquelle ces intervenants pourraient prétendre risque d’être trop petite pour que le modèle soit économiquement viable.
En effet, aujourd’hui, quand l’authenticité des transactions de paiement initiées par une carte de paiement ne peut plus être assurée, parce que les informations stockées sur cette carte ont été interceptées par des tiers, la carte peut être désactivée et remplacée par l’émetteur. Ceci est lié à un coût non-négligeable, incluant la production d’une nouvelle puce, sa configuration ainsi que toute la logistique associée à la transmission de cette puce vers le client final. Ces coûts risquent même d’augmenter s’il faut remplacer des éléments à l’intérieur d’un téléphone mobile, surtout si l’opérateur de la solution de paiement (la banque ou un autre établissement de paiement) doit faire appel à d’autres intervenants comme l’opérateur mobile ou le constructeur du téléphone.
Une alternative serait la construction d’un modèle de sécurité indépendant d’un tel élément physiquement présent sur les téléphones, dans le cloud. Les informations sensibles résident désormais dans un système centralisé et le téléphone n’est plus qu’un moyen simple pour se connecter à ce cloud. L’argument principal en faveur de ce concept est qu’il est moins complexe de sécuriser et maintenir un système central qu’une multitude de téléphones équipés de matériel spécialisé et qu’il est plus intuitif pour les utilisateurs de smartphones de se connecter à un service, ce qu’ils font déjà tous les jours. L’avantage principal de cette approche est qu’il n’est plus nécessaire de produire, distribuer et maintenir du matériel propriétaire pour le service de paiement. En effet, l’infrastructure mise à disposition par les constructeurs et les opérateurs mobiles suffit à supporter un tel système et les fonctionnalités de paiement peuvent facilement être implémentées sous forme d’applications sur les téléphones mobiles.
Le revers de la médaille de la simplicité de cette approche est clairement l’aspect de la sécurité. Si, d’un côté, les informations sensibles stockées sur des puces distribuées géographiquement sont en possession du payeur, elles se trouvent de l’autre côté toutes concentrées à un endroit dans le cloud. Il serait donc désormais envisageable de récupérer un grand nombre de données sensibles qui peuvent servir pour effectuer des paiements si on arrivait à trouver une faille de sécurité dans le cloud permettant d’accéder à ces informations. Ceci est d’autant plus critique s’il y a des numéros de cartes de paiement traditionnelles stockés dans le cloud, tel que c’est souvent le cas pour les portemonnaies électroniques.
Le cloud public ou le cloud privé ?
Il est donc par conséquent d’une importance primordiale que l’infrastructure centrale soit protégée d’après les standards de sécurité les plus stricts du secteur financier. Un des plus grands atouts d’un cloud est le fait que l’infrastructure physique nécessaire peut être délocalisée, accédée via le réseau, virtualisée et surtout mutualisée. Ceci signifie que beaucoup de services de nature très hétérogène peuvent être amenés à se partager les mêmes unités de stockage et de traitement ainsi que les mêmes infrastructures de communication. Même si ces dernières années, des efforts et progrès considérables ont été faits dans l’optimisation de l’allocation de ces ressources et dans l’isolation parfaite des applications exécutées sur cette infrastructure, le risque de contagion d’un système impacté par une intrusion malveillante vers un autre reste élevé. De plus, la loi luxembourgeoise interdit aux institutions financières de délocaliser leurs centres de traitement à l’étranger, ce qui exclut les services les plus grands et les plus connus tel que Amazon EC2 ou Google Cloud Platform comme prestataires éligibles.
L’alternative qui permet de limiter au maximum le risque de contagion est d’utiliser une infrastructure physique dédiée au service en question, ou à des services financiers similaires qui exige de respecter les mêmes normes de sécurité dans les applications qui y sont déployées. On parle alors communément de nuage privé ou private cloud. Cette infrastructure peut être hébergée par la banque ou le prestataire de services de paiement même, ou par des prestataires spécialisés et également soumis à la surveillance du régulateur. La sécurisation d’une telle infrastructure privative peut de nouveau se faire d’après les standards imposés par le régulateur et appliqués dans les banques pour la protection des données qu’elles hébergent et traitent au quotidien. Avec une multitude de couches d’isolation, de filtrage et de cryptage entre le réseau public et les données sensibles à l’intérieur d’une banque, une intrusion devient extrêmement complexe et coûteuse.
La sécurité des téléphones
La sécurisation des données seules ne suffit pourtant pas pour garantir le bon fonctionnement d’un système de paiement mobile et pour minimiser le risque de fraude. La partie applicative responsable de la communication avec le système central et l’initiation des opérations de paiement est distribuée par l’intermédiaire d’un registre d’applications, souvent opéré par le constructeur du téléphone, vers les appareils des utilisateurs finaux. Une fois l’application installée, l’utilisateur devra l’initialiser pour définir les moyens de paiement sous-jacents qu’il désire associer à son téléphone. Les modes de fonctionnement dépendent du type de l’application : certaines permettent de créer un compte prépayé et de l’alimenter par l’intermédiaire d’un virement bancaire ou d’une transaction par carte, d’autres permettent un accès direct au compte courant auprès de la banque de l’utilisateur. Pour minimiser le risque de fraude par des inconnus, et en même temps faciliter la mise en œuvre de l’obligation know-your-customer, il est préférable d’utiliser un mécanisme d’authentification à plusieurs facteurs (p.ex. Luxtrust) à l’intérieur d’une convention déjà existante entre le payeur et sa banque de confiance. L’association d’une carte de paiement ou d’un compte courant peut se faire de manière très simple en scannant un code spécifique avec la caméra de son téléphone à partir du système home-banking de sa banque. Cette méthode permet de garder la boucle d’authentification fermée et de s’assurer que seulement les utilisateurs qui ont déjà préalablement été identifiés positivement par la banque pourront avoir accès au paiement mobile.
Cette phase d’initialisation de l’application permet aussi de mettre en place toutes les mesures de sécurisation de la connexion entre le téléphone et le système central. Un certificat unique pour cet utilisateur est généré et stocké sur le téléphone, permettant de l’identifier à chaque connexion avec le cloud. L’utilisateur devra définir un code personnel qui lui sera demandé lors de chaque paiement pour éviter qu’un tiers puisse effectuer des transactions après avoir volé le téléphone. Un cryptogramme de ce code personnel est stocké dans le cloud. En parallèle, un identifiant générique pour le compte bancaire est généré dont une moitié est déposée dans le cloud et l’autre dans l’espace crypté du téléphone. Ceci rend l’exécution d’une transaction seulement possible si les deux moitiés sont rassemblées. Par conséquent, même si une personne malveillante arrivait à infiltrer le système central du cloud et à télécharger toutes les informations sensibles qu’il contient, cela ne lui permettrait toujours pas d’effectuer des transactions de paiement car il lui manquerait toujours une moitié des identifiants.
De plus, toutes les grandes plateformes mobiles (iOS, Android, Blackberry, Windows Mobile…) permettent de récupérer un identifiant unique de l’équipement du téléphone, permettant au système central de détecter si le certificat généré pour un téléphone lors de l’activation a été copié sur un autre. De manière similaire, il est possible d’identifier le numéro de téléphone associé à la carte SIM pour s’assurer que personne n’essaie de simuler des transactions de paiement à partir d’un canal de communication différent de celui utilisé pendant la phase d’activation.
Un point faible des systèmes de paiement par carte se situe souvent au niveau du marchand. Quand le payeur décide d’utiliser une carte de paiement, il est obligé d’interagir de manière active avec le terminal du marchand. Le payeur n’a pas la garantie que le marchand, qui par ce biais, entre en contact avec des informations de paiement sensibles, ne les utilise pas à des fins illicites. Pour contrer ce risque, il est donc extrêmement important d’éviter tout flux d’informations du payeur vers le marchand et que toute information par rapport au paiement (le montant, la référence etc.) puisse être validée explicitement par le payeur avant d’autoriser la transaction.
Les risques principaux de sécurité encourus par une telle architecture peuvent donc être contrôlés, même si le risque zéro n’existe pas. Il est important de maintenir un bon équilibre entre la sécurité, l’ergonomie et la facilité d’utilisation d’un tel service. En conclusion, il serait tout à fait possible d’égaliser, voire de dépasser le niveau de sécurité des instruments de paiement existants en identifiant les principales sources de risque et de trouver des solutions viables pour chacune.
La confiance du client
Un des principaux freins à l’adoption à grande échelle des systèmes de paiement mobiles naissants où déjà existants est sans doute la confiance du client en ce nouvel instrument de paiement. Ce sera le rôle des banques de lutter contre la perception des clients qu’il n’est pas sécurisé de transférer la responsabilité pour l’initiation d’un paiement à un téléphone par rapport à l’utilisation d’une carte de paiement sur un point de vente ou à distance. Les banques se trouvent dans la position la plus appropriée pour procéder à l’éducation de leurs clients, car ils disposent déjà d’une relation de confiance avec eux. C’est un défi beaucoup plus important pour les nouveaux entrants (Apple, Google, Amazon ou encore les nombreuses autres petites start-ups innovatrices) qui n’ont pas d’historique dans les services financiers et de paiements et ne bénéficient par conséquent pas de la même crédibilité envers leur clientèle.
Georges Berscheid