Crittografia post-quantistica per embedded e IoT: secure boot, TLS e OTA

La crittografia post-quantistica sta diventando una delle tecnologie più concrete per chi sviluppa sistemi embedded, gateway Linux e dispositivi IoT destinati a restare in campo per molti anni. Nel giro di pochi mesi sono arrivati i primi standard NIST finali, la roadmap europea di transizione, il supporto in OpenSSL 3.5 e i primi annunci embedded di vendor come STMicroelectronics. Questo significa che la PQC non è più solo un tema da laboratorio o da convegno: sta entrando nello stack reale di prodotti connessi, firmware aggiornabili, catene di trust e infrastrutture di sicurezza di lungo periodo.

La domanda importante non è solo “cos’è la crittografia post-quantistica?”. La domanda corretta per un team embedded è: se il mio dispositivo deve vivere 10, 15 o 20 anni, cosa succede a TLS, secure boot, OTA, certificati dispositivo e verifica delle firme quando gli algoritmi classici non sono più una base sufficiente nel lungo periodo?

Nei prodotti embedded il problema non riguarda soltanto la cifratura delle comunicazioni. Riguarda anche la catena di fiducia: il bootloader che verifica un’immagine firmata, il firmware che valida un pacchetto OTA, il gateway Linux che apre sessioni TLS verso il backend, la PKI di produzione, i certificati e i processi di manutenzione sul campo. Nel draft NIST IR 8547, NIST osserva esplicitamente che, se il codice che verifica le firme non è aggiornabile dopo la produzione, i dispositivi destinati a restare in uso a lungo dovrebbero essere progettati per richiedere firme resistenti al quantum.

Cos’è la crittografia post-quantistica

La crittografia post-quantistica, o PQC, è l’insieme di algoritmi pensati per resistere ad attacchi eseguiti con computer quantistici pur girando su hardware classico. Nel 2024 NIST ha pubblicato i primi tre standard principali della propria iniziativa post-quantum: FIPS 203 per ML-KEM, FIPS 204 per ML-DSA e FIPS 205 per SLH-DSA.

Per il mondo embedded i due nomi da ricordare subito sono ML-KEM e ML-DSA. ML-KEM, standardizzato in FIPS 203, è un key encapsulation mechanism pensato per stabilire un segreto condiviso su un canale pubblico. NIST specifica tre parameter set: ML-KEM-512, ML-KEM-768 e ML-KEM-1024, in ordine di sicurezza crescente e prestazioni decrescenti. In pratica è il candidato naturale per la parte di key establishment in protocolli come TLS.

ML-DSA, standardizzato in FIPS 204, è invece la famiglia di firme digitali lattice-based per generare e verificare firme. È il punto di contatto più naturale con secure boot, firmware signing, package signing, certificati e identità dispositivo. Nella documentazione OpenSSL su EVP_SIGNATURE-ML-DSA, le firme ML-DSA-44, ML-DSA-65 e ML-DSA-87 hanno dimensioni indicative nell’ordine di circa 2,5 KB fino a 4,5 KB: un dettaglio apparentemente piccolo, ma molto importante quando si parla di manifest OTA, header firmati e microcontrollori con flash limitata.

NIST continua a standardizzare algoritmi aggiuntivi di backup o alternativi, ma il messaggio ufficiale è molto chiaro: per la maggior parte dei deployment, i tre standard iniziali sono la base da cui partire. Non serve aspettare il “set perfetto”; serve cominciare a preparare i prodotti e a misurare gli impatti veri.

Perché la PQC è interessante per embedded e IoT

Nei sistemi embedded moderni la sicurezza non si esaurisce con un firewall, un certificato TLS o una firma RSA inserita in produzione. Un dispositivo connesso oggi può rimanere in campo per molti anni, subire aggiornamenti OTA, cambiare backend, essere integrato in impianti industriali o rientrare in cicli di supporto molto lunghi. Più lunga è la vita del prodotto, più diventa rischioso progettare la catena di fiducia assumendo che gli algoritmi classici resteranno adeguati per tutto il lifecycle.

L’urgenza non è solo teorica. La Commissione europea ha pubblicato nel 2025 una roadmap coordinata per la transizione alla crittografia post-quantistica. Nel relativo comunicato, l’UE indica che gli Stati membri dovrebbero iniziare la transizione entro la fine del 2026 e che la protezione delle infrastrutture critiche dovrebbe passare a PQC il prima possibile, entro fine 2030.

