04 Confidenzialità utilizzando la crittografia

[lezione del 10 ott 2019]

Dati gli strumenti per effettuare encryption, dove dobbiamo applicare la crittografia?

Consideriamo uno scenario con una LAN dotata di WiFi e con un router per il collegamento ad Internet. Vi sono più punti di attacco possibili:

  • è possibile che un dipendente osservi il traffico LAN;

  • si può osservare il traffico WiFi anche senza essere direttamente connessi,

  • è possibile derivare il router ed osservare il traffico da/a Internet;

  • in Internet un attaccante esterno può avere accesso ad un router che gestisca tutto o in parte il traffico in ingresso/uscita dalla LAN; …

Quindi si capisce come sia possibile che l’attività di en/decryption possa avvenire contemporaneamente a livelli diversi dei possibili strati di trasmissione dati:

  • applicativo;

  • trasporto;

  • routing;

  • accesso.

Ed usualmente sarà proprio così. L’applicazione effettuerà encryption dei propri dati. Questi (crittati) saranno sottoposti a encryption anche a livello di trasporto (ad. es. https). E potrebbero essere ulteriormente crittati a livello di accesso (ad esempio tramite WiFi).

Di solito si ha encryption:

  • in ogni device di switch (link encryption);

  • nei sistemi terminali (end-to-end encryption).

È essenziale assicurarsi dell’esistenza della end-to-end encryption. Se non si fa questo, ci si affida ciecamente ai sistemi di encryption del network, e se si va su Internet, questo è suicida 1.

End-to-end encryption

Vantaggi:

  • risolve eventuali dubbi riguardo la sicurezza di link e della rete;

  • fornisce la funzionalità di autenticazione.

Svantaggi:

  • è cifrato solo il livello applicativo, lasciando esposti i dati di trasmissione 3.

Riassumendo, possiamo confrontare le due metodologie come segue 4:

  • scopo

    • L: proteggere il livello di link da sniffers

    • E2E: proteggere il livello applicativo da nodi compromessi

  • copertura della cifra:

    • L: specifica del link, riguarda tutto il pacchetto trasmesso;

    • E2E: specifico della connessione, che è cifrata attraverso ogni link;

  • sicurezza dell’header del protocollo

    • L: criptati per tutti i livelli (dal fisico o dal link in su);

    • E2E: criptati solo i livelli più alti;

  • esposizione del device di rete

    • L: i nodi intermedi decifrano;

    • E2E: i nodi intermedi non sono in grado di decifrare;

  • autenticazione

    • L: disponibile l’autenticazione dell’host;

    • E2E: fornisce autenticazione dell’utente

  • facilità d’uso

    • L: trasparente per l’utente, una chiave per ogni link

    • E2E: non è trasparente per l’utente, una chiave per connessione

  • selezionabilità dell’algoritmo da parte dell’utente

    • L: stesso algoritmo per tutti gli utenti

    • E2E: l’utente può scegliere l’algoritmo di cifratura

  • implementazione

    • L: in hardware

    • E2E: hardware o software

applicazioni

  • L: virtual private network (VPN)

  • E2E: Secure Shell (SSH), SSL, Pretty Good Privacy (PGP)

Confidenzialità del traffico

L’analisi del traffico è parzialmente possibile anche nel caso di uso di end-to-end encryption.

L’attaccante può apprendere:

  • numero e lunghezza dei messaggi tra i nodi

  • la frequenza delle comunicazioni.

Ciò al fine di capire:

  • chi parla con chi,

  • quale protocollo viene utilizzato;

  • il tipo di dati e applicazioni utilizzate.

Covert channel

Un covert channel è un mezzo per comunicare secondo modalità non previste dal progettista del canale di comunicazione.

Ad esempio due partecipanti alla comunicazione possono concordare un codice che rappresenti un uno o uno zero in funzione di una lunghezza dei messaggi scambiati.

Contromisure

