Domande di Teoria di Sicurezza dell'Informazione

Ssl in generale

SSL è un protocollo per garantire comunicazioni riservate, autentiche e integre ma ripudiabili a livello applicativo. Si basa su 4 protocolli:

• Handshake per stabilire la connessione,
• Change cipher spec,
• Alert per segnalare errori,
• Record per comunicare.

Una sessione SSL è un’associazione logica bidirezionale tra un client e un server che contiene una o più connessioni, i canali di trasporto dei dati.

Handshake

Il protocollo permette l’autenticazione dei pari a livello applicativo e non dell’IP (in ogni caso non si controlla che l’URL associato al certificato sia quello con cui si sta dialogando, questo è delegato alle applicazioni che usano SSL) e di concordare i parametri di sicurezza e gli algoritmi:

1. Il client si presenta al server. Nella prima fase si scambiano numeri casuali, si sceglie il meccanismo di scambio delle chiavi.
2. Il server si autentica presentando il proprio certificato e può chiedere anche l’autenticazione del client, sono anche scambiate eventuali informazioni aggiuntive per concordare le chiavi sulla base del metodo scelto.
3. Se richiesto il client si autentica.
4. La sessione viene autenticata facendo un hash di tutti i messaggi precedenti che viene scambiato usando i protocolli concordati.

Record

Da questo momento in poi è possibile comunicare usando il protocollo per scambiare messaggi: questi vengono frammentati, concatenati alla loro lunghezza, ne viene creato un autenticatore con HMAC e quindi il tutto viene cifrato. Di conseguenza, si ha uno svantaggio lato ricevitore che è sempre costretto a decifrare per verificare l’autenticità e integrità (Authenticate then Encrypt).

Diffie-Hellman e varie versioni

Questo protocollo permette di concordare una chiave simmetrica senza alcun accordo precedente basandosi sulla difficoltà del logaritmo discreto e il campo di Galois. Le due parti cominciano concordando il campo, cioè un numero primo molto grande e un generatore del campo in modo che ig mod p, i = 1,2,…, p - 1 = {1,2,…, p - 1}. La robustezza si basa quindi sul fatto che scelto un p esista una e una sola potenza di g che lo generi e che l’operazione inversa sia molto complessa quando p è un primo molto grande.

Le parti cominciano quindi a scegliere casualmente una chiave privata X_A, X_B ∈ {1,2,…, p - 1} e quindi generano la chiave pubblica Y_A, Y_B = g^X_A mod p, g^X_B mod p che viene scambiata in chiaro sulla rete, quindi calcolano la chiave simmetrica come k_AB = Y_B^X_A mod p = k_BA = Y_A^X_B mod p. Questa è la versione anonima dello scambio e non garantisce alcuna identificazione delle parti.

Esistono quindi le varianti fixed ed ephemeral che permettono anche questo grazie all’uso dei certificati. La versione fixed prevede un certificato che garantisca p, g e la chiave pubblica per cui si procede normalmente tranne con l’aggiunta di un passaggio aggiuntivo per aggiungere probabilismo, dato che si lavora sempre con la stessa chiave pubblica. All’inizio dello scambio vengono scambiati anche due numeri casuali (uno per parte), quindi una volta trovata la pre-master secret si calcola il master secret che sarà usato come chiave di sessione.

La versione ephemeral prevede che i certificati garantiscano una chiave pubblica asimmetrica, quindi le chiavi pubbliche sono scambiate firmate con la rispettiva chiave privata garantita dal certificato e accompagnate dalla chiave pubblica stessa. L’uso dei numeri casuali qui non è richiesto ma fatto per compatibilità. Entrambe queste versioni non garantiscono autenticazione perché anche se si usa un certificato non proprio il protocollo terminerà, tuttavia non si arriverà a concordare la stessa chiave.

Quali meccanismi di scambio di chiavi può garantire SSL

SSL permette di scambiare le chiavi usando DH in una qualunque variante o un cifrario ibrido. Scambi con KDC o master key non hanno senso in quanto richiedono un precedente accordo tra le parti, cosa impossibile in Internet.

SSL vs IPSec: confrontare come garantiscono autenticazione e riservatezza e in generale gli header necessari per IPSec