Questa urgenza si sente particolarmente nei protocolli di rete. NIST prevede di dare priorità alla migrazione verso schemi quantum-resistant di key establishment, soprattutto per proteggere da scenari “harvest now, decrypt later” in protocolli interattivi come TLS e IKE. Per chi progetta gateway Linux, edge computer, router custom o concentratori industriali, questo è un segnale molto concreto: la PQC entra prima di tutto nei canali dati e poi, subito dopo, nella catena di trust del firmware.

Il vantaggio principale: proteggere la catena di fiducia prima che diventi costosa da cambiare

In un flusso embedded tradizionale, molte scelte crittografiche vengono congelate prima di quanto si immagini: formato dei certificati, dimensione dei manifest, policy di firma, tool di build, struttura del bootloader, procedura di provisioning, secure element, backend PKI. Finché il prodotto è in laboratorio, cambiare è ancora possibile. Quando il dispositivo è in campo, ogni modifica diventa più delicata e più costosa.

Per questo la PQC non va vista come “la nuova crittografia da sostituire a ECC e RSA in blocco”, ma come un modo per introdurre crypto agility e proteggere in anticipo la parte più difficile da correggere dopo. Il punto non è rifare tutto domani. Il punto è evitare di progettare oggi un prodotto che fra pochi anni obbligherà a ripensare boot chain, update policy e PKI quando i vincoli saranno già cristallizzati sul campo.

Applicazioni pratiche della PQC nei sistemi embedded

Nel mondo embedded la PQC non è interessante se resta una spiegazione astratta. Diventa interessante quando entra in quattro aree molto concrete: TLS e networking, secure boot e firmware signing, OTA e package lifecycle, identità dispositivo e PKI.

TLS e networking per gateway Linux ed edge computer

Questo è il primo punto in cui la transizione è già visibile nel software reale. Le release notes di OpenSSL 3.5 indicano il supporto a ML-KEM, ML-DSA e SLH-DSA. Inoltre, la lista predefinita dei gruppi TLS è stata modificata per includere e preferire gruppi ibridi PQC KEM, e le keyshare di default sono passate a offrire X25519MLKEM768 e X25519.

Per chi lavora su gateway Linux embedded, questo significa che i test non devono più partire da fork sperimentali di anni fa: una parte della discussione è arrivata nel mainstream di una libreria fondamentale. La documentazione OpenSSL include anche pagine dedicate a EVP_PKEY-ML-KEM e EVP_PKEY-ML-DSA, utili per capire come vengono gestite chiavi, parametri e formati.

Gli approcci ibridi sono molto interessanti perché mostrano un percorso di transizione pratico: mantenere una componente classica e aggiungere resistenza post-quantum. Ma vanno trattati con attenzione. Una soluzione ibrida non è automaticamente più semplice: aumenta il numero di componenti, la complessità di test, l’interoperabilità da verificare e la superficie di errore.

Secure boot e firma firmware

Se c’è una sezione in cui la PQC parla direttamente al mondo embedded, è questa. La funzione di secure boot è costruita sulla capacità di verificare una firma affidabile prima di eseguire codice. Nel caso di dispositivi che resteranno in campo per molti anni, la domanda smette di essere “ci serve la PQC?” e diventa “quanto è rischioso bloccare la nostra catena di avvio su firme che in futuro potrebbero non essere più considerate adeguate?”.

ML-DSA è il candidato naturale per questa parte della catena di fiducia. Va però trattato come un tema di architettura, non solo di algoritmo: firme dell’ordine di qualche kilobyte possono impattare header, manifest, formati immagine, partizioni, recovery path e processi di validazione. Non è un motivo per fermarsi; è un motivo per iniziare a progettare e misurare con criterio.

OTA, package signing e lifecycle di prodotto

Nel flusso OTA la PQC non cambia soltanto l’algoritmo di firma. Può cambiare la dimensione degli artefatti, il modo in cui gestisci i metadati di aggiornamento, la policy di rollback, la compatibilità fra versioni e il budget di memoria riservato alla verifica. STMicroelectronics, nel suo annuncio del 2025 sulla PQC per embedded systems, collega esplicitamente i propri asset post-quantum a tre casi d’uso embedded molto chiari: firmware update, secure boot e authentication mechanisms.

