Sintesi Tecnica: I Tre Assi del Rischio Quantistico

1. Definizione del Probleamento

La migrazione post-quantum è passata dalla fase di ricerca a quella di necessità operativa, spinta dalla finalizzazione dei FIPS 203/204/205 da parte del NIST e dalle scadenze CNSA 2.0 dell'NSA (2025–2033). Tuttavia, gli attuali strumenti di osservabilità crittografica soffrono di un limite critico: rispondono a una singola domanda per ogni asset: "Il suo primitivo è resistente al post-quantum (PQ)?".

Questo approccio a singolo asse non riesce a catturare l'intero profilo di rischio quantistico perché:

1. La protezione del canale viene ignorata: Due asset con algoritmi identici (es. ECDSA-P256) hanno profili di rischio molto diversi se uno opera su un collegamento non protetto e l'altro su un collegamento QKD (Quantum Key Distribution).
2. L'agilità crittografica è invisibile: Un asset che utilizza un algoritmo classico che può essere modificato tramite configurazione si trova in uno stato di rischio differente rispetto a uno in cui l'algoritmo è codificato in modo rigido nel firmware. Gli strumenti attuali non riportano l' "agilità di migrazione" come metrica di telemetria di prima classe.
3. Mancanza di un modello unificato: PQC (Crittografia Post-Quantum) e QKD sono spesso trattati come alternative mutuamente esclusive nella letteratura, mentre gli operatori necessitano di un modello unificato per valutare ambienti in cui le implementazioni ibride sono la realtà.

Di conseguenza, gli operatori non possono rispondere con precisione alla domanda "Possiamo essere pronti per il PQ in tempo?" perché mancano di una visione unificata di resistenza algoritmica, sicurezza del canale e velocità di migrazione.

2. Metodologia

Gli autori propongono un Modello di Postura del Rischio Quantistico a Tre Assi che tratta il rischio come un problema di osservazione multidimensionale. Ogni asset viene valutato su tre assi indipendenti, che vengono poi collassati in un unico punteggio regolato dalla scadenza, $q(asset, t)$.

I Tre Assi

• Asse A (Resistenza Algoritmica): Valuta i primitivi crittografici su una scala da [0, 1].
  • 1.0: PQ-resistente (es. ML-KEM, ML-DSA).
  • 0.9: PQ-ibrido (es. X25519 + ML-KEM).
  • 0.3: Classico (es. RSA-2048, ECDSA).
  • 0.0: Deprecato/Compromesso (es. SHA-1, RC4).
  • I punteggi sono ponderati per ruolo (firma, scambio chiavi, cifratura, hash).
• Asse C (Protezione del Canale): Valuta il meccanismo di consegna delle chiavi su una scala da [0, 1].
  • 1.0: Solo QKD.
  • 0.7: QKD-Hybrid PSK (chiavi derivate da QKD utilizzate in modalità ibride).
  • 0.0: Solo classico.
  • Questo asse tiene conto del degrado del collegamento (es. alto Quantum Bit Error Rate) scontando il punteggio proporzamente.
• Asse G (Agilità di Migrazione): Valuta la capacità di cambiare i primitivi su una scala da [0, 1].
  • 1.0 (Negoziazione): Algoritmo selezionato per sessione (es. TLS 1.3).
  • 0.75 (Configurabile): Modificabile tramite file di configurazione.
  • 0.50 (Vincolato/Pinned): Codificato nel codice sorgente, modificabile tramite aggiornamento software.
  • 0.20 (Bloccato): Fisso nel firmware o in moduli validati FIPS.
  • 0.0 (Congelato): Fisso nel silicio/ROM.

Il Punteggio Unificato

