Kripto-Kasino
Torrent Gear
So funktioniert die Datenverschlüsselung in Bezahlsystemen
Zahlungssysteme arbeiten mit den sensibelsten Daten - PAN (Kartennummer), Ablaufdatum, CVV/CVC, 3-DS Token, Bankdaten, Wallet-IDs. Ihr Leck sind Geldstrafen, der Entzug des Merchants von Banken/PSP und ein direkter finanzieller Verlust. Der Schutz ist mehrschichtig aufgebaut: Verschlüsselung im Kanal (TLS), Verschlüsselung und/oder Tokenisierung im Speicher, strenges Schlüsselmanagement und Hardware Trusted Modules (HSM). Unten ist die gesamte „Pipeline“ der Sicherheit in einfacher Sprache.
Grundsteine
Symmetrische Kryptographie
Algorithmen: AES-GCM/CTR/CBC (im Zahlungsverkehr ist der De-facto-Standard AES-GCM).
Vorteile: hohe Geschwindigkeit, kompakte Schlüssel.
Nachteile: Sie müssen den Schlüssel und IV/Nonce sicher verhandeln.
Asymmetrische Kryptographie
Algorithmen: RSA-2048/3072, ECC (P-256/384, Ed25519).
Verwendung: Schlüsselaustausch/Wrapper, Signaturen, PKI, TLS-Zertifikate.
Vorteile: Erfordert kein allgemeines Geheimnis im Voraus.
Nachteile: langsamer als symmetrische Verschlüsselung.
Идея Perfect Forward Secrecy (PFS)
Sitzungsschlüssel werden durch effemere ECDHE verhandelt. Selbst wenn der private Schlüssel des Servers einmal durchsickert, bleiben vergangene Sitzungen nicht entschlüsselbar.
Verschlüsselung „unterwegs“: TLS 1. 2/1. 3
1. Handshake (TLS handshake): Client und Server einigen sich auf Versionen/Chiffren, der Server legt ein Zertifikat (PKI) vor, tauschen ephemere Schlüssel (ECDHE) aus → ein sitzungssymmetrischer Schlüssel wird geboren.
2. Daten: werden in AEAD-Modi (AES-GCM/ChaCha20-Poly1305) mit Authentifizierung übertragen.
3. Optimierungen: TLS 1. 3 verkürzt Runden, unterstützt resumption; 0-RTT wird vorsichtig verwendet (nur idempotente Anfragen).
4. Praxis für Zahlungen: Wir verbieten SSLv3/TLS1. 0/1. 1, schalten Sie TLS1 ein. 2/1. 3, OCSP Stapeln, HSTS, strenge Sicherheitsüberschriften.
Verschlüsselung „auf Lager“: at rest
Varianten
Volume/DB Complete Encryption (TDE): Schnell eingeführt, schützt vor „kalten“ Medienzugriffen, aber nicht vor Lecks durch eine kompromittierte Anwendung.
Bit-/Feldebene (FLE): Die einzelnen Felder (PAN, IBAN) werden verschlüsselt. Granular, aber schwieriger zu implementieren und zu indexieren.
Formatierungserhaltende Verschlüsselung (FPE): Nützlich, wenn Sie die Ansicht „16 Ziffern als 16 Ziffern“ benötigen.
Tokenisierung: Die PAN wird durch ein Token (eine bedeutungslose Zeichenfolge) ersetzt; Diese PAN wird im Token-Tresor unter erhöhtem Schutz gespeichert. Bei der Zahlung/Rückgabe wird ein Token verwendet → der Merchant verarbeitet keine „rohen“ Karten.
Schlüsselidee
Bei der Lagerung sei nicht „welcher Algorithmus“ wichtiger, sondern wo die Schlüssel liegen und wer entgiften kann. Deshalb...
Schlüsselmanagement: KMS, HSM und Umschläge
Schlüsselhierarchie (envelope encryption)
Root/KEK (Key Encryption Key): Hohe Schutzklasse, gespeichert und im HSM ausgeführt.
DEK (Data Encryption Key): verschlüsselt bestimmte Daten/Chargen/Tabellen; selbst durch KEK verschlüsselt.
Rotation: Regeln der geplanten und ungeplanten (im Falle eines Vorfalls) Rotation KEK/DEK; Die Version der Schlüssel wird in den Metadaten des Chiffretextes angegeben.
HSM (Hardware Security Module)
Ein Hardwaremodul, das zertifiziert ist (z. B. FIPS 140-2/3), das Schlüsseloperationen in sich selbst speichert und ausführt.
Gibt keine privaten Schlüssel nach außen, unterstützt Limits/Nutzungsrichtlinien, Audit.
Verwendet für: Schlüsselgenerierung, DEK-Wrapper, Server-Key- 3-DS, EMV-Schlüssel, PIN-Operationen, Nachrichtensignatur.
KMS
Zentralisiert Schlüsselrichtlinien, Versionierung, Zugriffe, Protokolle und APIs.
In Verbindung mit HSM implementiert envelope encryption und automatische Rotation.
Kartenstandards und branchenspezifische Besonderheiten
PCI DSS (und Minimierungslogik)
Die Grundidee: CVV nicht lagern, PAN-Behandlungsbereich (Scope) minimieren.
Wo möglich - geben Sie die PAN-Eingabe an Hosted Fields/Iframe PSP → der Händler hat keinen Zugriff auf Rohdaten.
Protokolle, Backups, Dumps - die gleichen Regeln wie prod: Masking, Encryption, Retention.
EMV, PIN и POS
EMV-Chip/kontaktlos: Kryptogramme auf Karten-/Terminalebene, Schutz vor Klonen des Magierstreifens.
PIN-Blöcke und ISO 9564: PIN verschlüsselt vom Pin-Pad bis zur Verarbeitung, arbeitet mit HSM (Pin-Transfers, Schlüsselzonen).
DUKPT (Derived Unique Key Per Transaction): Am POS wird jede Zahlung mit einem eindeutigen Schlüssel verschlüsselt, der von BDK abgeleitet ist → die Kompromittierung einer Nachricht zieht keine anderen mit sich.
PCI P2PE: Ein zertifiziertes Ende-zu-Ende-Verschlüsselungsschema vom Pin-Pad bis zum Entschlüsselungsanbieter.
3-D Secure (2. x)
Die Authentifizierung des Karteninhabers → weniger Betrug/Chargebacks.
Kryptographie wird für Nachrichtensignaturen, Schlüsselaustausch ACS/DS/3DS Server verwendet; private Schlüssel sind in der Regel in HSM.
Typische Datenschutzarchitekturen
Variante A (Online-Merchant mit PSP):- Der Browser → HTTPS → Hosted Fields PSP (PAN erreicht den Merchant nicht).
- Die PSP gibt den Payment Token zurück.
- In der Merchant-DB werden das Token + die letzten 4 Ziffern und die BIN (für UX und Regeln) gespeichert.
- Retouren/Wiederholungen - nur per Token.
- Geheimnisse/Schlüssel in KMS, private Schlüssel TLS/3-DS in HSM.
- Die Anwendung ↔ API ist TLS/mTLS.
- Empfindliche Felder - FLE/FPE oder Tokenisierung; vault ist isoliert.
- Zugang zur Entgiftung - nur durch Service-Rollen mit „vier Augen“, Operationen - über HSM.
- Pin-Pad → DUKPT/P2PE → Verarbeitung.
- Die Ladeschlüssel des Terminals sind über sichere Schlüssel-Injektoren/HSMs.
- Protokollierung, Anti-Tamper-Schutz-Geräte.
Rotation, Audit und Incidents
Rotation der Schlüssel: geplant (alle X Monate) und durch das Ereignis (kompromittiert). DEK rewrap unter dem neuen KEK ohne Entschlüsselung der Benutzerdaten.
Unveränderliche Protokolle: wer und wann Zugriff auf Detox/Schlüssel erhalten hat; Signieren von Protokollen.
Kompromittierendes Runbook: sofortige Revoke/Rotate, Neuausstellung von Zertifikaten, API-Schlüsselblock, Partnerbenachrichtigung, Retrospektive.
Häufige Fehler und wie man sie vermeidet
1. „Wir verschlüsseln die Datenbank, also ist alles in Ordnung“.
Nein. Eine kompromittierte Anwendung liest Daten in die Öffentlichkeit. Wir brauchen Tokenisierung/FLE und das Prinzip der geringsten Rechte.
2. CVV-Lagerung.
Das geht nicht. CVV wird nie gespeichert, auch nicht verschlüsselt (über PCI DSS).
3. Schlüssel neben den Daten.
Das geht nicht. Schlüssel - im KMS/HSM, Zugriff - nach Rollen, Mindestprivilegien, separate Konten.
4. Keine Rotation/Versionen.
Versionieren Sie die Schlüssel immer, speichern Sie' key _ version 'in den Metadaten des Chiffretextes.
5. TLS ist nur am Perimeter.
Verschlüsseln Sie hinter CDN/WAF und innerhalb des Datenplans (servis→servis, Webhooks).
6. Tokenisierung „für die Art“.
Wenn detokenize kann jeder Dienst ist kein Schutz. Beschränken Sie sich auf einen engen Kreis und prüfen Sie die Herausforderungen.
7. Nicht gemeldete Backups/analytische Uploads.
Verschlüsselung und Maskierung sollten für Backups, Snapshots, BI-Showcases und Protokolle gelten.
Checkliste Umsetzung (kurz)
Kanal
TLS 1. 2/1. 3, PFS, mTLS für interne und Webhooks, HSTS, strenge Security-Header.
Aufbewahrung
PAN-Tokenisierung, CVV-Speicherverbot.
FLE/FPE für kritische Felder; TDE als Basisschicht.
Schlüssel
KMS + HSM, Envelope-Verschlüsselung (KEK/DEK), Rotation/Versionen, unveränderliche Protokolle.
Architektur
Hosted Fields/PSP SDK, Minimierung der PCI-Zone.
Rollenaufteilung/Netzwerke, Zero Trust, Geheimnisse - nur durch den Secret Manager.
Operationen
Pentest/Red Team nach Umfang und Geschäftslogik.
DLP/CTI-Überwachung von Abflüssen, Schulung des Personals.
Runbook на compromise: revoke/rotate/notify.
Mini-FAQ
Was ist besser für PAN: Verschlüsselung oder Tokenisierung?
In der Produktion - Tokenisierung (minimiert das Scope). In vault - Verschlüsselung mit HSM/KMS.
Brauche ich ein EV-Zertifikat für die Zahlungsdomäne?
Nicht erforderlich. Wichtiger sind das korrekte TLS-Profil, mTLS, die Schlüssel im HSM und die Disziplin.
Kann ich 0-RTT in TLS 1 verwenden? 3 für Zahlungen?
Für idempotente GETs ja. Für POST ist es besser, abzuschalten oder einzuschränken.
Wie lagere ich die „letzten 4“ und BIN?
Getrennt von der PAN; Dies sind keine sensiblen Daten, wenn sie richtig isoliert sind, aber beachten Sie die Maskierung in Protokollen/BI.
Verschlüsselung in Zahlungssystemen ist kein einzelner Kippschalter, sondern ein Ökosystem: TLS/PFS im Kanal, Tokenisierung und/oder FLE im Speicher, strenges Schlüsselmanagement durch KMS + HSM, Industriestandards (PCI DSS, EMV, 3-DS), Rotation und Audit. Diese vielschichtige Architektur macht das Durchsickern von Kartendaten äußerst unwahrscheinlich, vereinfacht die Durchführung von Audits und bewahrt vor allem das Vertrauen von Banken, Zahlungspartnern und Nutzern.