Crittografia e-mail: metodi, chiavi e modelli operativi

La domanda «Questa e-mail è crittografata?» è tecnicamente incompleta. Un messaggio può essere leggibile sul client, memorizzato come testo cifrato sul server di posta, decrittografato su un gateway, protetto tra due MTA tramite TLS e nuovamente archiviato non crittografato presso il destinatario. Una risposta attendibile indica quindi oggetto protetto, endpoint, titolari delle chiavi e punti in chiaro. NIST considera i meccanismi di trasporto, di dominio e di contenuto proprio per questo motivo come controlli cooperanti ma distinti (NIST SP 800-177 Rev. 1).

La crittografia del trasporto protegge una connessione. SMTP STARTTLS viene negoziato nuovamente per ogni hop e termina al rispettivo MTA. La crittografia del contenuto protegge un’entità MIME con S/MIME o OpenPGP e può sopravvivere a più hop di trasporto e archiviazione. Il fatto che funzioni davvero end-to-end non dipende solo dal formato: se un gateway aziendale decrittografa per conto degli utenti, gli endpoint crittografici si trovano nei gateway e non nei client utente (RFC 3207, RFC 8551, RFC 9580).

Una firma digitale è un’altra prestazione di sicurezza. Collega i dati a una chiave di firma privata e consente di verificare integrità e identità; non rende segreto il contenuto. Viceversa, un messaggio decrittografato correttamente non dice ancora chi lo abbia creato. In S/MIME vengono distinti CMS SignedData e EnvelopedData oppure AuthEnvelopedData. OpenPGP separa anch’esso i pacchetti di firma, chiave di sessione e dati crittografati (RFC 5652, RFC 8551, S/MIME Content Types, RFC 9580, Packet Syntax).

La spiegazione segue un messaggio e chiede a ogni hop dove sia presente il testo in chiaro e chi controlli le chiavi. Crittografia del trasporto, procedure end-to-end, gateway, portali, metadati, diagnostica e ripristino vengono confrontati su questa base.

La crittografia e-mail può proteggere l’hop di trasporto, il contenuto del messaggio o l’accesso a un portale. Questi modelli hanno titolari delle chiavi diversi e punti diversi in cui il testo è disponibile in chiaro. L’articolo segue quindi prima il percorso di protezione e solo successivamente i singoli prodotti e metodi.

Approccio architetturale: modelli di protezione e confini del testo in chiaro

La crittografia e-mail si differenzia soprattutto per i due punti che cifrano e decifrano. La tabella parte quindi dal normale percorso del messaggio e mostra poi dove il testo in chiaro rimane tecnicamente visibile.

Nessuno di questi modelli è genericamente «più forte». Il modello da client a client riduce i punti in chiaro nell’infrastruttura, ma rende più difficili il controllo antimalware, il journaling, l’eDiscovery e il ripristino. L’esempio pratico NCCoE esegue quindi la verifica S/MIME sul client utente con i relativi trust anchor, dopo che i controlli di trasporto e basati sul dominio sono terminati sull’MTA (NCCoE: DNS-Based Email Security). I gateway centralizzano policy e chiavi, ma diventano essi stessi punti altamente privilegiati per il testo in chiaro e le chiavi. I portali raggiungono destinatari senza crittografia della posta, ma creano un’ulteriore procedura web, di identità e di archiviazione. La scelta dipende dalla classificazione dei dati, dal modello di minaccia, dalla conservazione, dai requisiti legali e dalle capacità di entrambe le parti comunicanti, non dal nome del prodotto.

SMTP-TLS: protezione per hop di trasporto

SMTP è stato originariamente progettato senza riservatezza obbligatoria. STARTTLS estende una sessione SMTP esistente: dopo il completamento dell’handshake TLS, le capacità vengono nuovamente negoziate tramite EHLO. In modalità opportunistica, l’MTA mittente può ripiegare sul testo in chiaro in assenza di STARTTLS o in caso di errore del certificato. Ciò migliora la protezione contro l’intercettazione passiva, ma senza una policy aggiuntiva non fornisce una garanzia affidabile contro downgrade o un attaccante attivo (RFC 3207).