Questo conferma che il punto di ingresso embedded della PQC non sarà solo il networking enterprise, ma anche il lifecycle del firmware. Per un prodotto connesso, OTA e secure boot non sono moduli separati: sono parti della stessa catena di fiducia.

Identità dispositivo, certificati e PKI

Un altro fronte pratico è la PKI. L’ecosistema Open Quantum Safe documenta strumenti per sperimentare key exchange e autenticazione post-quantum in TLS, oltre a integrazioni basate su provider OpenSSL. Per un team embedded questo è prezioso soprattutto in laboratorio e nella fase di prototipazione: permette di esercitare la parte più dolorosa della migrazione, cioè certificati, tool e interoperabilità, prima ancora di decidere il rollout finale sul prodotto.

PQC non è solo una tecnologia da datacenter

Uno degli equivoci più comuni è pensare che la PQC riguardi prima di tutto server, cloud e grandi appliance. In realtà la filiera embedded si sta muovendo con una certa concretezza. STMicroelectronics ha annunciato algoritmi post-quantum integrati in MCU general-purpose, secure microcontrollers e microcontrollori automotive, oltre a librerie software per sviluppatori STM32.

Anche dal lato memoria i trade-off sono reali. In test pubblicati da wolfSSL su piattaforme embedded, ML-KEM e ML-DSA mostrano profili diversi di stack e heap. I dati pubblicati in Optimizing Post-Quantum Algorithm Memory Usage on Embedded Systems evidenziano che ML-KEM tende ad avere un profilo più prevedibile, mentre ML-DSA può richiedere più attenzione, soprattutto per heap e configurazioni orientate a stack ridotto.

Il messaggio pratico è chiaro: il KEM è spesso la prima porta d’ingresso realistica della PQC su hardware stretto; le firme richiedono più attenzione a latenza, memoria e formati degli artefatti.

Architettura tipica di una soluzione PQC embedded

Una soluzione PQC embedded ben progettata non introduce un “algoritmo magico” in un punto solo. Divide invece il problema in blocchi: session establishment, firme, certificati, toolchain di build, provisioning e memory budgeting. La tabella seguente sintetizza i punti principali da valutare in un prodotto reale.

PQC e integrazione controllata in Linux embedded

Per un gateway Linux embedded, il percorso più professionale non è “accendiamo la PQC ovunque e vediamo cosa succede”. Il percorso corretto è una integrazione controllata in build e release process. OpenSSL 3.5 rende possibile iniziare da test reali sul target; gli strumenti Open Quantum Safe aiutano molto in laboratorio per interoperabilità TLS e X.509.

In produzione, però, conviene separare bene immagine di sviluppo, immagine di test e immagine di produzione, decidendo quali algoritmi e quali gruppi abilitare davvero. La stessa logica vale per firmware e boot chain: il punto non è solo “supportare ML-DSA”, ma decidere dove conservare chiavi e trust anchor, come versionare la policy di firma, come migrare il backend PKI e come gestire fallback o rollback senza creare una giungla di compatibilità impossibile da mantenere.

pqc_embedded_strategy:
  linux_gateway_dev:
    openssl_3_5_tested: true
    hybrid_tls_groups_evaluated: true
    oqs_lab_interop_used: true
    x509_pqc_test_chain_created: true

  firmware_and_boot:
    signature_verifier_path_mapped: true
    manifest_size_impact_checked: true
    trust_anchor_update_policy_defined: true
    rollback_compatibility_reviewed: true

  production_rollout:
    only_required_algorithms_enabled: true
    legacy_fallback_policy_defined: true
    stack_heap_flash_measured_on_target: true
    release_artifacts_versioned: true

Quando la PQC può creare valore in un prodotto embedded

La PQC crea valore soprattutto quando il prodotto è connesso, aggiornabile, con una vita sul campo lunga e una dipendenza reale da certificati, secure boot, OTA o protocolli sicuri. Più alto è il costo di intervenire fisicamente sul dispositivo o di riprogettare la boot chain in ritardo, più cresce il valore di affrontare il problema in anticipo.