SSL garantisce l’autenticazione applicativa con un certificato sull’URL del server, IPSec invece lavora a livello di rete e quindi il suo certificato garantisce l’IP del pari. SSL garantisce riservatezza usando il protocollo record, IPSec invece usando il protocollo ESP che può garantire soltanto la riservatezza per migliorare l’efficienza di una cifratura a livello applicativo senza garantire autenticazione e integrità dei singoli messaggi oppure anche con autenticazione in cui il cifrato viene poi autenticato con un segreto condiviso (Encrypt then Authenticate).

In modalità trasporto viene cifrato (e autenticato) solo il payload, mentre in tunnel tutto il pacchetto originario. Per fare questo IPSec sfrutta un header aggiuntivo in cui inserisce l’autenticatore (nel caso di AH) o il padding della cifratura simmetrica in caso di ESP e l’autenticatore viene concatenato al cifrato nel payload. L’header contiene anche il numero di sequenza del messaggio per garantire il servizio anti replica e il SPI per individuare la SA di appartenenza del pacchetto.

Finestra a scorrimento di IPSec

Per garantire il servizio anti replica, dopo aver autenticato e verificato l’integrità del pacchetto se ne analizza il numero di sequenza per verificare se accettarlo o meno:

• Se ricade all’interno della sliding window (a default di 64 pacchetti) si verifica se già ricevuto o no, se no viene accettato e la sliding window aggiornata per riportare questa informazione senza però spostarla.
• Se viene prima del limite sinistro è considerato troppo vecchio e scartato a prescindere, sarà compito dei livelli superiori (TCP) spedire un nuovo pacchetto che avrà quindi un numero di sequenza IPSec maggiore.
• Se viene dopo il limite destro viene accettato e la sliding window fatta avanzare fino ad includerlo.

Cammini di fiducia

Nella verifica dei certificati dello stesso dominio si sfrutta la chiave pubblica della CA che viene distribuita con un certificato autofirmato all’interno della stessa directory e al momento della registrazione. Per passare ad altri domini occorre quindi che ci siano delle relazioni di fiducia tra la propria CA e le altre, questo è espresso dai cross-certificate in cui la CA firma con la propria chiave privata un certificato che garantisce la chiave pubblica di un’altra CA. Si definisce quindi cammino di fiducia il percorso di cross-certificates che porta dalla propria CA a quella del certificato che si deve valutare e trovarlo equivale alla ricerca di un cammino all’interno di un grafo. La difficoltà è quindi legata a come le CA sono organizzate fra di loro (un’organizzazione ad albero sarebbe l’ideale ma non è quasi mai possibile). Questi cammini possono però partire anche da CA diverse dalla propria in quanto sul sistema sono installati del certificati autofirmati detti Root Certification Authority.

Affinché il cammino sia considerato valido ogni certificato non deve né essere scaduto né revocato (attraverso un sistema identico alle CRL ma parallelo detto Authority Revocation List). Si possono poi adottare politiche particolari basate sulle estensioni presenti sul certificato.

PGP: il portachiavi a chiave pubblica

Contiene le chiavi pubbliche degli utenti con cui si è entrati in contatto, ognuna è salvata come una entry composta da:

• Identificatore del chiave pubblica (64 bit meno significativi).
• Chiave pubblica completa.
• Identificatore dell’utente.
• Momento della memorizzazione.
• Owner trust: livello di fiducia che il possessore del portachiavi attribuisce alla chiave.
• Signature trust: livello di fiducia attribuito al firmatario (se presente all’interno del portachiavi) di/del certificato/i con cui la chiave è stata distribuita. PGP calcola automaticamente questo valore.
• Key legitimacy: legittimità della chiave calcolata da PGP sulla base di owner trust e signature trust.

Poiché i livelli di fiducia possono cambiare nel tempo, PGP ricalcola periodicamente signature trust e key legitimacy per riflettere le modifiche a owner trust. Poiché il modello è decentralizzato, la diffusione di informazioni da un portachiavi all’altro è molto più lenta e queste chiavi non possono avere valore legale.

Cifrari simmetrici a flusso auto-sincronizzanti e flusso sincrono

Quando è meglio a flusso o a blocchi? Come funzionano ECB e CBC? Qual è meglio per cifrare una chiave di sessione e qual è meglio per cifrare un file?

I cifrari simmetrici a flusso servono quando occorre cifrare un flusso di dati e non si può aspettare che arrivino i prossimi byte. Si basano quindi sul fatto che sorgente e destinazione abbiano entrambi un generatore di flusso di chiave sincronizzato fra di loro in modo che generi la stessa sequenza con cui cifrare e decifrare, nel caso auto-sincronizzante...