Crittografia post-quantistica per prestatori di servizi di pagamento e PSP

Un prestatore di servizi di pagamento (PSP) può avviare fin d'ora la propria migrazione post-quantistica sulle componenti che controlla in autonomia: TLS sugli endpoint pubblici e rivolti ai partner, traffico interno tra servizi, amministrazione SSH e l'inventario crittografico che PCI DSS già richiede. Le componenti che dipendono da terzi, cioè le specifiche dei circuiti di carte, la crittografia EMV per chip e contactless, i moduli di sicurezza hardware (HSM) e i terminali di pagamento, seguono i tempi dei rispettivi fornitori. Tutto il lavoro consiste nel separare i due ambiti: migrare ciò che è vostro, documentare ciò che non lo è e tenere entrambi in un unico inventario datato.

Perché lo scambio di chiavi viene prima

RSA, ECDSA, EdDSA, ECDH e Diffie-Hellman su campi finiti sono tutti violabili dall'algoritmo di Shor su un computer quantistico sufficientemente grande, qualunque sia la dimensione della chiave. Qui non viene indicata alcuna data credibile per una macchina del genere. Ciò che conta per i pagamenti è la natura del rischio, noto come harvest now, decrypt later (HNDL): il traffico catturato oggi è protetto soltanto dallo scambio di chiavi che ha generato la chiave di sessione, quindi un attaccante che lo registra può decifrarlo in seguito, quando quello scambio di chiavi diventerà violabile. Per una firma è diverso: falsificarla è utile solo finché la firma gode ancora di fiducia.

Per questo lo scambio di chiavi ibrido viene prima e le firme seguono. Per un PSP il traffico registrato è concreto: messaggi di autorizzazione, chiamate alle API di tokenizzazione, file di regolamento e riconciliazione, trasferimenti batch verso acquirer e processor, e sessioni amministrative nell'ambiente dei dati dei titolari di carta. Il nostro articolo su harvest now, decrypt later espone il ragionamento in dettaglio. Un gruppo ibrido combina uno scambio di chiavi classico con ML-KEM (Module Lattice Key Encapsulation Mechanism), pubblicato dal NIST come FIPS 203 il 13 agosto 2024, in modo che la sessione resti almeno robusta quanto oggi anche se uno dei due componenti dovesse cedere.

Cosa può migrare ora un PSP

• Endpoint HTTPS pubblici: pagine di pagamento ospitate, script di checkout, dashboard per i merchant, ricevitori di webhook e API pubbliche. Il gruppo ibrido X25519MLKEM768 (codepoint IANA 0x11EC, si veda il registro dei parametri TLS) è proposto di default dalle versioni attuali di Chrome, Edge e Firefox, e i client che non lo supportano negoziano invece il gruppo classico.
• TLS tra servizi all'interno dell'ambiente dei dati dei titolari di carta, dove controllate entrambe le estremità e potete aggiornare le librerie secondo i vostri tempi.
• Amministrazione SSH: OpenSSH 9.9 (19 settembre 2024) ha introdotto mlkem768x25519-sha256, OpenSSH 10.0 (9 aprile 2025) lo ha reso l'accordo di chiave predefinito e OpenSSH 10.1 (6 ottobre 2025) emette un avviso quando una connessione negozia un accordo di chiave non post-quantistico. Si vedano le note di rilascio di OpenSSH.
• Residui pre-standard: un eventuale gruppo X25519Kyber768Draft00 ancora presente (codepoint 0x6399) è obsoleto e andrebbe sostituito dai gruppi ML-KEM.
• L'inventario stesso, che è un esercizio di documentazione più che un progetto crittografico, ed è il deliverable che un assessor chiederà di norma per primo.

Verificate cosa negozia oggi un endpoint prima di modificare qualsiasi cosa. Per i gruppi ML-KEM è necessario OpenSSL 3.5 o successivo:

openssl version
openssl s_client -connect api.example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 | grep -i negotiated

Su nginx compilato con OpenSSL 3.5 o successivo, il gruppo ibrido si abilita elencandolo prima di quelli classici, il che mantiene attivo il fallback:

ssl_protocols TLSv1.3 TLSv1.2;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

I nomi delle direttive e dei gruppi supportati variano tra server e distribuzioni, quindi verificate sulla vostra build. Testate prima in staging, poi monitorate i tassi di errore dell'handshake e il supporto dei client dopo ogni modifica in produzione. La key share ibrida è più grande di quella classica, il che può avere un impatto sui collegamenti con risorse limitate e sui vecchi middlebox che ispezionano l'handshake. L'accordo di chiave ibrido per TLS 1.3 è specificato nella RFC 10024 (agosto 2026).

Cosa dipende da circuiti, fornitori di HSM e terminali

Le aree seguenti non sono una decisione del PSP. Qui non vengono indicate date post-quantistiche per esse, perché su questo sito si pubblicano solo fonti primarie datate, e i circuiti, EMVCo e i fornitori di HSM sono le uniche autorità sui propri piani.