Se si usa link encryption:

  • gli header di rete già sono cifrati;

  • per evitare la misurazione della lunghezza del testo trasmesso, è possibile inviare comunque dei ciphertext non vuoti anche se il testo da trasmettere è vuoto.

Se si usa end-to-end encryption:

  • gli headers non sono protetti;

  • comunque si può effettuare il padding dei messaggi e generare ciphertext non vuoti in presenza di messaggi vuoti.

La distribuzione delle chiavi

Due partecipanti ad una conversazione confidenziale (A e B) hanno necessità di scambiarsi in sicurezza le chiavi simmetriche per effettuare la (de)cifratura dei messaggi.

Le possibilità sono le seguenti:

  • A può scegliere una chiave e consegnarla fisicamente a B;

  • un terzo partecipante può scegliere una chiave e consegnarla fisicamente ad A e a B;

  • se A e B hanno usato recentemente una chiave K, possono usarla per scambiare una nuova chiave;

  • se A e B hanno una connessione criptata con un terzo partecipante C, questo può inviare ad entrambi una chiave di sessione.

Consegnare fisicamente le chiavi è possibile solo se deve essere distribuita una piccola quantità di chiavi. È il caso del link encryption su piccole reti.

Quando si effettua end-to-end encryption tra nodi, la consegna fisica delle chiavi è improbabile. Con N nodi magliati (tutti parlano con tutti) le possibili sessioni sono \(N \cdot (N - 1) / 2\). 1000 nodi richiederebbero \(500^{.}000\) chiavi. Se ogni nodo avesse 10 applicazioni, bisognerebbe gestire \(10^{.}000\) applicazioni, per un totale di circa \(50 \cdot 10^6\) chiavi da distribuire. In questi scenari, è necessario trovare un modo di distribuire le chiavi dinamicamente e in modo sicuro tramite canali di comunicazione.

Con end-to-end encryption si usano i key distribution center (KDC). Quando una entità deve usare una chiave per una comunicazione end-to-end (detta session key), la richiede al key distribution center. Per poter effettuare questa operazione, l’entità deve utilizzare una master key. Ogni entità sarà dotata di una propria master key.

Un possibile scenario di distribuzione delle chiavi con KDC è il seguente:

_images/03_key_distrib.svg

