Crittografia secondo ACN: guida a TLS, firme digitali, password, hash e cifratura sicura

La crittografia non è più una funzione tecnica nascosta nelle librerie software. È diventata una componente di governance, resilienza, compliance e continuità operativa. Le Linee Guida Funzioni Crittografiche pubblicate da ACN nel 2026 spostano il tema da una domanda generica, “i dati sono cifrati?”, a una domanda molto più scomoda: la cifratura usata è ancora adeguata al rischio, al ciclo di vita del dato e alle minacce attuali? È una differenza decisiva. Dire che un sistema usa crittografia non basta. Bisogna sapere quale protocollo TLS protegge il traffico, quali algoritmi firmano certificati e software, come vengono conservate le password, quali funzioni hash sono ancora in uso, se la cifratura garantisce anche integrità e autenticazione, se gli asset critici possono migrare verso primitive post-quantum e se i fornitori sono davvero pronti a sostenere questa transizione. Il punto forte delle linee ACN è proprio questo: non trattano la crittografia come un elenco di algoritmi, ma come una disciplina applicativa. Ogni raccomandazione deve essere valutata nel contesto reale, validata dai responsabili della sicurezza e tradotta in scelte concrete su applicazioni, reti, dispositivi, servizi cloud, firmware, password store, HSM, KMS, PKI e sistemi industriali. Per Matrice Digitale, questo pillar va letto insieme alla guida sulla crittografia post-quantum, ma non coincide con essa. Il post-quantum è una parte della questione. La guida ACN alla crittografia sicura è più ampia: riguarda anche il modo in cui oggi si proteggono traffico, identità, archivi, firme, credenziali e dati a lungo termine.

Che cosa sono le Linee Guida Funzioni Crittografiche di ACN

Le Linee Guida Funzioni Crittografiche sono una serie di documenti tecnici con cui l’Agenzia per la Cybersicurezza Nazionale indica primitive, parametri e configurazioni considerate sicure nei principali ambiti applicativi della crittografia moderna. La serie copre l’introduzione generale alla crittografia, il Transport Layer Security, le firme digitali, la cifratura autenticata, i cifrari a blocchi, i cifrari a flusso, le funzioni hash, la conservazione delle password e l’autenticazione. Il loro pubblico non è formato solo da crittografi. I documenti sono pensati per sviluppatori, produttori di dispositivi, fornitori di servizi digitali, security manager, responsabili cybersecurity, pubbliche amministrazioni e organizzazioni private che devono verificare se i sistemi in uso adottano funzioni crittografiche ancora robuste. ACN chiarisce un aspetto importante: nessuna raccomandazione può essere copiata meccanicamente dentro ogni ambiente.

La pertinenza delle soluzioni deve essere valutata e validata dai responsabili della sicurezza dei sistemi informativi. Questo passaggio è essenziale, perché una crittografia forte sulla carta può fallire se viene integrata male, se rompe la compatibilità, se non è supportata dai dispositivi, se usa parametri sbagliati o se dipende da fornitori senza roadmap. Il collegamento con la legge 90/2024 rafforza il peso operativo del tema. Le organizzazioni coinvolte devono verificare che programmi e applicazioni che usano crittografia rispettino le linee guida ACN e non espongano i dati cifrati a vulnerabilità note. In pratica, la crittografia diventa un oggetto di verifica tecnica e organizzativa, non un dettaglio lasciato al singolo vendor.

La regola di fondo: non basta cifrare, bisogna cifrare bene

Il messaggio trasversale dei documenti ACN è semplice: la crittografia moderna deve garantire confidenzialità, integrità, autenticazione e aggiornabilità. Una cifratura che protegge solo la riservatezza ma non impedisce alterazioni controllate del dato può essere insufficiente. Un hash obsoleto può compromettere firme, controlli di integrità e catene di fiducia.

Una password salvata con parametri deboli può trasformare un data breach in una compromissione di massa. Un certificato firmato con schemi classici può diventare un problema nel lungo periodo se il sistema non è pronto alla migrazione post-quantum. Per questo le Linee Guida ACN non vanno lette come una tabella da spuntare, ma come una mappa del rischio crittografico. La domanda da fare a ogni sistema è:

quale proprietà sto proteggendo? Confidenzialità? Integrità? Autenticazione? Non ripudio? Protezione della password? Trasporto sicuro? Conservazione di lungo periodo?

Ogni risposta porta a primitive diverse, parametri diversi e responsabilità diverse. È qui che nasce la distinzione più utile per aziende e PA:

• per i dati in transito, il tema centrale è TLS, la scelta delle suite crittografiche e la gestione dei downgrade;
• per i dati a riposo, contano AES, modalità corrette, storage cifrato e gestione delle chiavi;
• per dati trasmessi o manipolabili, serve cifratura autenticata, non semplice cifratura;
• per identità e software, contano firme digitali, certificati, PKI e supporto post-quantum;
• per credenziali, contano salt, password hashing e parametri resistenti;
• per integrità, contano funzioni hash non obsolete;
• per sistemi longevi, conta la capacità di migrare senza ricostruire tutto da zero.

Questa è la vera crypto-agility: non inseguire l’algoritmo del momento, ma costruire sistemi capaci di cambiare quando gli standard, gli attacchi e i requisiti evolvono.

TLS: perché ACN spinge verso TLS 1.3 e profili ibridi

Il Transport Layer Security è il punto più visibile della crittografia quotidiana. Protegge navigazione web, API, servizi aziendali, messaggistica, comunicazioni VoIP, accessi amministrativi e molte integrazioni tra sistemi. Per questo la configurazione TLS è uno dei primi elementi da auditare quando si parla di crittografia sicura. ACN considera obsolete le versioni SSL e TLS 1.0/1.1. Le versioni da considerare sono TLS 1.3 e TLS 1.2, con preferenza chiara per TLS 1.3 quando la compatibilità lo consente. Non è solo una questione di modernità: TLS 1.3 riduce superficie d’attacco, elimina molte opzioni storicamente problematiche e usa suite più pulite. La parte più interessante, però, è l’apertura ai profili ibridi post-quantum per lo scambio chiavi. Per ridurre il rischio Harvest Now, Decrypt Later, ACN raccomanda l’uso di schemi ibridi che combinano ML-KEM con ECDHE, come X25519MLKEM768, SecP256r1MLKEM768 e SecP384r1MLKEM1024.

Questo significa che la migrazione non viene immaginata come salto improvviso dal classico al post-quantum, ma come fase di convivenza controllata. La logica è corretta. TLS deve funzionare su ecosistemi eterogenei: browser, server, CDN, reverse proxy, appliance, API gateway, client legacy, mobile app, ambienti cloud e sistemi embedded. Passare a una configurazione più sicura senza rompere i servizi richiede test, inventario dei termination point, verifica delle librerie e controllo delle estensioni abilitate. ACN sconsiglia inoltre scelte rischiose come 0-RTT nei contesti sensibili, e richiama l’attenzione su estensioni e configurazioni che possono indebolire il livello di protezione. La lezione pratica è netta: l’audit TLS non deve limitarsi a controllare se un sito “ha HTTPS”. Deve verificare versione, suite, parametri di scambio chiavi, firme, estensioni, fallback e comportamento reale sotto compatibilità.

Firme digitali, certificati e PKI: il punto più delicato della transizione

Le firme digitali sono il cuore della fiducia digitale. Servono per certificati, software, documenti, firmware, transazioni, identità applicative e catene di autenticità. Quando una firma non è più adeguata, non si indebolisce un singolo file: si indebolisce il modo in cui un sistema decide cosa è autentico. Le Linee Guida ACN sulle firme digitali hanno un messaggio molto forte: gli schemi classici devono essere sostituiti al più presto con soluzioni post-quantum dove il contesto lo consente. Le firme classiche restano accettate come ponte o come componente di schemi ibridi, ma non rappresentano più l’orizzonte di lungo periodo. Per RSA, ACN indica una soglia minima di 3072 bit nelle configurazioni accettate. Per ECDSA ed EdDSA, il problema non è l’inadeguatezza immediata nel mondo classico, ma la vulnerabilità futura davanti a computer quantistici sufficientemente maturi. Il punto è lo stesso già affrontato nel pillar sulla crittografia post-quantum: non bisogna aspettare il cosiddetto Q-Day per accorgersi che una PKI non si migra in poche settimane. ACN raccomanda schemi post-quantum come SLH-DSA e ML-DSA ai livelli di sicurezza più alti, con attenzione ai compromessi tra dimensioni, prestazioni, gestione delle chiavi e componenti hardware. Qui il problema diventa molto concreto: HSM, smart card, secure element, servizi di firma remota, CA interne, pipeline di code signing e sistemi di verifica devono essere compatibili con nuove primitive e nuovi formati. Il rischio operativo non è astratto. Se una pipeline firmware non accetta firme più grandi, se un HSM non supporta nuovi algoritmi, se una CA interna non ha roadmap, se un parser X.509 legacy fa assunzioni sulle dimensioni, la migrazione post-quantum si blocca. Ecco perché il tema firme digitali va affrontato prima degli altri in settori regolati, infrastrutture critiche, software supply chain e ambienti industriali.