MTA-STS pubblica dapprima un’indicazione DNS TXT e recupera la policy effettiva tramite HTTPS. In modalità enforce i nomi MX indicati devono essere convalidati tramite PKIX; gli errori causano consegna ritardata anziché testo in chiaro. DANE per SMTP associa informazioni sui certificati o sulle chiavi a record TLSA convalidati tramite DNSSEC. REQUIRETLS è un contrassegno SMTP e di messaggio con cui un mittente richiede TLS per l’ulteriore trasmissione. Questi metodi hanno dipendenze e ambiti diversi e non devono essere riuniti in un’unica casella «TLS richiesto» (RFC 8461, RFC 7672, RFC 8689).

SMTP TLS Reporting, TLS-RPT, fornisce report aggregati sulle verifiche riuscite e fallite delle policy TLS. Non dimostra una singola consegna e non contiene alcun messaggio; aiuta a riconoscere errori di certificato, DNS e policy prima che le code crescano a lungo. NIST raccomanda ai domini riceventi di segnalare DANE, MTA-STS o entrambi e descrive le diverse dipendenze da DNSSEC, HTTPS e PKIX (RFC 8460, NIST SP 800-177 Rev. 1, sezione 5.2).

SMTP-TLS termina al server di posta successivo. Se il contenuto del messaggio deve rimanere protetto attraverso più hop, si utilizzano metodi basati sui messaggi quali S/MIME o OpenPGP.

S/MIME: CMS, X.509 e MIME

S/MIME non è una singola libreria di crittografia, ma una combinazione di più standard. MIME struttura le parti del messaggio; CMS definisce contenitori firmati e cifrati; X.509/PKIX associa le chiavi pubbliche alle identità e agli anchor di fiducia tramite certificati. Per ciascun destinatario, il mittente cifra la chiave simmetrica del contenuto con la relativa chiave pubblica o con un metodo concordato di gestione delle chiavi. Per la lettura è necessaria la chiave privata corrispondente (RFC 8551, RFC 5652, RFC 5280).

L’amministratore deve separare due ruoli di chiave. Una chiave di firma deve essere disponibile solo al firmatario; una copia centrale consentirebbe tecnicamente a terzi di creare nuove firme con la sua identità. Una chiave di decrittografia può essere protetta o sottoposta a escrow secondo la policy dell’organizzazione, affinché i vecchi messaggi aziendali restino leggibili dopo perdita del dispositivo, cambio di ruolo o rinnovo del certificato. RFC 8551 sottolinea esplicitamente che una persona può avere più coppie di chiavi attive per scopi diversi; NIST distingue la protezione e il ripristino per tipo di chiave (RFC 8551, Multiple Key Pairs, NIST SP 800-57 Part 1 Rev. 5).

Prima dell’invio, il mittente necessita di un certificato di crittografia idoneo e valido per ogni destinatario. La distribuzione può avvenire tramite una directory, messaggi firmati, una piattaforma di certificati o manualmente. Le liste di distribuzione sono particolarmente impegnative, poiché espansione, visibilità e disponibilità dei certificati di tutti i membri devono combaciare. Microsoft documenta per Exchange gli attributi userSMIMECertificate e userCertificate nonché la raccolta di certificati per la verifica della fiducia (Microsoft: S/MIME in Exchange Server, Microsoft: S/MIME in Exchange Online).

OpenPGP: il formato non è il modello di fiducia

RFC 9580 definisce pacchetti OpenPGP, chiavi, fingerprint, firme, chiavi di sessione e dati cifrati. Secondo lo standard, un portachiavi è soltanto una raccolta di chiavi; il modo in cui un’organizzazione trova le chiavi, verifica i proprietari e decide la fiducia è esterno a questo formato dati. Il diffuso storico Web of Trust è quindi una possibile modalità operativa, ma non una definizione sinonimica di OpenPGP. Altri ambienti utilizzano fingerprint verificati manualmente, chiavi firmate dall’organizzazione, WKD, servizi di directory o gateway gestiti centralmente (RFC 9580, keyring e fingerprint).

Per le e-mail, PGP/MIME incapsula firme e testo cifrato in strutture MIME. Inline-PGP protegge invece solo parti di testo selezionate e porta facilmente a problemi di interoperabilità con HTML, allegati, set di caratteri e canonicalizzazione delle righe. RFC 3156 standardizza multipart/encrypted e multipart/signed per OpenPGP. Occorre testare con le controparti reali se un client supporta pienamente le chiavi moderne RFC 9580, AEAD, le curve utilizzate e PGP/MIME (RFC 3156, RFC 9580).

