Crypto-casino
Torrent Gear
Comment fonctionne le cryptage des données dans les systèmes de paiement
Les systèmes de paiement fonctionnent avec les données les plus sensibles - PAN (numéro de carte), durée de validité, CVV/CVC, tokens 3-DS, coordonnées bancaires, identifiants de portefeuille. Leur fuite - amendes, retrait du merchant des banques/PSP et perte financière directe. La protection est construite de manière multicouche : cryptage dans le canal (TLS), cryptage et/ou tokenization en stockage, gestion stricte des clés et modules de confiance matérielle (HSM). Ci-dessous - tout le « convoyeur » de sécurité en langage simple.
Briques de base
Cryptographie symétrique
Algorithmes : AES-GCM/CTR/CBC (la norme de facto est AES-GCM).
Avantages : haute vitesse, clés compactes.
Inconvénients : vous devez négocier en toute sécurité la clé et IV/nonce.
Cryptographie asymétrique
Algorithmes : RSA-2048/3072, ECC (P-256/384, Ed25519).
Utilisation : échange/emballage de clés, signatures, PKI, certificats TLS.
Avantages : ne nécessite pas de secret commun à l'avance.
Inconvénients : plus lent que le chiffrement symétrique.
Идея Perfect Forward Secrecy (PFS)
Les clés de session sont négociées par ECDHE Effemer. Même si la clé privée du serveur s'échappe un jour, les sessions passées ne seront pas rentables.
Chiffrement « en transit » : TLS 1. 2/1. 3
1. Poignée de main (TLS handshake) : le client et le serveur acceptent les versions/cryptages, le serveur présente un certificat (PKI), échange des clés éphémères (ECDHE) → la clé symétrique de session naît.
2. Données : sont transmises en modes AEAD (AES-GCM/ChaCha20-Poly1305) avec authentification.
3. Optimisations : TLS 1. 3 raccourcit les rondes, supporte la résumption ; 0-RTT utilisent prudemment (uniquement les demandes idempotentes).
4. Pratique du paiement : Nous interdisons les SSLv3/TLS1. 0/1. 1, allumons le TLS1. 2/1. 3, stapling OCSP, HSTS, titres de sécurité stricts.
Cryptage « stocké » : at rest
Options
Encryptage complet des volumes/OBD (TDE) : rapidement injecté, protège contre l'accès « froid » au média, mais pas contre les fuites à travers l'application compromise.
Niveau bit/champ (FLE) : les champs individuels (PAN, IBAN) sont chiffrés. Granulairement, mais plus difficile à mettre en œuvre et à indexer.
Cryptage de formatage (FPE) : utile lorsque vous avez besoin de la vue « 16 chiffres comme 16 chiffres ».
Tokénisation : Le PAN est remplacé par un jeton (chaîne inutile) ; le présent PAN est stocké dans une vault token sous protection renforcée. Le paiement/retour utilise un jeton → le merchant ne traite pas les cartes « crues ».
Une idée clé
Le stockage n'est pas plus important que « quel algorithme », mais où sont les clés et qui peut désintéresser. C'est pourquoi...
Gestion des clés : KMS, HSM et enveloppes
Hiérarchie des clés (envelope encryption)
Root/KEK (Key Encryption Key) : classe de protection élevée, stockée et exécutée dans HSM.
DEK (Data Encryption Key) : cryptage de données/lots/tables spécifiques ; il est lui-même crypté KEK 'om.
Rotation : règles de rotation planifiée et non planifiée (en cas d'incident) KEK/DEK ; la version des clés est indiquée dans les métadonnées du chiffrement.
HSM (Hardware Security Module)
Module matériel certifié (par exemple FIPS 140-2/3) qui stocke et exécute des opérations avec des clés en lui-même.
Ne donne pas de clés privées à l'extérieur, prend en charge les limites/politiques d'utilisation, l'audit.
Utilisé pour : la génération de clés, l'emballage DEK, les clés serveur 3-DS, les clés EMV, les opérations PIN, la signature de message.
KMS
Centralise la stratégie de clé, le versioning, les accès, les journaux et les API.
En liaison avec HSM, implémente l'encryption envelope et la rotation automatique.
Normes de cartes et spécificités de l'industrie
DSS PCI (et logique de minimisation)
L'idée principale est de ne pas stocker le CVV, minimiser la zone de traitement PAN (scope).
Si possible - donner l'entrée PAN sur Hosted Fields/Iframe PSP → le merchant n'a pas accès aux données brutes.
Logs, backups, vides sont les mêmes règles que la prod : masquage, cryptage, rétention.
EMV, PIN и POS
EMV puce/contact-less : cryptogrammes au niveau de la carte/terminal, protection contre le clonage de la bande de mage.
Blocs PIN et ISO 9564 : Le PIN est crypté de pin-pad au traitement, fonctionne avec HSM (pin-traductions, zones clés).
DUKPT (Derived Key Per Transaction) : Sur un POS, chaque paiement est chiffré avec une clé unique dérivée de BDK, → le fait de compromettre un message ne tire pas les autres.
PCI P2PE : système de cryptage « de bout en bout » certifié, du pin-pad au fournisseur de décryptage.
3-D Secure (2. x)
L'authentification du titulaire de la carte est → inférieure à frod/chargbecks.
La cryptographie est utilisée pour signer des messages, échanger des clés ACS/DS/3DS Server ; les clés privées sont généralement en HSM.
Architectures types de protection des données
Option A (merchant en ligne avec PSP) :- Navigateur → HTTPS → Hosted Fields PSP (le PAN n'entre pas dans le merchant).
- PSP renvoie payment token.
- La base de données du merchant stocke le jeton + les 4 derniers chiffres et le BIN (pour UX et règles).
- Retours/répétitions - par token seulement.
- Secrets/clés - dans KMS, clés privées TLS/3-DS - dans HSM.
- L'application ↔ API est TLS/mTLS.
- Les champs sensibles sont FLE/FPE ou Tokenization ; vault est isolé.
- L'accès à la désintoxication - uniquement par des rôles de service avec « quatre yeux », les opérations - par le biais du HSM.
- Pin-pad → DUKPT/P2PE → processeur.
- Les clés de chargement du terminal sont des injecteurs clés/XSM sécurisés.
- Journal, anti-tamper de protection des périphériques.
Rotation, audit et incidents
Rotation des clés : planifiée (une fois dans X mes.) et par événement (compromission). DEK rewrap sous le nouveau KEK sans déchiffrer les données utilisateur.
Revues immuables : qui et quand a eu accès à la désintoxication/clés ; signature des loges.
Runbook de compromission : revoke/rotate immédiat, transfert de certificats, bloc de clés API, notification aux partenaires, rétrospective.
Erreurs fréquentes et comment les éviter
1. « On crypte la base de données, c'est tout ».
Non. L'application compromise lit les données en public. La tokenisation/FLE et le principe des droits les plus bas sont nécessaires.
2. Stockage CVV.
Tu ne peux pas. CVV n'est jamais stocké, même crypté (PCI DSS).
3. Les clés sont à côté des données.
Tu ne peux pas. Les clés sont dans KMS/HSM, l'accès est par rôle, un minimum de privilèges, des comptes séparés.
4. Pas de rotation/versions.
Toujours versionner les clés, stocker 'key _ version' dans les métadonnées de chiffrement.
5. TLS uniquement sur le périmètre.
Chiffrez par CDN/WAF et à l'intérieur du plan de données (servis→servis, webhooks).
6. Tokénisation « pour la vue ».
Si detokenize peut n'importe quel service n'est pas une protection. Limitez à un cercle étroit et vérifiez les appels.
7. Backaps/décharges analytiques non comptabilisés.
Le cryptage et le masquage doivent s'étendre aux backups, snapshots, vitrines BI, logs.
Chèque de mise en œuvre (bref)
Canal
TLS 1. 2/1. 3, PFS, mTLS pour les headers de sécurité internes et web, HSTS, rigoureux.
Stockage
Tokenization PAN, interdiction de stockage CVV.
FLE/FPE pour les champs critiques ; TDE comme couche de base.
Clés
KMS + HSM, encryption envelope (KEK/DEK), rotation/versions, journaux immuables.
Architecture
Hosted Fields/SDK PSP, minimisation de la zone PCI.
Séparation des rôles/réseaux, zero trust, secrets - uniquement via le gestionnaire de secrets.
Opérations
Pentest/Red Team autour du périmètre et de la logique d'affaires.
DLP/CTI-surveillance des prunes, formation du personnel.
Runbook на compromise: revoke/rotate/notify.
Mini-FAQ
Quoi de mieux pour le PAN : chiffrement ou tokenisation ?
Dans la vente - Tokenization (minimise la scope). Dans vault - cryptage avec HSM/KMS.
Ai-je besoin d'un certificat EV pour un domaine payant ?
Pas obligatoire. Plus important est le profil TLS correct, mTLS, les clés dans HSM et la discipline.
Peut-on utiliser le 0-RTT dans TLS 1 ? 3 pour les paiements ?
Pour les GET idempotent - oui. Pour POST, mieux vaut éteindre ou limiter.
Comment stocker « les 4 derniers » et BIN ?
Séparé du PAN ; ce ne sont pas des données sensibles lorsqu'elles sont correctement isolées, mais respecter le masquage dans les logs/BI.
Le cryptage dans les systèmes payants n'est pas un seul commutateur, mais un écosystème : TLS/PFS dans le canal, Tokenization et/ou FLE en stockage, gestion rigoureuse des clés via KMS + HSM, normes industrielles (PCI DSS, EMV, 3-DS), rotation et audit. Cette architecture multicouche rend la fuite de données de carte très improbable, facilite les audits et, surtout, préserve la confiance des banques, des partenaires de paiement et des utilisateurs.