Cifratura autenticata: perché AES da solo non basta sempre

Una delle parti più importanti delle Linee Guida ACN riguarda la cifratura autenticata. Molti sistemi storici sono stati progettati con una visione riduttiva: cifrare significa rendere il dato illeggibile.

Ma in sicurezza moderna questo non basta. Bisogna anche sapere se il dato cifrato è stato modificato, se proviene dal contesto corretto e se il destinatario può verificarne l’integrità prima di usarlo. La cifratura autenticata, spesso indicata con AEAD, unisce confidenzialità, integrità e autenticazione dei dati. ACN raccomanda di preferirla alla sola cifratura ogni volta che il contesto lo consente. È la scelta già adottata dalle suite moderne di TLS 1.3, ed è il motivo per cui algoritmi come AES-GCM, AES-CCM e ChaCha20-Poly1305 sono centrali. La raccomandazione ha conseguenze pratiche. Se un’applicazione cifra dati ma non autentica il ciphertext, può essere vulnerabile a manipolazioni anche quando l’attaccante non conosce la chiave. Se usa IV o nonce in modo errato, può compromettere la sicurezza dell’intero schema.

Se tronca tag in modo aggressivo, riduce la resistenza alla contraffazione. Se combina cifratura e MAC in ordine sbagliato, può riaprire classi di attacco note. La regola editoriale da trasformare in policy è questa: quando un dato cifrato viaggia, viene salvato, copiato o riaperto da sistemi diversi, la cifratura autenticata deve essere la prima scelta. La cifratura “nuda” va trattata come eccezione da giustificare, non come default.

Cifrari a blocchi, cifrari a flusso e dati a riposo

Per i cifrari a blocchi, ACN indica AES come algoritmo raccomandato, con chiavi da 128, 192 o 256 bit. Nei casi che richiedono elevato periodo di conservazione del dato cifrato, la raccomandazione sale verso chiavi da 192 o 256 bit per mitigare il rischio di attacchi futuri, incluso lo scenario Harvest Now, Decrypt Later.

Questo passaggio è importante perché collega la scelta della chiave alla durata del dato. Un dato operativo che perde valore dopo pochi giorni non ha lo stesso profilo di un archivio sanitario, un segreto industriale, un backup legale, una chiave di firma o un dataset di ricerca. La crittografia corretta dipende anche dal tempo. ACN raccomanda inoltre modalità coerenti con il contesto. Per lo storage, la modalità XTS resta rilevante. Per gli altri casi, le modalità che non garantiscono autenticazione vanno trattate con cautela, perché possono risultare malleabili.

In generale, quando possibile, è preferibile una soluzione di cifratura autenticata. I cifrari a flusso hanno un ruolo più limitato. Possono essere utili in ambienti specifici e in scenari con vincoli prestazionali, ma ACN ricorda che garantiscono solo confidenzialità se usati da soli. In trasmissione, o quando serve protezione da manipolazioni, devono essere accompagnati da meccanismi che garantiscano autenticazione e integrità. Anche qui la regola è la stessa: evitare soluzioni fai-da-te, usare primitive standardizzate e rispettare le specifiche.

Hash: MD5 e SHA-1 non devono più stare nei sistemi moderni