Un Key ID breve non costituisce una prova d’identità sufficiente. RFC 9580 avverte che i Key ID non devono essere considerati univoci; per le verifiche si utilizza il fingerprint completo. Certificati di revoca, scadenza, subkey, nuovi fingerprint e la distribuzione sicura di una rotazione fanno quindi parte dello stesso ciclo di vita della prima emissione della chiave.

S/MIME e OpenPGP possono essere applicati sul dispositivo terminale o centralmente sul gateway. Il gateway semplifica policy e gestione delle chiavi, ma ottiene in cambio accesso al testo in chiaro.

Modello gateway: policy centrale e potere centrale sul testo in chiaro

Un gateway di posta accetta normali messaggi interni, classifica mittente, destinatario e dati, cerca chiavi S/MIME o OpenPGP appropriate e seleziona crittografia, firma, TLS o consegna tramite portale. In ingresso, se necessario, decrittografa prima del trasferimento al sistema di posta interno. Prodotti come SEPPmail, Totemomail oppure Kiteworks EPG e HIN utilizzano piattaforme diverse, ma la stessa fondamentale delega di fiducia: l’organizzazione delega la crittografia dall’endpoint dell’utente a un componente dell’infrastruttura (SEPPmail: prodotti, HIN Mail).

Ciò non risolve da sé la distribuzione delle chiavi. Il gateway necessita comunque di un’associazione comprovata tra l’identità del destinatario e la chiave pubblica, di una priorità tra più metodi, di regole per chiavi scadute o revocate e di un fallback definito. Lo scambio automatico di chiavi tra gateway può semplificare questi passaggi, ma è esso stesso un protocollo di fiducia con identità delle controparti, cache, scadenza e stati di errore.

L’ordine della policy decide quali controlli vedono il testo in chiaro. Se un gateway in ingresso decrittografa, antimalware, DLP e archiviazione possono operare successivamente. Se un gateway in uscita cifra troppo presto, gli scanner a valle sono ciechi. Se un gateway modifica un’entità MIME già firmata, la firma del contenuto o DKIM può diventare non valida. RFC 6376 rende gli header canonizzati e il body l’oggetto della firma; firma, crittografia, disclaimer, riscrittura e DKIM devono quindi essere ordinati in una pipeline documentata (RFC 6376).

Se presso il destinatario esterno non è disponibile una chiave adatta, un portale può memorizzare il messaggio e controllare l’accesso tramite autenticazione web. Il problema passa così dalla crittografia della posta all’identità web e all’esercizio della piattaforma.

Consegna tramite portale: applicazione web invece della chiave del destinatario

Con la consegna tramite portale, il destinatario riceve una normale e-mail di notifica e richiama il contenuto protetto tramite un’applicazione web. L’endpoint crittografico è il portale, non il client di posta del destinatario. Il compito tecnico si sposta quindi dalla distribuzione di chiavi pubbliche all’identità web, alla gestione delle sessioni, all’archivio di messaggi e allegati, al link di notifica, alla conservazione e al canale di risposta sicuro.

Come esempio concreto, HIN documenta la registrazione, il numero di cellulare e il codice SMS, nonché l’opzione di ricordare un dispositivo per accessi successivi. Questo esempio dimostra il modello operativo, non un’implementazione universale del portale. Altri prodotti utilizzano password, codice monouso tramite canale separato, identità federata o un accesso cliente già esistente (HIN: posta a non membri).

Per gli amministratori, un portale richiede almeno le seguenti evidenze:

• Quali dati sono contenuti nella notifica non protetta e nel token URL?
• Come vengono protetti registrazione iniziale, associazione dell’identità, tentativi falliti, memorizzazione del dispositivo e recupero dell’account?
• Dove risiedono messaggi, allegati, chiavi e dati di audit, e quando vengono eliminati?
• Un messaggio rimane recuperabile dopo scadenza, eliminazione dell’utente o cambio di tenant?
• Come vengono registrati risposta sicura, inoltro, download e conferma di lettura?
• Cosa accade se il portale non è raggiungibile, il servizio SMS è guasto o l’account del destinatario è compromesso?

