La crittografia post-quantistica non richiede di aspettare l'arrivo di un computer quantistico capace di violare RSA. Il rischio harvest now, decrypt later riguarda i dati cifrati oggi e conservati per essere decifrati in futuro. Con .NET 11 RC2 Microsoft amplia le primitive crittografiche disponibili in C#, introducendo API sperimentali per Composite ML-KEM e HPKE. Per comprendere la portata del cambiamento occorre distinguere algoritmi, protocolli, formati di chiave e disponibilità effettiva delle implementazioni native.
1. Perché RSA ed ECC richiedono una transizione
RSA ed ECC basano la propria sicurezza computazionale su problemi matematici per i quali l'algoritmo quantistico di Shor, eseguito su hardware sufficientemente potente e affidabile, offre una minaccia sostanziale. Gli algoritmi simmetrici come AES non sono colpiti nello stesso modo: Grover comporta un vantaggio quadratico teorico nella ricerca esaustiva, non una rottura equivalente. Questo spiega perché la migrazione interessa soprattutto scambio di chiavi e firme digitali.
2. Il punto di partenza è .NET 10
.NET 10 ha introdotto le classi MLKem, MLDsa, SlhDsa e CompositeMLDsa in System.Security.Cryptography. ML-KEM è un meccanismo di incapsulamento di chiavi, standardizzato da NIST FIPS 203; ML-DSA e SLH-DSA sono schemi di firma, rispettivamente FIPS 204 e FIPS 205. Le classi e i metodi possono avere stati di maturità differenti: alcune API restano marcate [Experimental].
3. KEM non significa cifratura dei documenti
Un KEM produce un segreto condiviso tra mittente e destinatario. Il segreto alimenta normalmente una KDF, dalla quale si ricava una chiave per un algoritmo simmetrico autenticato come AES-GCM. Il KEM non è un sostituto diretto di AesGcm.
Recipient public key
|
v
KEM Encapsulate --------> Encapsulation ciphertext
|
v
Shared secret
|
v
Key derivation
|
v
AES-GCM ------------> Encrypted payload + authentication tag
Recipient private key + encapsulation ciphertext
|
v
KEM Decapsulate --> same shared secret4. Composite ML-KEM: il nuovo tassello di .NET 11
La RC2 introduce API sperimentali per combinare un meccanismo post-quantum ML-KEM con un meccanismo classico. L'obiettivo dei KEM compositi è ottenere una costruzione che mantenga proprietà di sicurezza anche qualora una delle componenti risulti vulnerabile, secondo le ipotesi e il combiner specificati. Non è corretto concatenare arbitrariamente due segreti e chiamare il risultato 'hybrid secure': il formato, il contesto e la derivazione devono essere definiti da una specifica interoperabile.
Il supporto dipende dalla piattaforma, dai parametri algoritmici e dallo stato delle API sperimentali. Prima di introdurle in un protocollo occorre fissare una versione, verificare gli algoritmi disponibili e testare interoperabilità e downgrade resistance.
5. HPKE: un framework, non un singolo algoritmo post-quantum
Hybrid Public Key Encryption (HPKE) è un framework di cifratura che combina KEM, KDF e AEAD. Il nome 'Hybrid' non significa automaticamente 'classico + post-quantum': HPKE può essere implementato con suite completamente classiche. Nella RC2 il supporto .NET è sperimentale e le suite post-quantum ML-KEM/ibride non risultano ancora implementate. È quindi scorretto presentare la sola presenza di Hpke come prova che un'applicazione utilizzi già cifratura post-quantum end-to-end.
6. Firme post-quantum e certificati
ML-DSA e SLH-DSA rispondono a un problema differente dal KEM: autenticità e integrità. La transizione interessa certificati X.509, CA, trust store, TLS, HSM, firme di software e documenti. Un certificato firmato con un nuovo algoritmo non diventa utilizzabile ovunque soltanto perché il runtime conosce la primitiva: il sistema operativo, la catena di fiducia, il peer e il protocollo devono supportarlo. Microsoft sta sperimentando ecosistemi PKI post-quantum in ambienti controllati, non con certificati pilota pubblicamente trusted.
7. Laboratorio 1: capability detection in C#
Il primo test riproducibile consiste nel verificare il supporto delle primitive già introdotte in .NET 10. È preferibile a un esempio che presupponga l'esistenza di algoritmi nativi su qualsiasi sistema.
using System;
using System.Security.Cryptography;
Console.WriteLine($"ML-KEM supported: {MLKem.IsSupported}");
Console.WriteLine($"ML-DSA supported: {MLDsa.IsSupported}");
Console.WriteLine($"SLH-DSA supported: {SlhDsa.IsSupported}");
if (!MLKem.IsSupported)
{
Console.Error.WriteLine("ML-KEM unavailable on this platform.");
return;
}
Console.WriteLine("ML-KEM available: ready for platform-specific tests.");Creazione del progetto: dotnet new console -f net11.0. Installare SDK .NET 11 RC2 e controllare la versione con dotnet --info. Su Linux il supporto dipende anche da OpenSSL (per le primitive .NET 10, Microsoft indica OpenSSL 3.5 o successivo). Non sopprimere indiscriminatamente i warning SYSLIB: sono indicatori di contratti ancora sperimentali.
8. Laboratorio 2: una firma ML-DSA in ambiente compatibile
La prova seguente mostra la struttura dell'API, da validare sulla piattaforma e sulla specifica build SDK utilizzata.
using System;
using System.Security.Cryptography;
using System.Text;
if (!MLDsa.IsSupported)
{
Console.WriteLine("ML-DSA not supported on this host.");
return;
}
byte[] message = Encoding.UTF8.GetBytes("Post-quantum signature test");
using MLDsa signer = MLDsa.GenerateKey(MLDsaAlgorithm.MLDsa65);
byte[] signature = signer.SignData(message);
bool valid = signer.VerifyData(message, signature);
Console.WriteLine($"Signature valid: {valid}");La firma non cifra il messaggio. In un'applicazione reale, verificare sempre la provenienza della chiave pubblica, il formato di esportazione, l'identità del firmatario e le policy di rotazione.
9. Architettura di un servizio di cifratura crypto-agile
Application API
|
v
Cryptography abstraction
|-- Algorithm policy / versioning
|-- Key management / KMS / HSM
|-- KEM + KDF
|-- AEAD encryption
|-- Signature validation
|-- Telemetry (never log secrets)
v
Versioned encrypted envelope
|-- suite identifier
|-- key identifier
|-- encapsulated key
|-- nonce
|-- ciphertext
|-- authentication tagUn envelope cifrato dovrebbe includere identificatori di versione e suite, e associare metadati critici come additional authenticated data (AAD). Le chiavi non devono essere registrate nei log. Il cambio di algoritmo deve essere governato da policy, non da un fallback silenzioso verso suite più deboli.
10. Minacce e verifiche indispensabili
Una migrazione richiede test di downgrade, manipolazione dei ciphertext, error handling indistinguibile quando necessario, controllo della memoria, zeroization, gestione delle chiavi e compatibilità con certificati e protocolli. Per la crittografia composita verificare esplicitamente il comportamento quando una delle componenti fallisce. Per HPKE verificare che le suite realmente negoziate soddisfino la policy richiesta.
11. Benchmark: misurare l'intero protocollo
Misurare soltanto il tempo di una firma o di un'incapsulazione è insufficiente. Servono throughput, latenza p50/p95/p99, allocazioni, dimensioni di chiavi e ciphertext, handshake TLS, dimensioni delle catene X.509, CPU e interoperabilità tra sistemi operativi. Confrontare i risultati su hardware e implementazioni native dichiarate, evitando di presentare misure locali come caratteristiche universali dell'algoritmo.
12. Strategia di migrazione enterprise
La prima fase è un inventario: TLS endpoint, certificati, CA, HSM, JWT, CMS, firme del codice, VPN, backup e archivi con confidenzialità di lungo periodo. Segue la classificazione dei dati in base alla durata della riservatezza. Poi vengono introdotti test di interoperabilità in ambienti non produttivi, telemetria sugli algoritmi negoziati e un piano di rotazione e rollback esplicito. La scelta di una nuova API .NET non rende automaticamente post-quantum l'intera infrastruttura.
13. Cosa cambia davvero con .NET 11 RC2
La novità è l'arrivo di API sperimentali per Composite ML-KEM e HPKE, che completano il percorso avviato con le primitive PQC di .NET 10. Composite ML-KEM riguarda il key establishment composito; HPKE fornisce un framework di cifratura, ma il supporto iniziale non equivale a suite post-quantum già disponibili. Per progettare un sistema sicuro occorre verificare build, piattaforma, algoritmi supportati, standard e interoperabilità.
14. Conclusioni
La post-quantum cryptography è soprattutto un problema di architettura e migrazione: protocolli, formati, certificati, chiavi e dipendenze infrastrutturali. .NET 11 mette a disposizione ulteriori strumenti, ma la proprietà più preziosa resta la crypto-agility: poter aggiornare gli algoritmi senza riscrivere l'intero sistema e senza compromettere le garanzie di sicurezza.
Nessun commento:
Posta un commento