Sintesi Tecnica: QSecureMail

Problematica

L'avvento del calcolo quantistico pone una minaccia fondamentale alla crittografia a chiave pubblica classica, rendendo gli attuali sistemi di posta elettronica vulnerabili agli attacchi di tipo "harvest-now-decrypt-later" (HNDL - raccogli ora, decripta dopo). Mentre la Distribuzione Quantistica delle Chiavi (QKD) offre una sicurezza informazionale e la Crittografia Post-Quantum (PQC) offre resilienza algoritmica, l'implementazione pratica affronta un collo di bottiglia critico: la gestione delle risorse. I sistemi QKD generano chiavi a ritmi limitati e variabili, mentre il traffico email è imprevedibile in termini di volume e dimensione. Le soluzioni esistenti spesso non riescono a colmare il divario tra i vincoli fisici dell'hardware quantistico e i requisiti dinamici dei sistemi di posta elettronica, portando a potenziali interruzioni del servizio o a un consumo inefficiente delle chiavi.

Metodologia

L'autore propone QSecureMail, un sistema client di posta elettronica progettato per operare su infrastrutture esistenti integrando QKD e PQC. Il sistema si basa su un'architettura a tre livelli: un frontend React/Vite, un backend Node.js/Express e un'infrastruttura di gestione delle chiavi (KM) conforme allo standard ETSI GS QKD 014.

Componenti Core

1. Adaptive Security Policy Engine (ASPE):
   L'ASPE funge da livello centrale decisionale, selezionando dinamicamente i livelli di cifratura in base alla "salute del pool" in tempo reale (il rapporto tra chiavi disponibili e dimensione totale del pool). Impiega un meccanimento di isteresi per prevenire rapide oscillazioni tra i livelli di sicurezza sotto condizioni di carico fluttuanti. L'engine monitora il tasso di invio delle email ($\lambda_{email}$) e i tassi di ripristino delle chiavi per calibrare le soglie, garantendo che il pool di chiavi non si esaurisca durante carichi di traffico elevati. Se il sistema KM diventa irraggiungibile, il sistema degrada con grazia verso una modalità AES-256-GCM classica (Livello 4).

2. Motore di Cifratura a Tre Livelli:
   Il sistema definisce tre distinti livelli di cifratura, bilanciando la garanzia di sicurezza rispetto al consumo di chiavi:

   • Livello 1 (QKD-OTP Autenticato): Utilizza un vero One-Time Pad (OTP) derivato dalle chiavi QKD per una segretezza perfetta, aumentato da un tag HMAC-SHA256 per l'integrità. Questo livello consuma $\lceil|m|/32\rceil + 1$ chiavi per messaggio, rendendolo altamente sicuro ma dispendioso in termini di risorse.
   • Livello 2 (AES-256-GCM assistito da Quantum): Utilizza una singola chiave QKD a 256 bit per derivare una chiave di sessione AES tramite HKDF-SHA256. Questo fornisce sicurezza computazionale seminata da casualità quantistica, consumando esattamente una chiave per ogni email indipendentemente dalla dimensione del payload.
   • Livello 3 (Ibrido QKD⊕PQC): Il contributo innovativo del documento. Questo schema fonde una chiave derivata da QKD ($k_{QKD}$) con un segreto condiviso da un'incapsulazione ML-KEM-1024 (FIPS 203) ($k_{PQC}$) utilizzando un'operazione bitwise XOR ($k_{fused} = k_{QKD} \oplus k_{PQC}$). La chiave fusa guida la cifratura AES-256-GCM. Questa costruzione assicura la sicurezza finché almeno uno dei due canali, QKD o PQC, rimane sicuro.

3. Attestazione di Sicurezza:
   Il sistema attacca un header MIME strutturato X-QSecureMail-Security-Profile a ogni messaggio. Questo header codifica il livello di cifratura, un frammento dell'identificatore della chiave, il timestamp e l'algoritmo, consentendo un auditing trasparente della postura di sicurezza senza richiedere la decifrazione.

Contributi Chiave

Il documento identifica quattro contributi primari:

1. Adaptive Security Policy Engine (ASPE): Un livello operativo che gestisce il compromesso tra sicurezza e disponibilità. Utilizza isteresi e calibrazione online per prevenire l'esaurimento del pool di chiavi preservando al contempo il Livello 1 (OTP) per i messaggi critici quando le risorse lo permettono.
2. Cifratura Ibrida QKD⊕PQC (Livello 3): Una costruzione formalizzata che combina ML-KEM-1024 con chiavi ETSI GS QKD 014. L'autore fornisce il Teorema 1, dimostrando che la chiave fusa è computazionalmente indistinguibile dall'uniformità se almeno una delle chiavi componenti è uniforme, offrendo una difesa in profondità contro sia i progressi matematici che gli attacchi ai canali fisici.
3. QKD-OTP Autenticato (Livello 1): Una costruzione che risolve la debolezza di malleabilità degli OTP classici autenticando i ciphertext con una chiave HMAC separata derivata da QKD.
4. Attestazione di Sicurezza Trasparente: Un meccanismo per registrare e auditare la postura di sicurezza quantistica dei singoli messaggi tramite header standard.

Risultati e Valutazione

L'autore ha implementato un sistema di riferimento e ha condotto valutazioni sulle prestazioni utilizzando un simulatore di KM in-process (simulando l'hardware QKD tramite API ETSI 014).

• Latenza:
  • Livello 1 (OTP): La latenza scala linearmente con la dimensione del payload a causa dei recuperi sequenziali delle chiavi. Per un messaggio da 100 KB, la latenza media è di 1,373 ms.
  • Livello 2 (QKD-AES): La latenza è bassa e scala minimamente con la dimensione (0,170 ms per 10 KB), poiché richiede un solo recupero di chiave.
  • Livello 3 (Ibrido): Introduce un overhead computazionale fisso dovuto all'incapsulamento ML-KEM-1024. La latenza media è di circa 2,2–2,7 ms attraverso tutte le dimensioni del payload (da 1 KB a 100 KB). Ciò conferma che lo schema ibrido aggiunge un costo fisso piuttosto che proporzionale.
• Consumo di Chiavi e Sostenibilità del Pool:
  • Il Livello 1 consuma circa 321 chiavi per un'email da 10 KB ($\kappa_1 \approx 321$), mentre i Livelli 2 e 3 consumano solo 1 chiave ($\kappa_{2,3} = 1$).
  • Le simulazioni mostrano che a un tasso di 100 email/ora, un pool di 1.000 chiavi si esaurisce in circa 1,87 minuti con il Livello 1, ma dura circa 10 ore con i Livelli 2 e 3. Questa differenza di 321 volte valida la necessità delle soglie adattive dell'ASPE.
• Correttezza: I test unitari hanno confermato la correttezza del round-trip, l'integrità del ciphertext (rilevamento manomissioni), l'isolamento delle chiavi (vincolo del destinatario) e l'indipendenza dei componenti QKD e PQC.

Significato e Rivendicazioni

Il documento sostiene che QSecureMail offre un approccio fattibile per il dispiegamento di email sicure dal punto di vista quantistico su infrastrutture esistenti senza richiedere modifiche ai protocolli di trasporto email sottostanti (SMTP/IMAP).

• Praticità: Disaccoppiando il confine dell'hardware quantistico (API ETSI 014) dalla logica applicativa, il sistema può integrare l'hardware QKD fisico man mano che diventa disponibile.
• Resistenza HNDL: L'uso di chiavi fresche derivate da QKD per ogni messaggio affronta direttamente la minaccia HNDL, garantendo che i ciphertext archiviati non possano essere decifrati in seguito, anche se l'avversario dovesse acquisire un computer quantistico.
• Difesa in Profondità: Lo schema ibrido di Livello 3 fornisce un robusto fallback; se l'algoritmo PQC viene violato, la componente QKD (nelle configurazioni hardware) mantiene la sicurezza, e viceversa.
• Continuità Operativa: L'ASPE assicura che il servizio di posta elettronica rimanga disponibile anche sotto carichi elevati o scarsità di chiavi, degradando dinamicamente verso livelli di cifratura meno dispendiosi in termini di risorse senza compromettere la sicurezza dei messaggi critici.

L'autore mantiene una posizione modesta, riconoscendo che l'attuale implementazione si basa su un simulatore di KM software e che il lavoro futuro dovrà affrontare l'integrazione con l'hardware QKD fisico, la distribuzione delle chiavi tra diverse istanze e la verifica formale del motore delle policy. Tuttavia, l'architettura dimostra che la transizione verso email sicure dal punto di vista quantistico è realizzabile utilizzando l'attuale hardware client commodity e interfacce standardizzate.