Uno stato HTTP 200 dimostra solo che un’interfaccia web risponde. Un test sintetico del portale deve coprire notifica, registrazione o login, secondo fattore, apertura, allegato, risposta e il record di audit previsto.

Metadati, header e archiviazione

La crittografia del contenuto non protegge automaticamente l’envelope SMTP. Gli MTA che consegnano necessitano almeno degli indirizzi dei destinatari; i sistemi generano righe Received ed elaborano informazioni su dimensione e routing. Anche con S/MIME gli header esterni rimangono normalmente visibili. RFC 8551 consente di incapsulare un messaggio completo come message/rfc822 all’interno dell’entità MIME protetta, ma richiede una rappresentazione distinguibile degli header interni ed esterni. Il fatto che oggetto, visualizzazione del mittente ed elenco destinatari siano realmente protetti è una funzione del client e del gateway, non una conseguenza garantita dell’icona del lucchetto (RFC 5322, RFC 8551, Header Protection).

L’archiviazione deve stabilire quale rappresentazione viene conservata: testo in chiaro originale, entità originale firmata, originale cifrato, copia di lavoro decrittografata o oggetto del portale. Il solo testo in chiaro semplifica l’eDiscovery, ma perde la prova crittografica originale. Il solo testo cifrato può diventare illeggibile dopo la perdita della chiave. La convalida della firma in un momento successivo richiede byte originali, catena di certificati, informazioni di fiducia e revoca dell’epoca e una base temporale; un certificato oggi scaduto non rende automaticamente priva di valore una firma allora valida.

Ciclo di vita di chiavi e certificati

Un servizio crittografico produttivo necessita di un inventario che vada oltre le date di scadenza. NIST SP 800-57 tratta generazione, attivazione, protezione, inventario, distribuzione, utilizzo, rotazione, revoca, archivio, ripristino e distruzione come attività di gestione interconnesse (NIST SP 800-57 Part 1 Rev. 5).

La verifica del percorso S/MIME comprende anchor di fiducia, certificati intermedi, periodo di validità, nome o identità e-mail, Key Usage/Extended Key Usage, algoritmo e stato di revoca. OCSP e CRL sono a loro volta dipendenze di rete e cache. Con un soft-fail, una verifica rimane possibile nonostante informazioni di revoca non raggiungibili; con un hard-fail, un problema infrastrutturale può bloccare tutti i messaggi firmati o cifrati. Questa decisione deve far parte della policy e del monitoraggio (RFC 5280, RFC 6960).

La diagnostica inizia dal modello di protezione scelto: hop TLS, firma e crittografia del contenuto oppure accesso al portale. Solo successivamente si verificano certificato, chiave, policy e percorso di consegna.

Monitoraggio e analisi dei guasti

Il monitoraggio deve essere separato per modello di protezione. Per TLS di trasporto contano protocolli offerti e negoziati, errori di policy, validazione del certificato, TLS-RPT e anzianità della coda. Per S/MIME/OpenPGP contano chiavi del destinatario mancanti, percorsi o firme non validi, fallback, rotazione ed errori di decrittografia. Per i gateway si aggiungono decisione di policy, Message-ID, fingerprint della chiave, elaborazione del testo in chiaro e hop successivo. Per i portali, registrazione, MFA/OTP, archiviazione, scadenza dei link, login, apertura del messaggio e percorso di risposta sono segnali distinti.

Un protocollo d’incidente sensato risponde a:

1. Quale messaggio e quale percorso del destinatario sono interessati?
2. Quale modello di protezione e quale policy sono stati scelti?
3. Quale chiave pubblica o certificato è stato utilizzato, con quale fingerprint e stato?
4. Dove il messaggio è stato l’ultima volta leggibile, cifrato, memorizzato o in coda?
5. Il risultato è stato consegna, deposito sul portale, quarantena, fallback, retry o errore permanente?
6. Il risultato può essere riprodotto con un’identità di test controllata senza esporre dati di produzione?

Backup e ripristino

