Chiffrement : Thales Payment Services complète ses HSM avec le Confidential Computing d’AWS
Éditeur d’une plateforme de gestion des moyens de paiement en mode SaaS, la filiale de Thales est confrontée aux défis de la montée en charge de son service. Ses systèmes matériels de gestion de clés étant, par nature, limités en élasticité, le Français est allé la chercher chez AWS.
Inconnue du grand public, l’entité Thales Payment Services compte 3 000 clients dans le monde, notamment pour l’émission de leurs cartes bancaires physiques, mais aussi pour proposer des services de cartes bancaires clés en main via la plateforme Thales D1. Cette plateforme permet aux clients des banques de contrôler eux-mêmes leurs moyens de paiement via une application mobile.
Ces clients peuvent créer des comptes, des cartes virtuelles, demander des cartes physiques et les faire livrer à domicile, et peuvent également ajouter les cartes physiques ou virtuelles dans un portefeuille numérique de type Apple Pay : « pour les banques plus traditionnelles, c’est un vrai challenge technologique, car elles s’appuient sur un système qui a été construit pour l’autorisation en masse, pour la résilience massive, mais pas forcément pour intégrer des use case communicants », explique Cyril Solé, responsable de l’équipe infrastructure, sécurité et compliance chez Thales Payment Services.
Six cents banques dans 60 pays proposent des services en ligne via D1, ce qui représente 180 millions de cartes gérées sur la plateforme, un chiffre en croissance de 10 millions chaque mois.
Une plateforme en grande partie portée par AWS
Le fonctionnement d’une plateforme de paiement est, par définition, critique. Toute indisponibilité va fortement pénaliser la banque et ses clients. De plus, la plateforme est fréquemment soumise à de forts pics de trafic lors des fêtes de Noël ou du Black Friday, ainsi qu’à une forte saisonnalité. En outre, comme tout service SaaS, pour être compétitive, la plateforme d’exploitation doit s’ajuster au plus juste à l’activité.
Pour ces raisons, l’éditeur a déployé Thales D1 sur un Virtual Private Cloud d’AWS. Le logiciel fait largement appel aux services managés délivrés par AWS, notamment l’API Gateway, WAF et les fonctions serverless Lambda et DynamoDB pour l’API exposée aux systèmes bancaires et aux applications mobiles des utilisateurs.
Le cluster métier D1 regroupe toutes les fonctions métiers. La pile logicielle est là composée de conteneurs mis en œuvre sur AWS ECS et EKS, ainsi que d’un service de bases de données relationnelles RDS, pour PostgreSQL et MongoDB. La plateforme est interfacée avec les partenaires, les réseaux de Visa et de Mastercard, avec Apple pour accéder à Apple Pay et une intégration a été réalisée avec le centre de production des cartes physiques de Thales.
Le matériel cryptographique reste un point bloquant pour l’élasticité
Il y a une exception à cette architecture 100 % AWS, une brique ultra sensible, le cluster cryptographique. Ce dernier ne tourne pas sur AWS, mais sur un autre cloud, car il met en œuvre les technologies Thales : les HSM Luna 7 et Payshield 10K, ainsi que le logiciel de gestion de clé KMS Thales.
« Nous avons une consommation cryptographique très importante et qui ne fait qu’augmenter. »
Cyril SoléResponsable équipe infrastructure, sécurité et compliance, Thales Payment Services
Toutes les clés sont stockées dans ce système bien distinct de la plateforme de production sur AWS. Cette brique matérielle dans l’architecture de la plateforme a un impact direct sur l’élasticité du service, comme l’explique Cyril Solé : « nous avons une consommation cryptographique très importante et qui ne fait qu’augmenter. Aujourd’hui, nous avons de l’ordre de 500 millions d’opérations cryptographiques sur notre cluster cryptographique et c’est un vrai challenge ».
Ce cluster est absolument clé dans le fonctionnement du service. Lorsque le client lance son application mobile et qu’il veut consulter les informations de sa carte bancaire, l’application va générer une requête HTTP via le SDK D1. Les informations sont lues dans la base de données DynamoDB. « Celles-ci sont chiffrées avec une clé qui est gérée dans les HSM. La donnée est donc envoyée au cluster cryptographique pour opérer un transchiffrement. Dans l’HSM, on va déchiffrer et rechiffrer la donnée avec une clé différente, avec une clé de transport, une clé de cession. En réponse à la requête HTTP, la donnée va se retrouver dans le mobile », explique Cyril Solé.
Le SDK va enfin déchiffrer la donnée et l’utilisateur pourra accéder à son information et continuer ses achats.
Des enclaves cloud pour soulager les HSM
Dans cette architecture, le seul moyen d’augmenter la puissance du cluster cryptographique implique d’ajouter de nouveaux HSM matériels dans les racks. Alors, pour trouver de l’élasticité sans remettre en cause le schéma de sécurité de la plateforme, Thales Payment Service a exploité la solution de Confidential Computing d’AWS, les enclaves Nitro.
« Entre ces 2 KMS, un canal de communication propriétaire leur permet de communiquer et de s’échanger des actifs de manière complètement confidentielle sur un protocole sécurisé ».
Cyril SoléResponsable équipe infrastructure, sécurité et compliance, Thales Payment Services
Une partie de ce cluster déborde sur le Cloud AWS avec un cluster EC2 contenant des enclaves Nitro : « nous avons placé une version spéciale de notre KMS au sein d’une enclave Nitro. Entre ces 2 KMS, un canal de communication propriétaire leur permet de communiquer et de s’échanger des actifs de manière complètement confidentielle sur un protocole sécurisé ».
L’architecture exécutée par l’enclave Nitro est 100 % microservices. Le KMS Thales enclavé est lui-même un microservice. Il communique avec des convertisseurs de protocole TCP vers VSOC et VSOC vers TCP développés par Thales.
En effet, nativement, une enclave Nitro n’a pas de moyen de communiquer avec l’extérieur pour des raisons de sécurité. Thales a créé ces convertisseurs de protocole pour que le cluster EC2 communique avec l’enclave et permette l’échange de données avec le KMS du cluster cryptographique Thales et le KMS enclavé.
Autre microservice développé par Thales, un lanceur d’enclave : « pour faire une analogie, le lanceur d’enclave, c’est un petit peu l’entry point de Docker ; c’est la routine qui se lance lorsqu’on démarre l’enclave », explique Cyril Solé. « C’est elle qui initialise le KMS enclave ».
Au démarrage, le lanceur d’enclave contacte le système Nitro pour demander une attestation cryptographique. Cette attestation cryptographique est soumise au KMS dans le cluster cryptographique. Le cluster va vérifier l’authenticité de l’enclave via l’attestation, car le HSM dispose du certificat racine du système Nitro. À l’inverse, le KMS enclavé vérifie à son tour l’authenticité du cluster Thales.
Dès lors, le canal de communication sécurisé peut être ouvert. Une clé de configuration est alors envoyée dans l’enclave. Celle-ci est nécessaire pour permettre la poursuite du démarrage. Cette clé permet d’aller chercher un fichier de configuration dans S3, le déchiffrer dans l’enclave et achever le démarrage du KMS avec ces paramètres. Le KMS est alors opérationnel.
Le KMS enclavé assure une fonction de cache pour certains cas d’usage
« Le monitoring est un vrai challenge parce que ce qui se passe dans l’enclave reste dans l’enclave. »
Cyril SoléResponsable équipe infrastructure, sécurité et compliance, Thales Payment Services
Quand D1 contacte le KMS enclavé avec une requête HTTP, celui-ci contacte le KMS du cluster cryptographique pour obtenir une clé nécessaire au calcul. Cette clé est descendue dans l’enclave. Dès lors, les autres appels pour le même Use Case vont bénéficier de la mise en cache de l’enclave : « c’est là que l’on obtient l’élasticité recherchée et la réduction de la latence. La plupart des calculs cryptographiques éligibles sont exécutés dans le VPC (Virtual Private Cloud), ce qui limite les allers-retours avec les HSM hardware ». Le KMS Thales gère du labeling de clés : toutes les clés et tous les use cases ne sont pas habilités à tourner en enclave.
Autre développement mené par Thales pour ses enclaves Nitro, un microservice de monitoring. Cyril Solé explique pourquoi ce module a dû être développé : « le monitoring est un vrai challenge parce que ce qui se passe dans l’enclave reste dans l’enclave. La technologie n’est pas très verbeuse or, malgré tout, on veut scaler sur des métriques de types CPU, mémoire, etc. »
L’équipe projet a donc écrit un module qui s’exécute dans l’enclave. Celui-ci est signé et vérifié par les équipes de Thales Payment Services. Il remonte les indicateurs de fonctionnement interne de l’enclave au niveau de l’instance EC2 où il est possible d’installer un agent de supervision classique et même se livrer à l’autoscale.
Propos recueillis lors de l’AWS Summit Paris 2025.