Il modello calcola un punteggio di rischio regolato dalla scadenza $q(asset, t)$:
$$q(asset, t) = 1 - (\alpha \cdot A + \beta \cdot C + \gamma(\tau) \cdot G)$$
Dove $\tau$ rappresenta la "tensione della scadenza" (quanto la data corrente $t$ è vicina alla scadenza $D$ dell'operatore). Man mano che la scadenza si avvicina, il peso $\gamma$ assegnato all'agilità diminuisce, riflettendo che un'alta agilità è meno tollerante quando il tempo è limitato. Un flag BLOCKED (Bloccato) viene attivato per gli asset con bassa agilità che non possono essere migrati in tempo, indipendentemente dal loro punteggio attuale.

Implementazione: Sezar

Gli autori hanno implementato Sezar, una piattaforma di osservabilità open-source scritta in Rust, per operazionalizzare questo modello. I componenti chiave includono:

• Estensione dello Schema: Estensione dello schema crypto_inventory_event v1 per includere i campi channel_protection e agility.
• Cinque Agenti:
  1. sezar-net: Osservazione TLS/SSH/IPsec basata su eBPF.
  2. sezar-qkd: Collettore ETSI GS QKD 014 e un emulatore KME sintetico per i test.
  3. sezar-agility: Scanner statico che utilizza regole Semgrep per analizzare il codice sorgente e i binari per i livelli di agilità.
  4. sezar-cert: Inventario X.509 tramite log CT e scansioni host.
  5. sezar-chain: Osservazione della blockchain pubblica.
• Motore di Rollup: Una funzione pura che ingerisce gli eventi e calcola il punteggio unificato in base ai pesi e alle scadenze configurati dall'operatore.

3. Contributi Chiave

1. Il Modello a Tre Assi: Un framework formale che separa la resistenza algoritmica, la protezione del canale e l'agilità di migrazione, riconoscendo che PQC e QKD sono osservabili complementari.
2. Estensione dello Schema: Un aggiornamento strettamente additivo allo schema crypto_inventory_event (v1.1) che abilita la telemetria interoperabile per QKD e agilità.
3. Implementazione di Riferimento Sezar: Uno stack completo e open-source (agenti, collettore, dashboard) che unifica l'osservabilità di rete eBPF, la telemetria QKD basata su REST e l'analisi statica del codice.
4. Emulatore QKD: Un emulatore di Key Management Entity (KME) conforme allo standard ETSI GS QKD 014, che permette ai professionisti di testare software consapevole del QKD senza l'hardware fisico.
5. Rubrica di Agilità e Corpus: Un sistema di punteggio ordinale a cinque livelli operazionalizzato tramite un pacchetto di regole Semgrep, validato contro un corpus di verità fondamentale (ground-truth) valutato manualmente su 50 progetti server open-source.

4. Risultati Empirici

Il documento valida il modello attraverso tre studi riproducibili:

• Studio 1 (Asse A - Tranco Top-1k):

  • Scansione di 724 host rispondenti dal top-1k di Tranco.
  • Risultato: Il 43,8% degli host ha negoziato uno scambio chiavi ibrido PQ (X25519MLKEM768) quando offerto. Tuttavia, il 16,9% negoziava ancora TLS 1.2 (strutturalmente inadatto al PQ) e la distribuzione delle firme dei certificati rimaneva dominante RSA (64,9%).
  • Insight: Le scansioni a singolo asse perdono i vincoli strutturali (versione TLS) e la mancanza di agilità dei certificati.

• Studio 2 (Asse C - Emulatore QKD):

  • Test del sistema contro 13 transizioni di stato indotte in cinque scenari di guasto (stato stazionario, degradazione, guasto critico, PSK obsoleta, SAE bifurcata).
  • Risultato: 13/13 cambiamenti di stato sono stati classificati correttamente. Il sistema ha distinto correttamente tra guasti a livello di collegamento e problemi di attribuzione per singola sessione (es. un SAE fallito mentre un altro ha successo).
  • Insight: La sola telemetria a livello di collegamento è insufficiente; è necessaria l'attribuzione per singola sessione per valutare accuratamente la protezione del canale.

• Studio 3 (Asse G - Pilota di Agilità):

  • Confronto dello scanner sezar-agility con la verità fondamentale valutata a mano per un sottoinsieme di 11 progetti del corpus di 50 progetti.
  • Risultato: 91% di accordo (10/11 progetti). L'unico disaccordo riguardava chrony, dove l'evidenza statica era ambigua tra "configurabile" e "vincolato".
  • Insight: L'analisi statica può raggiungere un accordo sostanziale con la valutazione umana, sebbene le lacune di copertura dell'ecosistema Go (inizialmente mancanti i pattern crypto/tls) abbiano richiesto aggiornamenti delle regole.

5. Significato e Rivendicazioni

Il documento sostiene che la metrica di prontezza PQ a "singolo bit" è insufficiente per gli operatori che affrontano le scadenze 2030–2033. La significatività di questo lavoro risiede in:

1. Valutazione del Rischio Olistica: Dimostra che il rischio di un asset non riguarda solo l'algoritmo utilizzato, ma anche come le chiavi vengono consegnate e quanto velocemente l'algoritmo può essere sostituito.
2. Fattibilità Operativa: Dimostra che un modello di osservabilità unificato che copra PQC, QKD e agilità può essere costruito utilizzando hardware comune e strumenti open-source, senza richiedere stack commerciali proprietari.
3. Prioritizzazione Azionabile: Riassumendo i tre assi in un punteggio regolato dalla scadenza, il modello consente agli operatori di dare priorità agli sforzi di migrazione basandosi su un realistico "tempo per risolvere" piuttosto che solo sulla "vulnerabilità attuale".
4. Riproducibilità: Gli autori forniscono l'intero schema, l'emulatore, i set di regole e il corpus di verità fondamentale, invitando la comunità a verificare, criticare e raffinare le costanti e i pesi del punteggio anziché accettarli come verità assolute.

Gli autori dichiarano esplicitamente che il modello non risolve i vincoli economici o politici della migrazione, ma fornisce lo strato di telemetria necessario per rendere tali decisioni informate. Il contributo è il modello e lo strumento, non i punteggi numerici specifici, che sono destinati ad essere configurabili dall'operatore.