Dati cifrati e chiavi devono essere pianificati insieme, ma con misure di protezione separate. Un backup di messaggi cifrati senza le chiavi private di decrittografia necessarie a lungo termine può essere correttamente protetto ma comunque non recuperabile dal punto di vista operativo. Viceversa, un backup di key escrow insufficientemente protetto trasforma molti segreti individuali in un punto di attacco centrale. NIST tratta l’uso consentito di chiavi private recuperate in funzione del tipo di chiave e del periodo crittografico (NIST SP 800-57 Part 1 Rev. 5, PDF).

L’ambito minimo di ripristino comprende:

• messaggi originali cifrati ed eventualmente entità MIME firmate con valore probatorio;
• chiavi private di decrittografia con metadati, passphrase, ruoli e procedure di approvazione;
• chiavi pubbliche, catene di certificati, trust anchor, dati di revoca e convalida storica;
• policy di gateway e portale, routing, associazione delle chiavi, dati utente e oggetti messaggio;
• fonti di audit e temporali affinché le decisioni precedenti restino tracciabili;
• un test di ripristino con chiavi vecchie e nuove, più destinatari, allegati e verifica della firma.

Le chiavi private di firma non dovrebbero essere copiate come meccanismo generale di ripristino. Se un’organizzazione deve firmare automaticamente o per delega, un’identità organizzativa esplicita con una propria policy è preferibile alla copia inosservata di una chiave personale. Altrimenti, capacità di ripristino e non ripudio entrano in conflitto.

Strumenti diagnostici

La ricerca degli errori segue il modello di protezione scelto. Per la crittografia del trasporto vengono verificati DNS e TLS; per le procedure end-to-end seguono certificati, chiavi ed elaborazione client; per i gateway si aggiungono il relativo stato di policy e coda.

MTA-STS, TLS-RPT e DANE nel DNS

Resolve-DnsName -Type TXT _mta-sts.example.ch
Resolve-DnsName -Type TXT _smtp._tls.example.ch
Resolve-DnsName -Type TLSA _25._tcp.mx.example.ch

dig +short TXT _mta-sts.example.ch
dig +short TXT _smtp._tls.example.ch
dig +dnssec TLSA _25._tcp.mx.example.ch

Resolve-DnsName e dig mostrano le policy di trasporto pubblicate. Per DANE deve inoltre essere dimostrato lo stato di validazione DNSSEC; un testo TLSA semplicemente visibile non è ancora un record autenticato.

STARTTLS e catena di certificati

Test-NetConnection mx.example.ch -Port 25 -InformationLevel Detailed
curl.exe --verbose --ssl-reqd smtp://mx.example.ch:25

nc -vz mx.example.ch 25
openssl s_client -starttls smtp -connect mx.example.ch:25 \
  -servername mx.example.ch -showcerts

Test-NetConnection e nc verificano il percorso TCP. curl e openssl s_client mostrano STARTTLS, handshake e catena. Se un MTA di produzione effettua fallback o accoda in caso di errori risulta solo dalla sua policy e dai log.

Certificato S/MIME e finalità d’uso

certutil.exe -dump .\recipient-smime.cer
certutil.exe -verify -urlfetch .\recipient-smime.cer

openssl x509 -in recipient-smime.pem -noout \
  -subject -issuer -serial -fingerprint -dates -purpose -ext keyUsage -ext extendedKeyUsage
openssl verify -show_chain -CAfile trust-chain.pem recipient-smime.pem

certutil e openssl x509 mostrano identità, fingerprint, validità e finalità d’uso; openssl verify verifica un truststore indicato. Il test deve essere ripetuto con gli stessi trust anchor e le stesse regole di revoca del client o gateway di produzione.

Fingerprint OpenPGP e struttura della chiave

gpg.exe --show-keys --with-fingerprint --with-subkey-fingerprint .\recipient.asc
gpg.exe --list-packets .\message.pgp

gpg --show-keys --with-fingerprint --with-subkey-fingerprint recipient.asc
gpg --list-packets message.pgp

gpg mostra fingerprint completi, subkey, capacità e struttura dei pacchetti. --list-packets analizza solo il formato; non conferma né proprietario né fiducia. I fingerprint devono essere verificati tramite un secondo canale autenticato o una procedura organizzativa definita.

Percorso del portale e cattura dei pacchetti

Invoke-WebRequest -Method Head -Uri https://securemail.example.ch/
pktmon filter remove
pktmon filter add SecureMail -p 25
pktmon start --capture --pkt-size 0 --file-name securemail.etl
pktmon stop