È particolarmente sensata su gateway Linux, edge appliance, prodotti industriali installati presso clienti, dispositivi con update remoti e linee di prodotto che devono restare supportate per molto tempo. In queste classi di prodotto, la PQC non è solo sicurezza “in più”: è un modo per limitare il rischio di trovarsi con una chain of trust difficile da migrare quando il contesto normativo, tecnologico e di mercato si sarà già spostato.

Quando invece serve cautela

La PQC non è automaticamente la scelta giusta per ogni prodotto. Su dispositivi molto piccoli, con MCU estremamente vincolati, immagini minimali o tempi real-time aggressivi, l’impatto di memoria, latenza e complessità progettuale può superare il beneficio immediato. I benchmark e i dati pubblicati dai vendor mostrano che la fattibilità esiste, ma mostrano anche che le firme possono avere costi e variabilità che vanno presi sul serio.

Serve cautela anche con gli approcci ibridi. Possono essere utili come ponte di transizione, ma aumentano complessità, costi e rischi di implementazione. Il punto non è quindi “mettere PQC ovunque”, ma capire dove produce un vantaggio misurabile e dove invece conviene preparare il design, introdurre crypto agility e aspettare un livello di supporto più maturo.

Crittografia classica, ibrida e post-quantistica: differenze pratiche

La scelta giusta dipende dal ruolo del dispositivo. Oggi un gateway Linux può spesso partire dai test ibridi su TLS; un boot chain o un firmware signing flow possono invece richiedere una valutazione più prudente ma più profonda sulla parte firme e lifecycle.

Checklist tecnica per valutare la PQC su embedded e IoT

Prima di introdurre la PQC in un prodotto embedded, conviene fare un audit vero e proprio. L’obiettivo non è solo verificare se una libreria supporta ML-KEM o ML-DSA, ma capire se l’intera architettura può evolvere senza diventare fragile.

pqc_embedded_audit:
  lifecycle:
    expected_field_life_checked: true
    long_term_confidentiality_needs_checked: true
    non_updatable_signature_verifier_identified: true

  protocols:
    tls_or_vpn_usage_mapped: true
    device_authentication_paths_mapped: true
    certificates_and_pki_inventory_done: true

  firmware_chain:
    secure_boot_flow_reviewed: true
    ota_manifest_and_signature_format_reviewed: true
    rollback_and_recovery_paths_verified: true

  implementation:
    target_library_selected: true
    hybrid_transition_need_evaluated: true
    stack_heap_flash_measured_on_real_target: true
    latency_variance_measured: true

  operations:
    trust_anchor_rotation_plan_available: true
    crypto_agility_requirements_defined: true
    backend_compatibility_checked: true
    release_and_support_workflow_documented: true

Mini piano di adozione consigliato

La strategia migliore è quasi sempre graduale: inventario, proof of concept, misura sul target reale, integrazione controllata e solo dopo rollout. Questo rispecchia bene sia il tono delle linee guida NIST sia la maturità ancora disomogenea dell’ecosistema fra Linux embedded, librerie vendor e microcontrollori molto piccoli.

flowchart TD
    A["Inventario crittografico del prodotto"] --> B["TLS, VPN e canali sicuri"]
    A --> C["Secure boot e firmware signing"]
    A --> D["OTA, manifest e rollback"]
    A --> E["PKI, certificati e identità dispositivo"]

    B --> F["Valuta ML-KEM o gruppi ibridi"]
    C --> G["Valuta ML-DSA e formati firma"]
    D --> H["Misura impatto su artefatti e memoria"]
    E --> I["Verifica provisioning e trust anchors"]

    F --> L["Benchmark su target reale"]
    G --> L
    H --> L
    I --> L

    L --> M["Rollout controllato con crypto agility"]

Il diagramma sopra è una sintesi operativa del percorso più sano: prima mappare, poi sperimentare, poi misurare, poi distribuire. Non il contrario.

Il valore commerciale della PQC nei prodotti embedded

Per un’azienda che sviluppa dispositivi connessi, la PQC può diventare un vantaggio competitivo non perché “fa scena”, ma perché riduce il rischio di dover riprogettare tardi gli elementi più sensibili della fiducia digitale: boot chain, update path, PKI e protocolli sicuri. NIST ricorda che l’integrazione completa richiederà tempo; quindi chi inizia prima con audit e misure realistiche ha più margine per fare una transizione ordinata.

