Suite di cifratura
Una suite di cifratura, denominata anche suite di crittografia o con il termine in inglese cipher suite è un insieme di algoritmi utilizzati per rendere sicuri i collegamenti di rete basati su Transport Layer Security (TLS) o sul suo predecessore, ora deprecato, Secure Socket Layer (SSL). L'insieme di algoritmi che costituisce una suite comprende tipicamente: un algoritmo per lo scambio delle chiavi crittografiche, un algoritmo di crittografia ed un algoritmo di message authentication code (MAC).[1]
L'algoritmo per lo scambio delle chiavi si usa per assicurare lo scambio corretto tra due dispositivi delle chiavi utilizzate dall'algoritmo di crittografia, che esegue l'operazione di criptare e decriptare i messaggi e i dati scambiati tra le macchine comunicanti. L'algoritmo di MAC infine realizza i controlli di integrità dei dati per assicurare che il messaggio non abbia subito modifiche durante la trasmissione. In aggiunta a questi, le suite di cifrature possono comprendere anche algoritmi di firma digitale e di autenticazione per garantire le identità del server e/o del client.
Esistono centinaia di suite di cifratura differenti, ciascuna contenente una combinazione diversa dei vari algoritmi; alcune di queste offrono un livello di sicurezza superiore rispetto ad altre.[2]
La struttura e l'impiego concettuale delle suite di cifratura sono descritti nel documento di riferimento dello standard TLS;[3] la versione più diffusa di questo protocollo è TLS 1.2. La successiva versione TLS 1.3 aggiunge ulteriori requisiti sulle suite di cifratura, ma essendo stata standardizzata solo ad agosto 2018[4] non è ancora molto diffusa. Le suite di cifratura definite per TLS 1.2 non sono in generale utilizzabili con TLS 1.3 (e viceversa), salvo diversa indicazione nella loro definizione.
Un elenco di riferimento di suite di cifratura è disponibile sul TLS Cipher Suite Registry.[5]
Storia
modificaL'impiego dei cifrari nel protocollo Secure Socket Layer (SSL), poi evoluto nel TLS, era previsto fin dall'inizio ma nella bozza originale non si faceva menzione delle suite di cifratura; la possibilità offerta a un client e a un server di scegliere il meccanismo di crittografia da un piccolo insieme di cifrari veniva indicata come Cipher-Choice.[6][7] Il termine cipher suite fu introdotto solo nel protocollo SSL v3 (la ultima versione).[8] Da allora tutte le versioni del TLS hanno utilizzato il termine Cipher Suite nei rispettivi standard di definizione. Il concetto e lo scopo della suite di cifratura non sono cambiati rispetto al momento dell'introduzione del termine: viene tuttora usato come una struttura che descrive gli algoritmi supportati da una macchina da cui scegliere quali utilizzare per rendere sicuro il collegamento con un'altra macchina; quelle che sono cambiate nel tempo sono le versioni degli algoritmi compresi nelle suite di cifratura. Ogni versione di TLS ha aggiunto il supporto per le versioni di algoritmi più robuste eliminando al contempo quelle versioni che erano state identificate come non più sicure.
La scelta della suite di cifratura viene determinata durante il processo iniziale di handshake. Il protocollo TLS 1.3 ha modificato tale processo in modo da ridurre il numero di messaggi da scambiare durante l'handshake, il che risulta in minore elaborazione, minor traffico di pacchetti e maggiore efficienza rispetto alle versioni precedenti del TLS.
Schema di nomenclatura
modificaOgni suite di cifratura viene identificata con un nome univoco che consente anche di descrivere da quali algoritmi è composta. Ogni porzione del nome rappresenta, in una sequenza ordinata, il nome di ciascuno degli algoritmi compresi nella suite. Un esempio di nome è: TLS_RSA_WITH_3DES_EDE_CBC_SHA256
Il significato di questo nome va letto in questo modo:
- TLS definisce il protocollo a cui la suite è destinata; in questo caso si tratta di TLS.
- RSA indica l'algoritmo di scambio delle chiavi utilizzato. Questo algoritmo si usa per determinare se e in che modo il client e il server si autenticano reciprocamente durante l'handshake.[9]
- 3DES_EDE_CBC indica il tipo e la modalità della cifratura a blocchi usata per codificare il flusso di messaggi.[10]
- SHA256 indica l'algoritmo di message authentication code usato per garantire l'integrità e l'autenticità del messaggio, basato su una chiave a 256 bit.[11]
Handshake completo: negoziazione delle suite di cifratura
modificaPer attivare la crittografia, il client e il server devono concordare la suite di cifratura specifica da usare nello scambio dei messaggi. Chiaramente sia il client che il server devono supportare la suite di cifratura prescelta; se non c'è concordanza sulla suite da usare, non viene stabilita alcuna connessione.[12] Il processo di selezione avviene durante la fase iniziale della connessione tramite il protocollo di TLS Handshake. La versione TLS 1.3 prevede un protocollo di TLS Handshake diverso rispetto alle versioni passate e a quella attuale di TLS/SSL.[4]
Dopo aver negoziato quale suite di cifratura usare, il server e il client mantengono comunque la possibilità di modificare i cifrari concordati usando il protocollo ChangeCipherSpec nell'handshake in corso oppure in un nuovo handshake.[3]
Per verificare quali cifrari TLS supporta un server, è possibile usare uno scanner SSL/TLS.
Handshake con TLS 1.0–1.2
modifica
Il client inizia il processo inviando al server un messaggio clientHello che riporta la versione di TLS utilizzata e un elenco di suite di cifratura nell'ordine di preferenza del client. Il server invia come risporta un messaggio serverHello che riporta la suite di cifratura selezionata e l'identificativo della sessione (session ID). Il server invia quindi un certificato digitale per confermare al client la propria identità. All'occorrenza il server può anche richiedere il certificato digitale del client.
Se il client e il server non usano chiavi pre-condivise (Pre-Shared Key, PSK), il client invia un messaggio criptato al server che consente al client e al server di calcolare la chiave segreta da usare per lo scambio dei messaggi.
Dopo aver verificato con successo l'autenticità del server e, se occorre, dopo aver scambiato la chiave segreta, il client invia un messaggio finished per informare il server che il processo di handshake dal suo lato è terminato. Dopo aver ricevuto questo messaggio, il server invia a sua volta al client un messaggio finished per confermare che il processo di handshake si è concluso. A questo punto, client e server hanno stabilito la suite di cifratura da usare per la comunicazione reciproca.
Handshake con TLS 1.3
modifica
Se due macchine comunicano via TLS 1.3, negoziano la suite di cifratura usando il protocollo TLS 1.3 Handshake, che concentra la messaggistica in un solo ciclo di scambio contro i due richiesti nelle versioni precedenti.
Il client invia al server un messaggio clientHello che contiene l'elenco delle suite di cifratura supportate nell'ordine di preferenza del client e in aggiunta esegue una previsione su quale algoritmo di scambio di chiavi potrebbe essere utilizzato così da poter inviare subito all'occorrenza una chiave segreta condivisa. Questo meccanismo di previsione consente di eliminare un ciclo di messaggi.
Dopo aver ricevuto il messaggio di clientHello, il server manda al client un unico messaggio di serverHello contenente la sua chiave, il suo certificato, la suite di cifratura scelta e il messaggio finished.
Dopo che il client ha ricevuto il messaggio finished del server, le due macchine sono allineate su quale suite di cifratura utilizzare.[13]
Algoritmi supportati
modificaIn TLS 1.0–1.2
modifica| Scambio/negoziazione delle chiavi | Autenticazione | Tipo di cifrario a blocchi/flusso | Message authentication code |
|---|---|---|---|
| RSA | RSA | RC4 | Hash MD5 |
| Diffie–Hellman | DSA | Triple DES | Funzione hash SHA |
| ECDH | ECDSA | AES | |
| SRP | IDEA | ||
| PSK | DES | ||
| Camellia |
TLS 1.3
modificaIl protocollo TLS 1.3 ha eliminato molti algoritmi classici che erano supportati nelle versioni precedenti del TLS, nell'intento di rendere il protocollo più sicuro.[14] Inoltre tutti gli algoritmi di cifratura e autenticazione sono combinati insieme nell'algoritmo di cifratura autenticata con dati associati (Authenticated Encryption with Associated Data, AEAD) e nella derivazione delle chiavi si deve usare un algoritmo di hash basato su HMAC (HMAC-based Key Derivation Function, HKDF).[4] Non è più ammesso l'uso degli algoritmi che non rientrano nella classificazione AEAD (Non-AEAD) come per esempio AES_128_CBC: questo per via delle falle di sicurezza e delle potenziali vulnerabilità scoperte durante l'impiego e che potrebbero portare a una connessione TLS non sicura.
DTLS con suite di cifratura
modificaIl protocollo Datagram Transport Layer Security (DTLS) si basa su TLS ma viene usato in modo specifico per connessioni su UDP invece che su TCP. Essendo basato su TLS, il DTLS è in grado di utilizzare la maggior parte delle suite di cifrature definite per il TLS. Ci sono alcuni casi particolari che vanno tenuti in considerazione quando si usano le suite di cifratura TLS per il DTLS: per esempio DTLS non supporta il cifrario a flusso RC4 e quindi non consente l'utilizzo delle suite di cifratura TLS che usano tale algoritmo.[15]
Per stabilire se una suite di cifratura TLS è compatibile con DTLS non è sufficiente basarsi sul suo nome perché tutte le suite del TLS contengono il prefisso "TLS", per esempio: TLS_RSA_WITH_RC4_128_MD5. Invece, tutti i registri dei parametri TLS prevedono adesso il flag DTLS-OK per indicare quando una suite di cifratura è compatibile con DTLS.[16]
Vulnerabilità
modificaIl livello di sicurezza di una suite di cifratura è determinato dal livello di sicurezza degli algoritmi che la compongono: se la versione dell'algoritmo di cifratura o di autenticazione appartenente a una suite possiede vulnerabilità note, allora l'intera suite e la connessione TLS relativa sono vulnerabili. Per questo motivo un tipo di attacco comune contro il TLS e le suite di cifratura è il cosiddetto downgrade attack che consiste nell'usare un server che utilizza versioni di TLS o di SSL più vecchie rispetto al client più moderno.
Quando inizia l'handshake, il client moderno presenta i protocolli più avanzati che possiede; se la connessione non va in porto, il client automaticamente riprova a stabilire la connessione usando protocolli via via meno avanzati (come TLS 1.0 o SSL 3.0) fino a quando riesce a concludere con successo l'handshake con il server. Questo meccanismo è pensato per fare in modo che le nuove versioni di TLS siano compatibili con quelle più vecchie. Un utente malintezionato però può sfruttare questo meccanismo per forzare il client a usare una versione di TLS o SSL che supporta suite di cifratura con vulnerabilità note o deboli dal punto di vista della sicurezza, per poi sfruttare tali vulnerabilità;[17] questo è il meccanismo utilizzato da attacchi come POODLE.
Un modo per evitare questa falla di sicurezza consiste nel disabilitare il server o il client a tornare indietro fino a SSL3.0; lo svantaggio di questa contromisura è che in questo modo non è possibile collegarsi ad alcune macchine vecchie partendo da sistemi più nuovi. Se è necessario ricorrere a SSL 3.0 per poter comunicare con i sistemi più vecchi, esiste una suite di cifratura approvata, TLS_FALLBACK_SCSV, che è in grado di verificare che l'abbassamento della versione non è provocato da intenti malevoli.[17]
Suite di cifratura per dispositivi limitati
modificaGli algoritmi di cifratura, scambio delle chiavi e autenticazione di solito richiedono un'elevata capacità di elaborazione e di memoria. Per garantire la sicurezza anche ai dispositivi limitati con ridotte capacità di elaborazione, memoria e vita della batteria, come ad esempio i dispositivi usati per l'Internet delle cose sono a disposizione delle suite di cifratura selezionate appositamente. Due esempi di queste sono:
- TLS_PSK_WITH_AES_128_CCM_8 (Pre-Shared Key)[18]
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (raw public key)
Ognuna di queste suite è stata realizzata per poter operare su dispositivi con limitate capacità di memoria ed elaborazione e sono state sviluppate nell'ambito del progetto open source TinyDTLS[19]. Il motivo per cui queste suite sono in grado di essere usate da questi dispositivi consiste nel fatto che possono essere implementate con un codice snello: l'implementazione della suite di cifratura PSK richiede soltanto 1889 byte di RAM e 38266 di ROM flash, che è una quantità molto ridotta rispetto alle richieste della maggior parte degli algoritmi di cifratura e di sicurezza.[20] Questo basso consumo di memoria dipende dal fatto che queste suite di cifratura utilizzano algoritmi che si sono dimostrati efficienti e sicuri, anche se non quanto gli algoritmi che richiedono maggiori risorse, per esempio usando una cifratura a 128 bit invece che a 256 bit; in più usano Pre-Shared Key o chiavi pubbliche grezze (raw public key) che richiedono meno occupazione di memoria e potenza di calcolo rispetto alla infrastruttura a chiave pubblica tradizionale (PKIX).[21]
Note di programmazione
modificaNella programmazione, ci si riferisce alle suite di cifratura sia in forma plurale che singolare, con una definizione differente nei due casi:
- CipherSuite cipher_suites (al plurale)
- un elenco delle opzioni crittografiche supportate dal client.[22] Un esempio di come si usano di solito le cipher_suites durante il processo di handshake:[23]
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-2>;
CompressionMethod compression_methods<1..2^8-1>;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ClientHello;
- CipherSuite cipher_suite (al singolare)
- la suite di cifratura selezionata dal server tra le cipher_suites del client.[24] Un esempio di come si usa di solito la cipher_suite durante il processo di handshake:[25]
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
select (extensions_present) {
case false:
struct {};
case true:
Extension extensions<0..2^16-1>;
};
} ServerHello;
Note
modifica- ^ (EN) Cipher Suites in TLS/SSL (Schannel SSP) (Windows), su docs.microsoft.com. URL consultato il 2 luglio 2018.
- ^ (EN) tls and ssl cipher suites | research | sprawl, su thesprawl.org. URL consultato il 26 ottobre 2017 (archiviato dall'url originale il 30 gennaio 2019).
- ^ a b (EN) RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2, su datatracker.ietf.org, Internet Engineering Task Force.
- ^ a b c (EN) RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, su datatracker.ietf.org, Internet Engineering Task Force.
- ^ TLS Cipher Suite Registry
- ^ (EN) The SSL 0.2 Protocol, su www-archive.mozilla.org. URL consultato il 7 dicembre 2017.
- ^ (EN) draft-hickman-netscape-ssl-00, su tools.ietf.org. URL consultato il 7 dicembre 2017.
- ^ (EN) SSL 3.0 Specification, su freesoft.org. URL consultato il 7 dicembre 2017.
- ^ (EN) Tim Dierks, The Transport Layer Security (TLS) Protocol Version 1.2, su tools.ietf.org, p. 47. URL consultato il 26 ottobre 2017.
- ^ (EN) Tim Dierks, The Transport Layer Security (TLS) Protocol Version 1.2, su tools.ietf.org, p. 17. URL consultato il 26 ottobre 2017.
- ^ (EN) Tim Dierks, The Transport Layer Security (TLS) Protocol Version 1.2, su tools.ietf.org, p. 16. URL consultato il 26 ottobre 2017.
- ^ (EN) John Carl Villanueva, An Introduction To Cipher Suites, su jscape.com. URL consultato il 25 ottobre 2017.
- ^ (EN) An overview of TLS 1.3 and Q&A, su cloudflare.com. URL consultato il 19 dicembre 2019.
- ^ (EN) TLS 1.3 Protocol Support | wolfSSL Embedded SSL/TLS Library, su wolfSSL. URL consultato il 26 ottobre 2017.
- ^ (EN) N. Modadugu e E. Rescorla, RFC 4347 - Datagram Transport Layer Security, su tools.ietf.org. URL consultato il 25 ottobre 2017.
- ^ (EN) Eric Rescorla e Nagendra Modadugu, RFC 6347 - Datagram Transport Layer Security Version 1.2, su tools.ietf.org. URL consultato il 25 ottobre 2017.
- ^ a b (EN) Bodo Moeller e Adam Langley, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks, su tools.ietf.org. URL consultato il 25 ottobre 2017.
- ^ (EN) Daniel Bailey e David McGrew, RFC 6655 - AES-CCM Cipher Suites for Transport Layer Security (TLS), su tools.ietf.org. URL consultato il 26 ottobre 2017.
- ^ (EN) Sito del progetto TinyDTLS, su Eclipse.org.
- ^ (EN) Vladislav Perelmen, Security in IPv6-enabled Wireless Sensor Networks: An Implementation of TLS/DTLS for the Contiki Operating System (PDF), 29 giugno 2012, p. 38. URL consultato il 19 dicembre 2019 (archiviato dall'url originale il 29 agosto 2017).
- ^ (EN) Samuel Weiler, John Gilmore, Hannes Tschofenig, Tero Kivinen e Paul Wouters, Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS), su tools.ietf.org. URL consultato il 7 dicembre 2017.
- ^ (EN) RFC 5246, su datatracker.ietf.org, Internet Engineering Task Force. , p. 41
- ^ (EN) Tim Dierks, The Transport Layer Security (TLS) Protocol Version 1.2 - Appendix A.4.1, su tools.ietf.org. URL consultato il 26 ottobre 2017.
- ^ (EN) RFC 5246, su datatracker.ietf.org, Internet Engineering Task Force. , pp. 42–43, 64
- ^ (EN) Tim Dierks, The Transport Layer Security (TLS) Protocol Version 1.2 - 7.4.1.2, su tools.ietf.org. URL consultato il 26 ottobre 2017.
Bibliografia
modifica- (EN) RFC 5246 — The Transport Layer Security (TLS) Protocol Version 1.2, su datatracker.ietf.org, Internet Engineering Task Force.
- (EN) RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3, su datatracker.ietf.org, Internet Engineering Task Force.