curl --head --verbose https://securemail.example.ch/
tcpdump -ni any -s 0 -w securemail.pcap 'tcp port 25 or tcp port 443'

Invoke-WebRequest e curl verificano solo la raggiungibilità HTTP/TLS. pktmon e tcpdump acquisiscono solo nel punto di misurazione scelto. I dati dei pacchetti possono contenere testo SMTP in chiaro, indirizzi e metadati del portale e devono essere protetti di conseguenza.

Storia tecnica

PEM, Privacy Enhanced Mail, standardizzò all’inizio degli anni 1990 la posta Internet protetta crittograficamente, ma non raggiunse un’ampia interoperabilità. S/MIME combinò successivamente la struttura CMS derivata da PKCS con MIME e X.509. Gli standard S/MIME si sono evoluti attraverso più generazioni fino alla versione 4.0 pubblicata nel 2019; CMS stesso è standardizzato in RFC 5652 (RFC 1421, RFC 8551, RFC 5652).

OpenPGP nacque dal formato di pacchetti PGP e fu inizialmente standardizzato in RFC 2440, poi in RFC 4880. RFC 9580 ha sostituito RFC 4880 nel 2024 e ha modernizzato, tra l’altro, versioni delle chiavi, fingerprint e procedure per la crittografia autenticata. PGP/MIME secondo RFC 3156 rimane l’incapsulamento e-mail; l’evoluzione del formato non elimina tuttavia il compito organizzativo di regolare identità delle chiavi e ripristino (RFC 9580, RFC 3156).

SMTP STARTTLS è stato standardizzato nel 1999 in RFC 2487 e aggiornato nel 2002 da RFC 3207. DANE per SMTP, MTA-STS, TLS-RPT e REQUIRETLS hanno successivamente aggiunto livelli di policy e reporting contro downgrade e configurazioni errate. Parallelamente, le aziende hanno introdotto gateway e portali web perché i destinatari esterni non dispongono in modo affidabile di chiavi S/MIME o OpenPGP compatibili. La crittografia e-mail è così diventata meno una singola funzionalità client e più un sistema distribuito composto da SMTP, DNS, HTTPS, PKI, directory, policy, identità web e ripristino (RFC 7672, RFC 8461, RFC 8460, RFC 8689).

Fonti

• NIST – SP 800-177 Rev. 1, Trustworthy Email
• IETF RFC 3207 – SMTP Service Extension for Secure SMTP over TLS
• IETF RFC 8551 – S/MIME 4.0 Message Specification
• IETF RFC 9580 – OpenPGP
• IETF RFC 5652 – Cryptographic Message Syntax
• NCCoE – DNS-Based Email Security Practice Guide
• IETF RFC 8461 – SMTP MTA Strict Transport Security
• IETF RFC 7672 – SMTP Security via DANE
• IETF RFC 8689 – SMTP REQUIRETLS
• IETF RFC 8460 – SMTP TLS Reporting
• NIST – SP 800-177 Rev. 1, PDF
• IETF RFC 5280 – Internet X.509 PKI Certificate and CRL Profile
• NIST – SP 800-57 Part 1 Rev. 5
• Microsoft Learn – S/MIME in Exchange Server
• Microsoft Learn – S/MIME in Exchange Online
• IETF RFC 3156 – MIME Security with OpenPGP
• SEPPmail – prodotti
• HIN – HIN Mail
• IETF RFC 6376 – DomainKeys Identified Mail
• HIN Support – posta a non membri
• IETF RFC 5322 – Internet Message Format
• IETF RFC 6960 – Online Certificate Status Protocol
• NIST – SP 800-57 Part 1 Rev. 5, PDF
• Microsoft Learn – Resolve-DnsName
• ISC BIND 9 – pagina man di dig
• Microsoft Learn – Test-NetConnection
• OpenBSD – pagina man di nc
• curl – pagina man della riga di comando
• OpenSSL – s_client
• Microsoft Learn – certutil
• OpenSSL – x509
• OpenSSL – verify
• GnuPG – manuale gpg
• Microsoft Learn – Invoke-WebRequest
• Microsoft Learn – pktmon
• tcpdump – pagina del manuale
• IETF RFC 1421 – Privacy Enhancement for Internet Electronic Mail