• Crittografia EMV per chip e contactless, compresa l'autenticazione offline dei dati, che si basa su chiavi RSA e a curva ellittica fissate dalle specifiche.
• Interfacce di rete dei circuiti di carte e le gerarchie di chiavi che impongono ad acquirer e processor.
• Firmware degli HSM, configurazioni certificate e supporto PKCS#11 per ML-KEM e ML-DSA (Module Lattice Digital Signature Algorithm, FIPS 204).
• Formati dei key block e crittografia legata al PIN.
• Hardware dei terminali di pagamento, il cui ciclo di sostituzione si misura in anni.

Interpretazione, non requisito: assegnate a ciascuna di queste dipendenze una riga nell'inventario, con un responsabile interno, la posizione pubblicata dal fornitore se esiste e una data di revisione. Quando compare un bollettino di un circuito o una nota di rilascio di un HSM, quella riga cambia e la traccia mostra quando ne siete venuti a conoscenza. I questionari ai fornitori al rinnovo del contratto sono l'altra leva: chiedete una roadmap scritta invece di presumere che esista.

PCI DSS 12.3.3 è già la struttura portante

Il requisito 12.3.3 di PCI DSS v4.0.1 chiede che le cipher suite e i protocolli in uso siano documentati e riesaminati almeno una volta ogni 12 mesi. Si articola in tre parti: un inventario aggiornato che indichi lo scopo di ciascun algoritmo e dove viene utilizzato, il monitoraggio della perdurante validità di ciò che è in uso e una strategia documentata per rispondere ai cambiamenti previsti nelle vulnerabilità crittografiche. È obbligatorio dal 31 marzo 2025, dopo essere stato una best practice fino a quella data; lo standard è disponibile nella document library del PCI SSC. La nostra guida all'inventario crittografico PCI DSS 12.3.3 ne illustra la struttura, e la pagina di riferimento PCI DSS v4.0.1 riporta le scadenze datate.

Leggete con attenzione la terza parte. I cambiamenti previsti nelle vulnerabilità crittografiche sono la collocazione naturale del post-quantistico. Interpretazione: la vulnerabilità quantistica dello scambio di chiavi RSA e a curva ellittica è uno di questi cambiamenti previsti, quindi la strategia 12.3.3 di un PSP può indicare lo scambio di chiavi ibrido, specificare quali endpoint sono già migrati ed elencare le dipendenze da circuiti e HSM con i rispettivi responsabili. Il requisito 12.3.3 non impone ML-KEM oggi.

DORA: cosa richiede il testo alle entità finanziarie dell'UE

Il Regolamento delegato (EU) 2024/1774 della Commissione, ovvero le norme tecniche di regolamentazione sulla gestione dei rischi ICT ai sensi di DORA, si applica alle entità finanziarie dell'UE, compresi gli istituti di pagamento e gli istituti di moneta elettronica. L'Art. 6 richiede una politica in materia di cifratura e controlli crittografici che preveda disposizioni per l'aggiornamento o la modifica della tecnologia crittografica in base agli sviluppi della crittoanalisi. L'Art. 7 richiede la gestione delle chiavi lungo l'intero ciclo di vita e un registro dei certificati per gli asset ICT che supportano funzioni essenziali o importanti. Entrambi sono riassunti con le relative scadenze nella pagina di riferimento DORA.

Il testo non nomina alcun algoritmo e non fissa alcuna data post-quantistica. Interpretazione: l'Art. 6 è soddisfatto da una politica con un fattore di attivazione definito e un iter di approvazione per la modifica di un algoritmo, e l'Art. 7 da un registro dei certificati che già riporti algoritmo e dimensione della chiave, il che lo rende il luogo naturale per vedere cosa è ancora RSA o ECDSA. NIS2 Art. 21(2)(h) chiede politiche e procedure sull'uso della crittografia in termini analoghi, attraverso il recepimento nazionale. Questo articolo ha carattere informativo e non costituisce consulenza legale.

Dal requisito all'evidenza

Date ufficiali su cui pianificare

Nessuna di queste è specifica dei pagamenti, e nessuna costituisce una scadenza legale per un PSP salvo dove indicato nell'ultima colonna. Mantenete le cautele quando le citate internamente.

Iniziate dagli endpoint che potete vedere

Il primo passo utile più rapido è misurare cosa negoziano oggi i vostri endpoint di pagamento pubblici, per poi decidere l'ordine dei lavori: analizzate il vostro dominio con PQC Status per verificare il supporto di ML-KEM ibrido, le versioni TLS e la catena di certificati. Eseguite l'analisi separatamente sul dominio di checkout, sull'host delle API e sull'host dei webhook, poiché spesso si trovano dietro terminatori diversi. Registrate ogni risultato nell'inventario 12.3.3 con la relativa data, aggiungete le dipendenze da circuiti, HSM e terminali come righe aperte con i rispettivi responsabili e fissate il prossimo riesame entro dodici mesi al massimo.