Crypto-casinò
Torrent Gear
Come funziona la crittografia dei dati sui sistemi di pagamento
I sistemi di pagamento operano i dati più sensibili - PAN (numero di carta), scadenza, CVV/CVC, 3-DS token, identità bancarie, identificatori portafogli. La loro fuga di notizie - multe, revoca di merchant da banche/PSP e perdita finanziaria diretta. La protezione è progettata in modo multi-strato: crittografia del canale (TLS), crittografia e/o tornizzazione dello storage, gestione rigorosa delle chiavi e plug-in hardware (HSM). Sotto c'è tutta la catena di sicurezza in modo semplice.
Mattoni di base
Crittografia simmetrica
Algoritmi: AES-GCM/CTR/CBC (standard di fatto AES-GCM).
I vantaggi sono alta velocità, chiavi compatte.
Contro: dobbiamo trovare un accordo sicuro sulla chiave e sulla IV/nonce.
Crittografia asimmetrica
Algoritmi RSA-2048/3072, ECC (P-256/384, Ed25519).
Uso: scambio/avvolgimento chiavi, firme, PKI, certificati TLS.
I vantaggi non richiedono un segreto generale in anticipo.
I contro sono più lenti della crittografia simmetrica.
Идея Perfect Forward Secrecy (PFS)
Le chiavi di sessione sono concordate con un ECDHE effeminato. Anche se la chiave privata del server venisse deselezionata, le sessioni passate resterebbero inadeguate.
Crittografia nel percorso: TLS 1. 2/1. 3
1. Stretta di mano (TLS handshake) - Client e server accettano le versioni/codici, il server invia il certificato (PKI), condividono le chiavi effimere (ECDHE), e nasce la chiave simmetrica di sessione.
2. Dati trasmessi in modalità AEAD (AES-GCM/ChaCha20-Poly1305) con autenticazione.
3. Ottimizzazioni: TLS 1. 3 riduce i giri, supporta respumption; 0-RTT viene utilizzato con cautela (solo richieste idempotate).
4. Prassi per pagamenti: proibiamo SSLv3/TLS1. 0/1. 1, includiamo TLS1. 2/1. 3, OCSP stapling, HSTS, titoli di sicurezza rigorosi.
Crittografia di storage: at rest
Opzioni
Crittografia completa dei volumi/database (TDE): immessa rapidamente, protegge dall'accesso a freddo al supporto, ma non dalla fuoriuscita tramite un'applicazione compromessa.
Campo di bit/livello (FLE) - I singoli campi (PAN, BAN) vengono cifrati. Granulare, ma più difficile da implementare e indicizzare.
Formated Memory Crittografia (FPE) - Utile quando si desidera visualizzare 16 cifre come 16 cifre.
Tornitura: PAN sostituito da token (una stringa inutile) Il vero PAN è memorizzato in token vault con protezione rafforzata. Per i pagamenti/rimborsi viene utilizzato il token merchant non elabora le carte crude.
Idea chiave
Non è il tipo di algoritmo che conta, ma dove sono le chiavi e chi può disintossicare. Quindi...
Gestione chiavi: KMS, HSM e buste
Gerarchia chiavi (encryption)
Root/KEK (Key Encryption Key) - Alta protezione, memorizzata e eseguita in HSM.
DEK (Data Encryption Key) - Cifra dati/lotti/tabelle specifici. crittografato da KEK.
Rotazione: regolamenti di rotazione KEK/DEK pianificati e non pianificati la versione delle chiavi è indicata nei metadati del cifrotesto.
HSM (Hardware Security Module)
Un modulo hardware certificato (ad esempio FIPS 140-2/3) che memorizza e esegue le operazioni con le chiavi all'interno.
Non dà chiavi private all'esterno, supporta limiti/regole d'uso, controllo.
Usato per generare chiavi, avvolgenti DEK, chiavi server 3-DS, chiavi EMV, PIN, firma messaggi.
KMS
Centralizza la politica delle chiavi, la versioning, la disponibilità, i registri e l'API.
In collegamento con HSM, implementerà encryption e rotazione automatica.
Standard di carte e specificità di settore
PCI DSS (e logica di minimizzazione)
L'idea principale è di non conservare CVV, minimizzare l'area di elaborazione PAN (scope).
Se possibile, non è possibile immettere PAN su Hosted Fields/Iframe PSP al Merchant.
Logi, bacapi, dampi sono le stesse regole del proto: occultamento, crittografia, retenza.
EMV, PIN и POS
EMV chip/contatto-less: crittogrammi a livello di mappa/terminale, protezione contro la clonazione della banda magica.
PIN e ISO 9564: PIN crittografato dal pin al processore, con HSM (PIN, zone chiave).
DUKPT (Derived Unique Key Per Trasmissione) - Su POS ogni pagamento è cifrato con una chiave unica derivata da BDK.
PCI P2PE: crittografia certificata «end-to-end» dal pin-pad al provider di decrittografia.
3-D Secure (2. x)
L'autenticazione del titolare della carta è minore di frode/charjbeek.
La crittografia viene utilizzata per firmare messaggi, scambiare chiavi ACS/DS/3DS Server; chiavi private di solito in HSM.
Architetture tipiche per la protezione dei dati
Opzione A (online merchant con PSP):- Il browser HTTPS Hosted Fields PSP (PAN non accede al merchant).
- PSP restituisce payment token.
- Il database di merchant memorizza i token + ultimi 4 numeri e BIN (per UX e regole).
- Restituzioni/ripetizioni solo per token.
- I segreti/chiavi sono in KMS, le chiavi private TLS/3-DS in HSM.
- App ↔ API - TLS/mTLS.
- I campi sensibili sono FLE/FPE o tornitura; vault è isolato.
- Accesso alla disintossicazione solo per i ruoli di servizio a quattro occhi, operazioni tramite HSM.
- Pin-pad → DUKPT/P2PE →.
- Le chiavi di caricamento del terminale sono tramite iniettori chiave/CSM protetti.
- Registrazione, anti-tamper protezione dispositivi.
Rotazione, controllo e incidenti
Rotazione delle chiavi: pianificata (X mes) e per evento (compromissione). DEK rewrap sotto il nuovo KEK senza decifrare i dati utente.
Registri immutabili: chi e quando ha avuto accesso alla disintossicazione/chiave; Firma dei cassetti.
Runbook compromissione: revoke/rotate immediato, reimpostazione dei certificati, unità API, notifica dei partner, retrospettiva.
Errori frequenti e come evitarli
1. «Stiamo cifrando il database, quindi va tutto bene».
No, no. L'applicazione compromessa legge i dati in pubblico. Ci vogliono la tornizzazione/FLE e il principio dei diritti minimi.
2. Storage CVV.
Non puoi. CVV non viene mai memorizzato, nemmeno criptato (PCI DSS).
3. Le chiavi sono accanto ai dati.
Non puoi. Le chiavi sono in KMS/HSM, accesso ai ruoli, minimo privilegi, account separati.
4. Nessuna rotazione/versione.
Versionate sempre le chiavi, memorizzate'key _ version'nei metadati del cifrotesto.
5. La TLS è solo nel perimetro.
Cifrare oltre CDN/WAF e all'interno del piano di data (servis→servis, webhoop).
6. Tornizzazione per la vista.
Se detokenize può qualsiasi servizio non è una protezione. Limitate a un cerchio stretto e verificate le chiamate.
7. Backup/scarichi analitici non registrati.
Crittografia e occultamento devono essere estesi a backap, snapshot, vetrine BI, logi.
Assegno foglio di implementazione (brevemente)
Canale
TLS 1. 2/1. 3, PFS, mTLS per web e interni, HSTS, sicurezza-headers rigorosi.
Storage
Tornizzazione PAN, disattivazione dello storage CVV.
FLE/FPE per campi critici; TDE come livello base.
Chiavi
KMS + HSM, encryption (KEK/DEK), rotazione/versione, registri invariati.
Architettura
Hosted Fields/SDK PSP, minimizzazione della zona PCI.
Separare ruoli/reti, zero trust, segreti - solo attraverso il segreto manager.
Operazioni
Pentest/Red Team nel perimetro e nella logica aziendale.
Monitoraggio DLP/CTI, formazione del personale.
Runbook на compromise: revoke/rotate/notify.
Mini FAQ
Cosa c'è di meglio per PAN: crittografia o tornizzazione?
In vendita - Tornizzazione (minimizza scope). In vault, crittografia con HSM/KMS.
È necessario un certificato EV per il dominio di pagamento?
Non obbligatorio. Più importante è il profilo TLS corretto, il mTLS, le chiavi in HSM e la disciplina.
È possibile utilizzare 0-RTT in TLS 1. 3 per i pagamenti?
Per i GET idipotenti, sì. Per POST è meglio spegnere o limitare.
Come conservare gli ultimi 4 e BIN?
Separato dal PAN; non si tratta di dati sensibili quando si è isolati correttamente, ma attenersi al camuffamento nei loghi/BI.
La crittografia dei sistemi di pagamento non è un unico tumbler, ma un ecosistema: TLS/PFS nel canale, tornizzazione e/o FLE in archiviazione, gestione rigorosa delle chiavi tramite KMS + HSM, standard di settore (PCI DSS, EMV, 3-DS), rotazione e controllo. Questa architettura a più livelli rende molto improbabile la fuoriuscita dei dati sulle schede, semplifica il passaggio delle credenziali e, soprattutto, mantiene la fiducia delle banche, dei partner di pagamento e degli utenti.