in cui:

  1. A invia la richiesta di una chiave di sessione al KDC, nella richiesta è incluso \(N_1\) (nonce) come identificativo della stessa.

  2. KDC risponde con un messaggio criptato con la chiave pubblica \(K_a\) 5. La risposta include la chiave per la sessione(\(K_s\)) e il messaggio originale incluso il suo identificativo 6. Inoltre la risposta include un ulteriore messaggio per B, criptato con la chiave pubblica \(K_b\), contenente la chiave per la sessione e l’identificativo di A (\(ID_a\), ovvero il suo indirizzo di rete).

  3. A memorizza la chiave per la sessione e inoltra a B il messaggio che gli è destinato (ovvero \(E(K_{b}, [K_{s}||ID_{A})\)) 7. A questo punto la comunicazione tra A e B potrebbe cominciare, ma, per essere certi che il messaggio ricevuto da B in (3) non sia un reply è bene effettuare altri due passi:

  4. B invia un nuovo nonce ad A (\(N_2\));

  5. ed A risponde a B modificando in modo conosciuto il nuance ricevuto.

È possibile pensare a distribuzione delle chiavi con controllo decentralizzato.

Questo scenario è interessante perché permette di evitare possibili problemi di guasto e sicurezza legati alla presenza di un nodo centrale: il KDC. Però richiede che ogni nodo abbia una master key condivisa gli altri nodi cui può comunicare; come detto in precedenza: \(N \cdot (N - 1) / 2\) master keys.

In questo caso possiamo avere:

_images/04_decentralized_key_distrib.svg

in cui:

  1. A invia una richiesta a B per ricevere una session key; la richiesta è identificata dal nonce \(N_1\).

  2. B risponde con un messaggio criptato con la master key (\(K_m\)). La risposta contiene la session key (\(K_s\)) scelta da B, l’identificatore di B, una modifica conosciuta di \(N_1\) e un secondo nonce (\(N_2\)).

  3. A risponde a sua volta criptando con la session key una modifica conosciuta di \(N_2\).

Un altro aspetto da considerare è come vengono usate le chiavi.

In generale è bene avere una qualche forma di controllo su come vengono utilizzate le chiavi che sono distribuite.

Ad esempio, è ragionevole pensare che una master key non possa essere trattata come una session key.

Oppure, si può volere utilizzare tipi diversi di session key a seconda della tipologia d’uso. Ad esempio: per criptare i dati possono avere chiavi diverse da quelle per criptare i PIN.

Generazione di numeri casuali

I numeri casuali hanno un ruolo importante nella crittografia.

Ad esempio negli scenari precedenti riguardo la distribuzione di chiavi, con la presenza di KDC o a controllo distribuito, si usano i nonce (\(N_x\)) nel colloquio per prevenire gli attacchi di tipo replay.

Spesso i nonce sono numeri casuali. Così come si usano numeri casuali per la generazione di session key e di chiavi per gli algoritmi di cifratura RSA a chiave pubblica.

Quando si ha una sequenza di numeri che dovrebbero essere statisticamente casuali, si utilizzano due criteri per validarli:

  • distribuzione uniforme;

  • indipendenza.

È possibile controllare l’uniformità di una distribuzione. Non è possibile controllare con sicurezza l’indipendenza degli elementi tra loro.

La generazione di numeri statisticamente casuali è difficile. Un rilassamento delle condizioni si può avere limitandosi a richiedere la imprevedibilità.

In crittografia si usano appositi algoritmi per generare sequenze di numeri casuali. Questi algoritmi sono deterministici. Quindi a rigore non dovremmo parlare di sequenze di numeri statisticamente casuali. Ma, se l’algoritmo è buono, la sequenza generata è in grado di superare molti test di casualità.

Generatori lineramente congruenti.

Utilizzano la formula \(X_{n+1} = (a \cdot X_{n} + c) \; mod \; m\)

  • \(m\) è il modulo \(m > 0\);

  • \(a\) è un moltiplicatore tale che \(0 < a < m\);

  • \(c\) è un incremento tale che \(0 < c < m\);

  • \(X_0\) è il valore di partenza (seme: seed) con \(0 < X_0 < m\).

Una occhiata a Wikipedia (vedi [WIKI2019a]) ci avverte di usare attenzione nella scelta dei diversi coefficienti. La stessa fonte riporta alcuni esempi ampiamente studiati. Tra questi, i coefficienti della glibc di GCC: \(m = 2^{31}\), \(a = 1103515245\) \(c = 12345\).


1

Internet è un sistema di internetworking pubblico. Non vi è modo di sapere su quali sistemi passerà il proprio traffico dati. Di conseguenza non vi è alcuna possibilità di pensare ad una forma di protezione diversa dal end-to-end.

2

Un opponente può avere successo entrando in uno qualunque dei sistemi che implementano la rete.

3

I dati della trasmissione possono essere un potenziale obiettivo di un opponente. Sapere chi parla con chi, con quale frequenza, la lunghezza dei messaggi … sono tutte informazioni che possono interessare.

4

L indica Link Encryption; E2E indica End to End Encryption.

5

Quindi solo A può leggere il messaggio, e certifica che è stato emesso da KDC.

6

In tal modo A può gestire la richiesta: infatti può averne inviate più di una.

7

In questo caso l’uso di \(K_b\) permette solamente a B di leggere il messaggio, e certifica che proviene da KDC. Inoltre identifica con \(ID_A\) il richiedente che vuole instaurare la comunicazione.