Le funzioni hash sono ovunque: verifica dell’integrità, firme digitali, certificati, password hashing, deduplicazione, controlli software, log, catene di audit. Proprio perché sono così diffuse, la loro obsolescenza è spesso sottovalutata. ACN raccomanda l’uso delle famiglie SHA-2, SHA-3 e SHAKE nelle versioni adeguate. Al contrario, MD5 e SHA-1 sono considerati obsoleti e non consigliati per applicazioni moderne. Questo non significa che ogni presenza storica di SHA-1 generi automaticamente un incidente, ma significa che nessun nuovo sistema dovrebbe dipendere da quelle funzioni per proprietà di sicurezza.

Il problema degli hash obsoleti è subdolo: spesso restano dentro applicazioni legacy, script di controllo, pipeline di build, vecchi sistemi documentali, controlli di integrità o componenti di terze parti. Un audit serio deve quindi cercarli esplicitamente, non limitarsi a controllare i sistemi più recenti. La domanda da fare è: dove usiamo ancora MD5 o SHA-1? Perché? Il dato è solo un identificatore non di sicurezza o è parte di un processo di integrità, firma, autenticazione o verifica? Se è parte di una proprietà di sicurezza, va sostituito.

Password: il problema non è solo la complessità, ma la conservazione

Le password continuano a essere uno dei punti più fragili della sicurezza digitale. Anche quando un’organizzazione impone regole complesse agli utenti, può sbagliare la parte più importante: come conserva le password lato server. Le Linee Guida ACN sulla conservazione delle password sono molto pratiche. Il salt è obbligatorio per qualsiasi algoritmo di password hashing. Le soluzioni personalizzate sono da evitare. Gli algoritmi da privilegiare sono scrypt e soprattutto Argon2id, mentre PBKDF2 resta ammesso con parametri elevati. bcrypt viene trattato come scelta ormai datata e non raccomandata rispetto alle alternative più robuste.

Il messaggio per aziende e PA è diretto: un data breach non deve trasformarsi automaticamente in una lista di password recuperabili. La funzione di password hashing deve essere progettata per rendere costoso l’attacco offline, non solo per “trasformare” la password in una stringa diversa. Per questo l’audit delle password deve verificare almeno quattro cose: presenza di salt, algoritmo usato, parametri, capacità computazionale dell’ambiente. Argon2id va calibrato in modo che l’accesso normale resti sostenibile, ma l’esecuzione massiva da parte di un attaccante diventi costosa. È un equilibrio ingegneristico, non un valore magico.

Autenticazione e MAC: integrità e provenienza del messaggio

Nel mondo reale non basta proteggere il contenuto. Bisogna anche garantire che un messaggio non sia stato alterato e che provenga da chi condivide la chiave corretta. Qui entrano in gioco i MAC, cioè Message Authentication Code. Le linee ACN indicano HMAC, CMAC e GMAC come famiglie rilevanti, con chiavi di almeno 128 bit e tag normalmente non inferiori a 96 bit, salvo casi eccezionali. HMAC deve usare funzioni hash robuste; CMAC e GMAC devono appoggiarsi a cifrari sicuri, in pratica AES.

Questa parte è utile soprattutto per sviluppatori e architetti applicativi. Molte vulnerabilità nascono da protocolli interni costruiti male: token firmati con primitive deboli, messaggi cifrati senza autenticazione, tag troppo corti, chiavi riusate in contesti diversi, nonce gestiti male, MAC verificati dopo aver processato il contenuto. Le linee ACN servono a evitare proprio queste scorciatoie. Il principio operativo è: non inventare protocolli crittografici interni se esistono standard maturi. E se un protocollo custom è inevitabile, deve essere progettato, revisionato e testato da persone competenti.

Crittografia end-to-end: utile, ma non magica

La crittografia end-to-end è una delle espressioni più usate nel dibattito pubblico, ma spesso viene raccontata come una formula assoluta. In realtà E2EE significa che il contenuto viene cifrato in modo che solo gli endpoint legittimi possano leggerlo. È una proprietà forte, ma non risolve tutti i problemi. Le Linee Guida ACN aiutano a leggere l’end-to-end in modo più maturo. Una comunicazione E2EE può usare primitive robuste, ma resta vulnerabile se gli endpoint sono compromessi, se la gestione delle chiavi è fragile, se il backup rompe il modello di protezione, se l’autenticazione degli utenti è debole o se metadata e contesto operativo restano esposti. Per questo, in un ambiente aziendale o pubblico, la domanda non deve essere solo “questa app usa crittografia end-to-end?”. Deve diventare:

come vengono generate le chiavi? Dove vengono conservate? Come avviene la verifica dell’identità? Che cosa succede se un dispositivo viene perso? I backup sono cifrati con lo stesso livello? I metadati sono protetti? Il fornitore può modificare client, librerie o protocolli senza controllo?

La crittografia end-to-end resta fondamentale, soprattutto per messaggistica, collaborazione, archivi sensibili e comunicazioni ad alto rischio. Ma va inserita in un modello più ampio di autenticazione, gestione dispositivi, governance delle chiavi e controllo della supply chain.

Post-quantum: dove entra davvero nella guida ACN

Il post-quantum non è il solo tema delle linee ACN, ma ne è uno dei più strategici. La minaccia principale riguarda gli algoritmi asimmetrici classici, cioè le primitive usate per scambio chiavi e firme digitali. RSA, Diffie-Hellman ed ECC restano fondamentali oggi, ma sono vulnerabili in prospettiva a computer quantistici sufficientemente potenti. ACN risponde con due approcci complementari. Nel TLS raccomanda profili ibridi che combinano ML-KEM ed ECDHE per mitigare il rischio Harvest Now, Decrypt Later.

Nelle firme digitali raccomanda la transizione verso schemi post-quantum come ML-DSA e SLH-DSA, lasciando gli schemi classici come soluzioni accettate o ibride nella fase intermedia. Questa impostazione è più realistica di un semplice “sostituire tutto subito”. Le organizzazioni devono prima sapere dove usano crittografia asimmetrica, quali dati hanno lunga vita utile, quali sistemi non sono aggiornabili, quali fornitori supportano nuovi algoritmi e quali processi rischiano di rompersi con chiavi o firme più grandi. Il punto operativo è chiaro: la migrazione post-quantum non parte dall’acquisto di un prodotto. Parte dall’inventario crittografico.

Inventario crittografico: la misura che manca quasi ovunque

La maggior parte delle organizzazioni non sa davvero dove usa crittografia. Sa di avere HTTPS, VPN, certificati, password, firme, KMS, backup cifrati, ma non possiede una mappa completa di algoritmi, parametri, librerie, dipendenze, scadenze, vendor, chiavi e componenti legacy. Senza inventario, ogni roadmap crittografica è una promessa vaga. Non si può migrare ciò che non si conosce. Non si può valutare il rischio HNDL se non si sa quali dati hanno lunga vita utile. Non si può chiedere a un vendor supporto post-quantum se non si sa quali funzioni crittografiche quel vendor gestisce. Non si può dichiarare conformità se non si hanno evidenze.

Un inventario crittografico dovrebbe includere:

• versioni TLS, suite, certificati, endpoint e API gateway;
• PKI, CA interne, firme digitali, code signing e firmware signing;
• HSM, KMS, smart card, secure element e servizi di firma remota;
• librerie crittografiche usate da applicazioni e microservizi;
• database, storage, backup e modalità di cifratura dei dati a riposo;
• password store, algoritmi di hashing e parametri;
• funzioni hash usate in processi di integrità e verifica;
• sistemi IoT, OT, embedded e dispositivi non aggiornabili;
• fornitori critici e roadmap di supporto.

Questo inventario non deve restare un file statico. Deve diventare parte del ciclo di vita di sicurezza: procurement, sviluppo, deploy, vulnerability management, incident response e audit.

Roadmap operativa per aziende e PA

Una roadmap realistica ispirata alle linee ACN può essere costruita in sette fasi.

1. Censire gli usi crittografici

Il primo passo è mappare dove l’organizzazione usa TLS, certificati, firme, password hashing, hash, AES, AEAD, KMS, HSM, librerie e protocolli custom. La mappa deve coprire ambienti cloud, on-premise, applicazioni legacy, IoT, OT e supply chain software.

2. Eliminare obsolescenze evidenti

SSL, TLS 1.0/1.1, MD5, SHA-1 per scopi di sicurezza, RSA sotto soglia, password hashing debole e cifratura senza autenticazione dove non giustificata sono candidati immediati alla rimozione o alla sostituzione programmata.

3. Portare TLS verso configurazioni moderne