Dal lato europeo, il Cyber Resilience Act non prescrive ML-KEM o ML-DSA in modo specifico, ma impone un quadro in cui i produttori devono prendere sul serio la sicurezza del prodotto lungo tutto il lifecycle. In questo contesto, la capacità di aggiornare e far evolvere l’architettura crittografica del prodotto diventa molto più rilevante.

FAQ su PQC ed embedded

Serve cambiare tutto subito?

No. Le fonti ufficiali spingono a iniziare la transizione ora, ma non a sostituire ogni algoritmo in blocco domani mattina. La priorità è capire dove il rischio è più alto: TLS e canali con esigenze di confidenzialità di lungo periodo, code signing, secure boot, PKI e prodotti con vita sul campo molto lunga.

ML-KEM sostituisce ECDH?

Concettualmente è il riferimento naturale per il nuovo key establishment post-quantum, ma nel mondo reale la transizione passa spesso da soluzioni ibride o compatibilità graduale. OpenSSL 3.5 supporta già gruppi e keyshare ibridi, ma questi meccanismi vanno testati dentro protocolli e stack specifici, non copiati indiscriminatamente in ogni punto dell’architettura.

ML-DSA ha senso per secure boot e firma firmware?

Sì, è uno degli use case più naturali. La firma del firmware, dei manifest OTA e dei pacchetti software è una parte critica della catena di fiducia. Tuttavia, l’impatto su dimensione firme, tempi di verifica e formati immagine deve essere misurato su hardware reale.

La PQC è davvero fattibile su MCU?

Sì, ma con trade-off concreti. Le implementazioni embedded stanno maturando e alcuni vendor stanno già portando supporto PQC su microcontrollori e librerie dedicate. Il punto non è chiedersi se sia possibile in assoluto, ma se sia sostenibile sul target specifico in termini di stack, heap, flash, latenza e consumo.

Su Linux embedded posso fare test reali oggi?

Sì. OpenSSL 3.5 include supporto a ML-KEM, ML-DSA e SLH-DSA, mentre Open Quantum Safe rimane molto utile in laboratorio per prototipazione, interoperabilità TLS e test su certificati. Questo rende i gateway Linux embedded un punto di partenza naturale per PoC seri e misurabili.

Il Cyber Resilience Act richiede già PQC?

No, non prescrive algoritmi specifici di questo tipo. Però impone un quadro di sicurezza di prodotto e di lifecycle che rende più importante progettare sistemi aggiornabili, con fiducia digitale mantenibile e meno dipendenti da scelte crittografiche rigide.

Riferimenti tecnici utili

• NIST — Post-Quantum Cryptography Project
• NIST — First 3 Finalized Post-Quantum Encryption Standards
• NIST FIPS 203 — ML-KEM
• NIST FIPS 204 — ML-DSA
• NIST FIPS 205 — SLH-DSA
• NIST IR 8547 — Transition to Post-Quantum Cryptography Standards
• Commissione europea — Roadmap per la transizione alla PQC
• OpenSSL 3.5 — Release notes
• OpenSSL — EVP_PKEY-ML-KEM
• OpenSSL — EVP_PKEY-ML-DSA
• OpenSSL — EVP_SIGNATURE-ML-DSA
• Open Quantum Safe — TLS
• Open Quantum Safe — X.509
• STMicroelectronics — PQC per embedded systems
• wolfSSL — Optimizing PQC memory usage on embedded systems

Conclusione

La crittografia post-quantistica non è più un argomento da “tenere d’occhio più avanti”. Per i team che sviluppano gateway Linux, firmware aggiornabili, secure boot, OTA e prodotti destinati a vivere a lungo, è già un tema di architettura.

La mossa giusta non è cambiare tutto in modo impulsivo. La mossa giusta è capire dove il rischio è reale, introdurre crypto agility, provare gli stack disponibili, misurare memoria e latenza sul target, e preparare la catena di fiducia del prodotto prima che diventi troppo rigida da modificare.

Quando viene affrontata con metodo, la PQC non è una moda. Diventa parte della strategia con cui un prodotto embedded resta credibile, aggiornabile e difendibile nel tempo.