TLS 1.3 deve diventare il default dove possibile. TLS 1.2 può restare per compatibilità, ma con suite selezionate, estensioni corrette e controllo dei fallback. I profili ibridi ML-KEM vanno testati nei servizi ad alta esposizione e nei flussi con dati a lunga vita utile.

4. Rafforzare password, hash e cifratura dati

Argon2id o scrypt dovrebbero essere preferiti per password hashing. SHA-2, SHA-3 e SHAKE devono sostituire hash obsoleti. Per dati a lunga conservazione, AES-192/256 e modalità corrette diventano scelte più prudenti. Dove serve integrità, usare AEAD.

5. Preparare PKI e firme alla transizione post-quantum

CA interne, firme software, certificati, HSM, smart card, firma remota e firmware signing devono essere testati rispetto a ML-DSA, SLH-DSA e scenari ibridi. Il problema è spesso la compatibilità, non solo l’algoritmo.

6. Vincolare i fornitori

Ogni nuovo acquisto di appliance, servizi cloud, HSM, KMS, PKI, sistemi IoT, piattaforme documentali o strumenti di firma deve includere requisiti di crypto-agility, supporto a standard moderni, roadmap PQC, audit log, aggiornabilità e gestione sicura delle chiavi.

7. Riesaminare ogni anno

La crittografia non è una scelta una tantum. Gli standard cambiano, gli attacchi migliorano, le librerie vengono aggiornate, i vendor modificano roadmap. Una revisione annuale, integrata con audit e risk management, è il minimo per evitare di tornare rapidamente indietro.

Checklist ACN per un audit crittografico

Errori comuni da evitare

Il primo errore è confondere cifratura e sicurezza. Un’applicazione può cifrare dati e restare vulnerabile perché usa chiavi deboli, IV riutilizzati, hash obsoleti, password hashing inadeguato o protocolli custom.

Il secondo errore è pensare che la crittografia end-to-end risolva tutto. L’E2EE protegge il contenuto, ma non elimina rischi su endpoint, identità, backup, metadati e gestione delle chiavi.

Il terzo errore è delegare tutto al fornitore. Se un cloud provider, un vendor HSM o una piattaforma documentale non espone chiaramente algoritmi, parametri e roadmap, l’organizzazione non può dimostrare controllo reale.

Il quarto errore è trattare la post-quantum cryptography come problema futuro. I dati a lunga conservazione intercettati oggi possono diventare leggibili domani. La migrazione va pianificata prima che sia urgente.

Il quinto errore è lasciare la crittografia fuori dal procurement. Ogni nuovo acquisto tecnologico dovrebbe chiedere supporto a TLS moderno, gestione sicura delle chiavi, crypto-agility, aggiornabilità e roadmap post-quantum.

Il senso strategico delle linee ACN

Le Linee Guida ACN non chiedono alle aziende di diventare laboratori crittografici. Chiedono qualcosa di più concreto: smettere di trattare la crittografia come una scatola nera. Ogni organizzazione dovrebbe sapere quali algoritmi usa, quali sono accettati solo temporaneamente, quali sono obsoleti, quali proteggono dati a lungo termine, quali dipendono da fornitori esterni e quali non potranno essere aggiornati senza cambiare architettura. Questa è la vera maturità crittografica. Non il nome dell’algoritmo più recente, ma la capacità di governare il rischio nel tempo. ACN spinge esattamente in questa direzione: crittografia sicura by design, verificabile, aggiornata, validata e coerente con la minaccia reale. Nel 2026, la domanda non è più se un sistema usa crittografia. La domanda è se l’organizzazione è ancora in grado di fidarsi della crittografia che usa.

FAQ sulla crittografia secondo ACN

Fonti ACN utilizzate

• ACN, Introduzione alla Crittografia e alle Linee Guida, maggio 2026.
• ACN, Transport Layer Security (TLS), maggio 2026.
• ACN, Firme Digitali, maggio 2026.
• ACN, Cifratura Autenticata, maggio 2026.
• ACN, Cifrari a Blocchi e Modalità di Funzionamento, maggio 2026.
• ACN, Cifrari a Flusso, maggio 2026.
• ACN, Conservazione delle Password, maggio 2026.
• ACN, Funzioni di Hash, maggio 2026.
• ACN, Autenticazione, maggio 2026.