Che materia stai cercando?

Appunti di Sicurezza dell'Informazione

Conoscenze e abilità da conseguire
Conoscenza degli algoritmi e dei protocolli per la difesa dei sistemi per l'elaborazione dell’informazione da attacchi intenzionali. Conoscenza dei meccanismi protettivi impiegati in contesti di rilevante interesse applicativo.

Programma/Contenuti
1. Sicurezza dei sistemi informatici: attacchi, proprietà di sicurezza e contromisure.
2.... Vedi di più

Esame di Sicurezza dell'Informazione M docente Prof. R. Montanari

Anteprima

ESTRATTO DOCUMENTO

Questa tecnica usa una chiave di simboli del linguaggio naturale e di lunghezza finita, permettendo di avere

sequenze di più caratteri cifrati con gli stessi caratteri della chiave. La ricerca di queste sequenze di caratteri

porta a determinare la lunghezza della chiave sulla base delle distanze a cui si trovano, permettendo quindi

una restrizione forte delle chiavi possibili, sulla base della lunghezza, e su cui può quindi essere eseguito un

attacco di forza bruta.

Per aumentare la robustezza di questo cifrario occorre quindi usare non più una chiave di lunghezza

finita ripetuta, ma una che sia lunga quanto il testo i cui caratteri sono scelti in maniera completamente

casuale (anche se ciò risulta tuttavia molto oneroso se si intende comunicare la chiave su un canale privato

sicuro dedicato). Si può poi fare in modo che ogni simbolo del testo in chiaro non abbia effetto solo sul

corrispondente simbolo cifrato ma anche su tutti i simboli successivi.

3.6 One time pad

Questo cifrario è un’evoluzione della sostituzione polialfabetica, con chiave lunga quanto il testo. Essa veniva

applicata alle comunicazioni telegrafiche assumendo una codifica binaria a 5 bit.

La prima versione, o cifrario di Vernam, usa una chiave letta da una nastro che avanza carattere per

carattere durante la cifratura, ma questa chiave non è assolutamente casuale. Il miglioramento proposto

da Mouborgne ha portato alla nascita della tecnica denominata one time pad, in cui ogni chiave viene

usata una sola volta. Sia la sorgente che la destinazione hanno un generatore di flusso di chiave che genera

gli stessi caratteri; per cifrare la sorgente somma in modulo 2 il messaggio e la chiave, cioè ne fa lo XOR,

mentre per decifrare viene ripetuta la stessa operazione sommando la chiave al testo cifrato.

È stato dimostrato che questo cifrario risulta inviolabile, tuttavia richiede che le chiavi vengano protette

in maniera molto sicura. Ciò richiede però molto impegno anche per garantire l’allineamento tra i due

generatori di chiavi, ragione per cui questa tecnica è stata poco usata. Il cifrario è sì inviolabile da un

attacco passivo, perché chiavi diverse possono dare messaggi diversi che hanno entrambi un senso logico,

tuttavia è suscettibile di attacchi attivi in cui il messaggio cifrato viene modificato.

3.7 Sicurezza

Si parla di sicurezza perfetta se, dato un messaggio cifrato, risulta impossibile ottenere il testo in chiaro

senza conoscere la chiave. Ci concentreremo invece sulla sicurezza computazionale, cioè per cui è neces-

saria una potenza computazionale maggiore di quella disponibile per ottenere il testo in chiaro dal messaggio

cifrato senza conoscere la chiave.

Sulla base degli studi di Shannon, per aumentare la sicurezza computazionale occorre creare confusione,

cioè deve essere difficile prevedere cosa accade al testo cifrato se si cambia anche un solo simbolo del testo

in chiaro. Per realizzare questo la tecnica più semplice risulta essere la sostituzione. Allo stesso tempo

deve essere presente diffusione, cioè ogni carattere del testo in chiaro deve influire su molti, se non tutti, i

simboli del testo cifrato. Per realizzare questo la tecnica migliore è la trasposizione.

21

Capitolo 4

Cifrari simmetrici

I cifrari simmetrici sono molto efficienti e veloci, e per come operano possono avere anche un’implementazione

in hardware. Sono solitamente usati per garantire la riservatezza, ma in casi limitati possono essere usati

anche per l’autenticazione e l’identificazione.

Esistono due tipi di cifrari:

• Cifrari a flusso: trasformano, con una regola variabile nel tempo, uno o pochi bit per volta. Sono

usati per cifrare flussi di dati, come trasmissioni telefoniche, in cui non si vuole un rallentamento nel

flusso per attendere i bit successivi. Questi cifrari si riconducono al one time pad.

• Cifrari a blocchi: suddividono il messaggio in blocchi di uguale dimensione e ad ognuno viene

applicata la stessa trasformazione. Sono usati tipicamente per la memorizzazione o scambio di dati, e

si rifanno alla sostituzione monoalfabetica, combinata in alcuni casi con trasposizione e altre tecniche.

4.1 Cifrari a flusso

Questo tipo di cifrari si riconduce al one time pad, pertanto occorre che sorgente e destinazione abbiano

a disposizione un PRNG crittograficamente sicuro, impostato con lo stesso seed iniziale in modo che le

sequenze di bit generate siano uguali e sincronizzate. Siccome i PRNG generano dei flussi di chiave periodici

di periodo lunghissimo, questo sistema non risulta perfettamente sicuro, ma è invece computazionalmente

sicuro.

Per il corretto funzionamento del sistema occorre che ci sia una perfetta sincronia tra sorgente e destina-

zione, altrimenti si decifrerà qualcosa di sbagliato.

I cifrari a flusso sono ulteriormente suddivisi in:

• Cifrari a flusso sincrono: questa tipologia corrisponde a quanto appena descritto, in cui si usano

due PRNG impostati con lo stesso seed iniziale.

• Cifrari a flusso auto-sincronizzante: in questo schema è presente una retroazione tra il testo

cifrato e i bit di chiave. Uno shift register, in collaborazione con un seed iniziale, determina la chiave

di cifratura corrente. Alla destinazione si avrà una struttura analoga in cui il testo cifrato entra nello

stesso shift register per collaborare con il seed iniziale al fine di generare la chiave. Questa idea,

applicata per gruppi di bit e non singolarmente, sarà alla base dei cifrari a blocchi in modalità CFB

(§ 4.2.2.2.1).

La distinzione tra questi due tipi di cifrari deriva dalla necessità di evitare gli attacchi attivi:

• L’aggiunta o cancellazione di bit dal messaggio cifrato porta ad una perdita di sincronismo tra i PRNG.

Non si riesce più quindi a decodificare correttamente.

• La modifica di un bit porta a sbagliare una sola decifrazione ma non si perde il sincronismo.

L’uso di cifrari a flusso auto-sincronizzante permette di evitare problemi in caso di aggiunta, o rimozione,

di bit avendo solo un periodo transitorio in cui non si riesce a decifrare. Ciò avviene tuttavia a scapito della

22

gestione della modifica di un bit, la quale porta ad un periodo transitorio in cui non si riesce a decifrare

(e non a decifrare male un solo bit). La durata del periodo transitorio deriva dalla lunghezza dello shift

register, che porta a decifrazioni errate fintanto che ci sono bit sbagliati nello shift register stesso.

La costruzione di un cifrario a flusso auto-sincronizzante risulta molto più costosa, e richiede una tecnica

particolare per la realizzazione dello shift register, motivo per cui esso viene utilizzato in maniera limitata. La

scelta di quale cifrario a flusso adottare dipende da quali tipi di attacchi sono più probabili nell’infrastruttura

che si sta progettando.

Esempio 4.1 – WEP Il cifrario WEP a flusso sincrono, usato in passato nelle comunicazioni Wi-Fi,

si basa su una chiave precedentemente condivisa, concatenata ad un vettore di inizializzazione di e

24 bit,

usata come seed del PRNG. In questo sistema, viene inviato il vettore di inizializzazione in chiaro assieme

al testo cifrato, il quale verrà usato a destinazione per reimpostare il PRNG.

Non è possibile richiedere che ad ogni frame scambiato si usi una chiave diversa, dunque si è scelto di

lasciare inalterata la chiave e far sì che per frame successivi il vettore di inizializzazione venga incrementato

di 1. Sulla base di questa scelta, il cifrario non risulta per nulla robusto, in quanto la stessa chiave viene

usata più volte. Data la semplicità della cifratura effettuata con uno XOR, un attaccante può intercettare

più messaggi, e dedurre delle informazioni sui messaggi in chiaro senza attaccare l’algoritmo del PRNG o la

chiave dopo aver identificato due messaggi cifrati con lo stesso flusso di chiave:

⊕ ⊕

c = m P RN G(k), c = m P RN G(k),

1 1 2 2

⊕ ⊕ ⊕ ⊕ ⊕

c c = m P RN G(k) m P RN G(k) = m m .

1 2 1 2 1 2

24

Nel caso di quest’algoritmo, si ha la stessa chiave ogni frame, in quanto i vettori di inizializzazione

2

vengono ripetuti portando anche ad avere dei seed successivi, in particolare il loro suffisso di fortemente

24 bit,

correlati fra loro.

4.1.1 Attacco di malleabilità

I cifrari a flusso sono suscettibili ad attacchi di malleabilità. Tali cifrari risultano infatti malleabili in quanto

dedicati alla riservatezza, senza occuparsi di garantire integrità: un attaccante può quindi intervenire sul

testo cifrato, modificandolo in modo che il messaggio decifrato risulti esattamente come desiderato (e non un

testo casuale privo di significato come invece ci si aspetterebbe). Se sul canale si trova il messaggio cifrato:

c = m P RN G(k),

un attaccante può intercettare il messaggio e sommarvi una sequenza di bit opportuna in modo che a

p

destinazione arrivi ⊕ ⊕

m P RN G(k) p

che una volta decifrato risulta uguale a ⊕

m p

che avrà l’esatto significato voluto dall’attaccante.

Esempio 4.2 Si prenda ad esempio uno scambio di messaggi strutturati tra Bob e Alice tali che, prima

del corpo del messaggio, presentino un’intestazione che specifica il mittente del messaggio. L’attaccante

non ha modo di conoscere la chiave o di leggere il messaggio cifrato, ma conosce solo la forma dei messaggi

perché conosce il contesto applicativo. L’attaccante non vuole modificare il testo del messaggio, ma cambiare

l’intestazione affinché il messaggio sembri provenire da Eve; deve pertanto modificare l’intestazione da From

a per determinare cosa sommare, calcola la codifica ASCII di e ottenendo

Bob From Eve: Bob Eve,

B = E =

0x426f62, 0x457665,

calcolando lo XOR tra questi due ottiene ⊕

p B E

= = 0x071907,

sommando quindi questa stringa di bit, con opportuni 0 iniziali per mantenere inalterata la prima parte

dell’intestazione, farà sì che diventi

Bob Eve. 23

4.2 Cifrari a blocchi

I cifrari a blocchi risultano robusti in tutti i contesti applicativi dove è presente asincronismo, per esempio

per cifrare molti dati che non necessitano di essere decifrati subito.

Il messaggio originale viene suddiviso in blocchi di molti bit, il cui numero varia a seconda dell’algoritmo; a

ogni blocco viene quindi applicata la stessa trasformazione, secondo una chiave di lunghezza finita abbastanza

lunga da rendere impossibile un attacco di forza bruta (ad oggi almeno di In decifrazione si suddivide

128 bit).

nuovamente il testo cifrato in blocchi, ognuno decifrato con una stessa trasformazione (inversa di quella di

cifratura), pilotata dalla stessa chiave usata per cifrare.

Come nelle funzioni hash si ha la necessità di aggiungere un padding nell’ultimo blocco se non risulta

abbastanza lungo, secondo gli standard PKCS#5 e #7. Diversamente dai cifrari a flusso, inoltre, la chiave

può essere riutilizzata per più messaggi, e la dimensione del testo cifrato può anche risultare maggiore del

k

testo in chiaro per introdurre ridondanza.

La modalità appena illustrata è denominata modalità di base o Electronic Code Book ECB e appli-

ca, sostanzialmente, una sostituzione monoalfabetica, non risentendo però della vulnerabilità di un’analisi

statistica in quanto ogni blocco non contiene un singolo carattere, ma molti caratteri alla volta.

Algoritmi standard di questa tipologia sono il DES, che operava negli anni ’80 e ’90 in ambito bancario con

di chiave e blocchi di seguito dal TDES, che permette invece chiavi di dimensione variabile. Al

56 bit 64 bit,

giorno d’oggi viene utilizzato AES, con chiavi variabili tra 128 e e con blocchi di dimensioni variabili

256 bit

tra 128 e Come già detto la chiave dovrà essere completamente aleatoria e, anche se può essere

256 bit.

riutilizzata per più messaggi, occorre comunque cambiarla periodicamente per ridurre il numero di campioni

di testo cifrato di cui un attaccante può disporre.

4.2.1 Rete di Feistel L R

k

i−1 i−1

i

La maggior parte dei cifrari a blocchi (tra cui non compare lo standard attuale ⊕ F

AES) si rifanno alla rete di Feistel. Questa rete descrive un procedimento

che permette di aggiungere diffusione e confusione attraverso trasposizione e

sostituzione secondo la teoria di Shannon (§ 3.7). Questo deve essere realizzato L R

i i

generando dei blocchi di testo cifrato univoco per il corrispondente testo in

chiaro. Figura 4.1: Un round della

rete di Feistel.

Le due word di ogni blocco, dette sinistra e destra , vengono sottoposte

L R

0 0

a più round di trasformazione, con almeno un’operazione di sostituzione e trasposizione per round: per fare

ciò, ogni round applica una sostituzione a , poi sommata modulo 2 con per generare , mentre

F R L R

i 0 i+1

sarà per dare trasposizione (Figura 4.1). La chiave , usata per ad ogni round, dovrà essere di-

L R k F

i+1 i i

versa e generata secondo uno specifico algoritmo, a partire dalla chiave condivisa tra sorgente e destinazione.

Lo standard attuale AES ha avuto origine da una gara il cui obiettivo era la ricerca di un algoritmo con

prestazioni eccellenti su qualunque tipo di piattaforma, basso utilizzo di memoria, semplice setup iniziale

di una chiave di lunghezza variabile e possibilità di parallelizzare le operazioni. L’algoritmo scelto è stato

il quale non segue il modello di Feistel per applicare trasposizione e sostituzione; l’algoritmo di

Rijndael,

cifratura e decifratura risultano inoltre distinti.

4.2.2 Modalità di cifratura

I cifrari a blocchi possono essere usati in più modalità, occorre quindi scegliere quella ottimale.

La modalità di base, vista in precedenza, cifra con la stessa chiave ogni singolo blocco. Per questo

motivo, se blocchi diversi contengono parti uguali, il cifrato sarà in qualche modo simile, inoltre messaggi

identici forniscono lo stesso identico cifrato. Ciò non è ottimale, in quanto il risultato in questo modo non è

perfettamente aleatorio, e risulta anche vulnerabile ad attacchi di malleabilità. Questa modalità è, quindi,

24

fortemente sconsigliata quando si devono cifrare dei dati fortemente strutturati, mentre rimane valida per la

cifratura di numeri casuali che sono contenuti in un solo blocco. La casualità è infatti, in questo caso, fornita

dal contenuto del messaggio, e la si può pertanto applicare nello scambio di chiavi simmetriche presenti in

un solo blocco. Esistono altre modalità di cifratura che vanno confrontate sulla necessità di fare padding,

testo cifrato aleatorio, resistenza a rumori sul canale e possibilità di parallelizzare le operazioni. m

4.2.2.1 Cipher Block Chain CBC i

c

In questa modalità il messaggio viene suddiviso in parti e, nell’ultima, viene aggiunto del i−1

padding. Per ridurre il determinismo si fa in modo che ogni blocco dipenda anche da tutti

i precedenti: viene quindi aggiunto un blocco di inizializzazione , posto in XOR con

IV E

k k

la prima parte di testo in chiaro prima di essere cifrata. Il testo cifrato risultante passa

quindi al secondo blocco, dove viene posto in XOR con la parte di messaggio in chiaro c

i

relativo a tale blocco prima di cifrarla. Il procedimento prosegue cifrando in questo modo

4.2),

ogni parte di testo in chiaro in XOR con il testo cifrato del blocco precedente (Figura Un

Figura 4.2:

blocco di cifratura

dove si assume . Poiché ogni blocco dipende dal risultato del precedente risulta

c = IV

0 in modalità CBC.

impossibile parallelizzare.

Questa tecnica introduce non determinismo, a patto però che il vettore di inizializzazione sia completa-

mente aleatorio, imprevedibile e usato solo una volta. Il blocco di inizializzazione deve essere noto sia a chi

cifra, sia a chi decifra, senza necessità di tenerlo segreto; se lo fosse si aumenterebbe la sicurezza complessi-

va. Se il vettore di inizializzazione non rispetta queste condizioni questa modalità diventa vulnerabile a un

attacco con testo in chiaro noto.

Questa modalità in cifratura risulta molto meno efficiente della ECB. Essa è compatibile in termini di

padding, ma richiede l’invio del vettore di inizializzazione e non permette pre-processazione dei dati né la

parallelizzazione. In decifrazione, poiché si hanno a disposizione già tutti i blocchi di testo cifrato, risulta

possibile parallelizzare le operazioni. La modifica del testo cifrato si ripercuote su tutti i blocchi successivi.

4.2.2.2 Cipher Feedback CFB e Output Feedback OFB

Queste due modalità sono affini ai cifrari a flusso. La prima è simile ad un cifrario a flusso auto-sincronizzante,

mentre la seconda ad un cifrario a flusso sincrono.

4.2.2.2.1 CFB In modalità CFB deve essere pre-condivisa una chiave ed un vettore di inizializzazione.

k ≫

Il mittente quindi codifica bit del messaggio alla volta usando un’operazione che cifra bit alla

n N n

volta.

Al primo passo lo shift register viene impostato al vettore di inizializzazione , come illustrato in

IV

Figura 4.3a. Ad ogni passo, il suo contenuto viene cifrato secondo la chiave, generando bit cifrati e salvati

N

in un altro shift register. Gli bit più significativi di questo secondo shift register sono quindi usati per

n

cifrare un blocco del messaggio mediante un’operazione di XOR. Il risultato sarà il primo blocco cifrato di n

bit, inseriti poi come bit meno significativi del primo shift register. Si procede quindi per i blocchi successivi,

che saranno cifrati con bit sempre diversi, riducendo in questo modo il determinismo.

In questa modalità risulta ottimale che il vettore di inizializzazione sia privato. Inoltre, siccome i valori

dello shift register principale sono composti da tutti i blocchi cifrati precedenti e dal vettore di inizializ-

zazione, è possibile parallelizzare l’operazione di decifrazione riempiendo opportunamente gli shift register;

inoltre, poiché la cifratura del messaggio avviene attraverso uno XOR, anche in decifrazione gli shift regi-

ster saranno processati usando la stessa operazione di cifratura. Questa tecnica non richiede l’aggiunta di

padding, ma è vittima di una propagazione degli errori finché i bit errati permangono nello shift register.

4.2.2.2.2 OFB Come illustrato in Figura 4.3b, OFB opera in maniera simile al CFB, con la differenza che

la retroazione non è del messaggio cifrato ma degli bit più significativi del flusso di chiave. Analogamente al

n

CFB non è richiesta l’operazione inversa della cifratura per decifrare il messaggio, tuttavia questa modalità

risulta più resistente alla modifica di bit per errori sulla rete in quanto non c’è propagazione degli errori sui

bit successivi, presenta però gli stessi problemi di un cifrario a flusso sincrono.

25 Shift register

Shift register bit

N

bit

N ⧸

⧸ N

N E

k

E

k ⧸

⧸ N

N Shift register a bit

N

Shift register a bit

N | − bit

| bit

− N n

n

bit

bit N n

n ⧸

⧸ n

n

⧸ ⧸

m i n n ⧸ ⧸

m c

i i

c n n

i

(a) (b)

Blocco di cifratura in Blocco di cifratura in

modalità CFB. modalità OFB.

Figura 4.3: Modalità a retroazione.

4.2.2.3 Counter CTR +1

In questa modalità il testo in chiaro viene suddiviso in blocchi e ogni blocco viene Registro

seed

sommato modulo 2 col risultato della cifratura dello stato di un contatore ran-

domizzato. Per impostare il contatore viene usato un seed iniziale casuale e, ad E

k k

ogni blocco viene incrementato di 1. Questa modalità è quindi perfettamente pa- k

i

rallelizzabile sia in cifratura che in decifrazione. Lavorando con lo XOR non c’è ⊕

m c

i i

necessità di una funzione dedicata di decifrazione, inoltre, è possibile avere un

accesso casuale ai blocchi. Questa modalità risulta essere la più efficiente. Figura 4.4: Blocco di ci-

fratura in modalità CTR.

4.3 Autenticità

Si è visto come costruire degli autenticatori tramite le funzioni hash, ma questo è possibile anche usando i

cifrari simmetrici in maniera opportuna.

Supponendo di inviare sul canale il messaggio semplicemente cifrato non c’è garanzia che, una volta deci-

frato, esso sia autentico e non modificato. Ciò è possibile solo nel caso di documenti fortemente strutturati,

facendo in modo che una modifica del cifrato generi un messaggio decifrato senza struttura e/o significato.

L’uso di un cifrario simmetrico per garantire l’autenticazione, inoltre, non è efficiente, perché non c’è

immediata disponibilità del dato in chiaro. L’uso di cifrari simmetrici diventa quindi efficiente se, e solo se,

si lavora su messaggi riservati fortemente strutturati e solo fra due destinatari; ciò affinché il possesso della

chiave per cifrare sia la garanzia d’identità.

4.3.1 Message Authentication Code MAC

Per costruire un autenticatore utilizzando un cifrario simmetrico si sfrutta la modalità CBC con vettore

d’inizializzazione impostato a 0 e, l’ultimo blocco (che prende il nome di MAC), viene concatenato al

messaggio come autenticatore.

La soluzione con hash risulta comunque più efficiente, ma entrambe si basano sulla condivisione di un

segreto tra le parti. Essa è quindi un’autenticazione ripudiabile.

4.3.2 Firma digitale

Si è visto come la realizzazione di una firma digitale sia possibile con cifrari asimmetrici in maniera efficiente.

Ciò è tuttavia possibile anche utilizzando cifrari simmetrici, anche se ciò è estremamente complesso ed

inefficiente. Esistono tuttavia cifrari ad hoc per permettere questa soluzione.

Una firma digitale, con valore legale, deve: 26

• consentire a chiunque di identificare univocamente il firmatario;

• non poter essere imitata da un impostore;

• non poter essere trasportata da un documento ad un altro;

• non poter essere ripudiata dall’autore;

• rendere inalterabile il documento su cui è stata apposta.

Per realizzare queste proprietà con cifrari simmetrici è necessaria una terza parte che funga da garante

T

per la firma e, ogni volta che la sorgente vuole mandare un documento alla destinazione si procede

A B

come segue.

1. manda il documento a identificandosi come conserverà quindi il documento garantendo che

A T A. T

sia di A.

2. consegna ad una ricevuta non imitabile che solo può creare, e che dimostra l’autenticità del

T A T

documento.

3. manda il documento a con la ricevuta.

A B

4. verifica presso che il documento sia autentico.

B T

Con questa modalità non potrà mai ripudiare il documento perché l’ha inizialmente depositato presso .

A T

Nell’implementazione di questo protocollo si richiede che ogni entità registrata presso abbia una chiave

T

simmetrica per le comunicazioni. Si procede come:

k

1. cifra il messaggio con la sua chiave e invia per segnalare chi è e per evitare che

A k A∥E (A∥M )

A k A

un attaccante modifichi il messaggio. estrae il messaggio, genera una chiave casuale e salva in un

T R

∥M ∥R∥E ∥M

database in cui l’ultima parte funge da firma.

A∥T (A∥T ),

R ∥M ∥E ∥M

2. risponde inviando in modo che abbia la garanzia che il messaggio

T E (A∥T (A∥T )) A

R

k

A

provenga da . ora decifra tutto eccetto la firma, in modo da controllare anche che il documento

T A

sia stato depositato correttamente. In caso di errore il procedimento ricomincia da capo.

∥M ∥E ∥M

3. Nella trasmissione, invia a per segnalare chi è la sorgente e la terza parte

A B A∥T (A∥T ),

R

verso cui il documento può essere verificato. ∥M ∥E ∥M

4. verifica presso il documento, inviando per segnalare la sua identità e di

B T B∥A∥T (A∥T )

R

chi è il documento che vuole verificare. a questo punto decifra la firma e controlla nel database che

T

tutto sia corretto; ∥M

5. In caso di successo, risponde a con (A∥T ).

T B E

k B T RN G

A∥E (A∥M )

k R

A ∥

E D

M k k

A A DB

k E

k

A R

A ∥M ∥R∥E ∥M

A∥T (A∥T )

R

∥M ∥E ∥M

E (A∥T (A∥T ))

R

k A ∥

D E

k k

A A

∥M ∥E ∥M

A∥T (A∥T ) R

R ∥M ∥E ∥M

B∥A∥T (A∥T )

R

∥ D R

k k

B B B

∥M

E (A∥T )

k

M B

D E

k k

B B

A

Figura 4.5: Implementazione del Registro Atti Privati per firme digitali dei documenti.

Come è possibile vedere in Figura 4.5 questo schema risulta estremamente complesso e richiede una terza

parte che potrà riscontrare onerosi problemi di sovraccarico di operazioni e di protocollo. Per garantire

il non ripudio si prediligono quindi i cifrari asimmetrici che risultano più efficienti. Lavorando con cifrari

simmetrici, inoltre, è richiesto che :

T 27

• sia sempre online;

• non costituisca un collo di bottiglia;

• non crei documenti falsi;

• mantenga le chiavi in una memoria sicura.

4.4 Scambio delle chiavi

Il Key Management è l’area della crittografia che si occupa di come generare, distribuire e distruggere

le chiavi, simmetriche o asimmetriche. Il sistema più sicuro per lo scambio delle chiavi sarebbe un canale

sicuro dedicato, ma questo sistema non è scalabile né automatizzabile. Esistono quindi due modelli:

• con la presenza di un accordo a priori che preveda la condivisione di un segreto iniziale, a partire dal

quale generare le chiavi;

• senza alcun accordo a priori di un segreto iniziale.

4.4.1 Master key

Lo schema master key prevede che ogni coppia di utenti si sia inizialmente scambiata una chiave , la

k

AB

quale prende il nome di master key, su un canale sicuro. Ciò richiede però che il numero di chiavi scambiate,

detto il numero di utenti, sia:

N −

N (N 1) .

2

Per evitare gli attacchi occorre che ogni messaggio sia cifrato con chiavi diverse dalla master key. Queste

k

chiavi possono essere diverse per messaggio oppure cambiare periodicamente. Sul canale sarà quindi posto

k

concatenato con la nuova chiave, la quale sarà cifrata in modalità ECB usando la master key poiché

E (m)

k

si sta cifrando un dato aleatorio.

La durata delle chiavi dipende dal periodo per cui il dato deve rimanere confidenziale: un dato che deve

k

rimanere segreto per molto tempo richiede chiavi sempre diverse, ma, se la riservatezza è molto più limitata

nel tempo, le chiavi possono essere riciclate per più messaggi. La master key avrà invece vita molto più

k

lunga, in quanto viene usata per cifrare dati casuali.

4.4.2 Key Distribution Center KDC

Il modello a master key non riduce il numero di chiavi da distribuire. Per poterlo fare si introduce una terza

parte che prende il nome di Key Distribution Center, la quale permette di distribuire solo chiavi, una

N

per utente. Per ogni sessione di comunicazione, sorgente e destinazione richiedono al KDC una chiave di

k

sessione a singolo uso. Per fare ciò si procede come in Figura 4.6:

∥A∥B

1. manda come primo messaggio con un numero random, la propria identità e con chi vuole

A R

A

parlare. riceve il messaggio, genera una chiave e salva nel database questi dati.

T k ∥B∥k∥E

2. ora sfida per verificare che sia effettivamente chi dice di essere inviando

T A E (R (A∥k))

A

k k

A B

in modo da rendere riservata la chiave perché solo possa decifrarla. Il messaggio ne include anche

A

un altro riservato per il quale contiene la sorgente della comunicazione e la chiave di sessione.

B,

3. Se è chi dice di essere può decifrare la risposta di , salvare la chiave di sessione ed inoltrare il

A T

messaggio a per avviare la comunicazione.

E (A∥k) B

k B

4. Se è chi dice di essere decifra la chiave di sessione e sfida inviando in risposta

B A, E (R ).

B

k

5. che conosce decifra il messaggio e ne dà conferma a inviando o un qualunque

A, k, B, E (R 1)

B

k

altro messaggio fortemente correlato al precedente (ma diverso per evitare attacchi con replica).

28

∥A∥B

R

A

A T

∥B∥k

R A∥k

A

k k

A A E k

k B

B

∥B∥k∥E

E (R (A∥k))

A

k k

A B ∥

D E

k k

A A k

B

E (A∥k)

k B D k

B

k

k E (R )

B

k

D E R

B

k k

k k

R

B −

E (R 1)

B

k

E D

k k

Figura 4.6: Protocollo del KDC per l’avvio di una comunicazione.

I primi due messaggi sono fortemente concatenati fra loro e non replicabili grazie all’uso di . Il terzo

R

A

messaggio è invece suscettibile di replica e non è certo che stia ricevendo i dati da L’attacco con

B A.

replica a può causare DoS oppure, nel caso un intrusore sia risalito ad una chiave precedente, forzare

B B

ad usarla per la comunicazione. Gli ultimi messaggi non possono evitare un attacco con chiave nota, ma

possono evitare che un attaccante forzi a generare tanti campioni cifrati con se questa non è nota.

B k

Il KDC presenta comunque alcuni svantaggi, in quanto:

• è richiesto un overhead da parte sua;

• deve risultare fidato;

• deve sempre essere online;

• può risultare un collo di bottiglia;

• deve avere una memoria sicura in cui salvare i dati.

4.4.3 Scambio di Diffie-Hellman

Questo protocollo, per lo scambio delle chiavi, non utilizza né una terza parte fidata, né un un segreto

pre-condiviso tra le parti, ma si appoggia invece ad un problema difficile della matematica: il logaritmo

discreto.

Fissato un numero primo molto grande e detto un suo generatore (o radice primitiva) modulo

p g

ossia un numero tale che

p, g 2 3 p−1

g mod p, g mod p, g mod p, . . . , g mod p

siano distinti e compresi tra e inclusi; dato un qualsiasi intero è possibile trovare un univoco tale

1 p 1 b i

che ≤ ≤ − ≤ ≤ −

i

b = g mod p, 1 b p 1, 0 i p 1;

prende il nome di logaritmo discreto in base di

i g b.

A partire da queste premesse, il protocollo prevede di scegliere e scambiarli pubblicamente sulla rete

p g,

tra le due parti e quindi di:

A B, ≤ ≤ −

1. Generare le chiavi segrete in maniera casuale in modo che

X 1 X , X p 1.

A B

2. Generare le chiavi pubbliche a partire da quelle segrete come:

Y X X

Y = g mod p, Y = g mod p

A B

A B

ed effettuare il loro scambio in chiaro sulla rete.

29

3. Calcolare la chiave del cifrario simmetrico come:

( ) ( )

X X

X X

X X

A B

A B

k = Y mod p = g mod p, k = Y mod p = g mod p

B A

A B

B A

e le proprietà dell’algebra modulare garantiscono che valga sempre .

k = k

A B

Questo scambio è anonimo e non permette in alcun modo di identificare le parti in causa; esistono

tuttavia varianti che prevedono anche l’identificazione. La sua robustezza è legata alla difficoltà di calcolare

il logaritmo discreto di un numero; in particolare, tale operazione risulta molto complessa quando la base

del logaritmo è un numero primo molto grande.

La variante El Gamal assume che sia stata pre-condivisa , in modo che ci sia autenticazione per

Y B

almeno una delle due parti. 30

Capitolo 5

Cifrari asimmetrici

Un cifrario asimmetrico può essere usato per qualunque requisito di sicurezza: dalla cifratura, ai PRNG

crittograficamente sicuri, passando per i protocolli d’identificazione sfruttando la chiave segreta (nota solo

all’utente) e quella pubblica (nota invece a tutti), ricavata attraverso una funzione unidirezionale da quella

segreta.

Deve sempre essere possibile reperire la chiave pubblica di un utente, e deve esistere un meccanismo che

garantisca che quella chiave appartenga effettivamente ad un certo utente (per garantire non ripudio).

Tutte le quattro trasformazioni già viste (cifratura, decifrazione, firma e verifica) si basano su problemi

difficili della matematica.

Il cifrario RSA, per esempio, si basa sul problema della radice dato un numero prodotto di due

e-esima: n √

∈ Z

numeri primi, un numero coprimo con ed un elemento , trovare un intero tale che e

e Φ(n) c m m = c.

n

Un altro problema difficile a cui esso si appoggia è il problema della fattorizzazione, ossia il trovare i numeri

primi che costituiscono i fattori di un numero n.

La robustezza dei cifrari asimmetrici si basa sulla verifica dell’identità della chiave pubblica: prima di

usarla occorre sempre verificare l’identità del proprietario (oppure esserne certi). Se si lavora all’interno di

un singolo dominio, si potrebbe lavorare con un database in cui salvare la chiave pubblica accoppiata al

nome del proprietario. In questo caso, però, la verifica dell’identità della chiave non è sicura, in quanto non

sussiste alcun meccanismo crittografico che garantisca la sicurezza del database e rilevi eventuali modifiche.

5.1 Distribuzione delle chiavi pubbliche

Per distribuire con sicurezza le chiavi pubbliche ci si appoggia pertanto ad un meccanismo dedicato che

prende il nome di certificato elettronico. Esso sfrutta un ente fidato denominato autorità di certifica-

zione.

Ogni chiave è quindi accompagnata da un attestato (il certificato) per verificarne l’identità: il certificato

contiene quindi l’identità dell’utente, la sua chiave pubblica , una firma digitale dell’hash dell’identità

X k X pub

e la chiave pubblica (al fine di garantire che il messaggio non sia stato modificato):

∥S

X∥k (H(X∥k )),

X CA X

pub pub

in questo modo si trasferisce la fiducia all’autorità di certificazione, la quale deve rilasciare dei certificati

sicuri (che vengono quindi emessi soltanto dietro compenso).

Il certificato di autenticità di una chiave pubblica può essere garantito, come appena visto, da un’en-

tità centralizzata e avere quindi validità legale. È tuttavia possibile appoggiarsi anche ad un modello

decentralizzato.

5.1.1 Standard X.509

Per poter rendere i certificati validi a livello globale, esiste uno standard a cui tutti i certificatori fanno capo.

I certificati devono contenere tutti i dati necessari e, allo stesso tempo, minimizzare la dimensione: i primi

campi sono relativi al certificato come oggetto e a chi l’ha generato:

31

• versione del certificato (quella attuale è la 3);

• numero seriale univoco;

• entità che ha emesso il certificato, algoritmo di firma usato e relativi parametri;

seguono poi i parametri relativi alla chiave garantita:

• periodo di validità della chiave pubblica;

• nome del proprietario della chiave;

• chiave pubblica dell’utente;

si trova infine la firma digitale del certificato stesso, applicata ai campi della chiave pubblica.

Questi sono i campi previsti dalla prima versione. Le successive versioni hanno introdotto campi aggiuntivi

per ulteriori informazioni, non incluse nella firma del certificato, al fine di fornire maggiore flessibilità alle

applicazioni nella gestione del certificato stesso. Esistono delle estensioni standard come l’identificatore

univoco dell’autorità di certificazione e dell’utente; ogni altra estensione è invece contenuta in un determinato

gruppo, a seconda delle informazioni fornite. Alcune delle informazioni che possono essere incluse sono: l’uso

che si farà della chiave, la data di scadenza della chiave privata (dato che il certificato porta solo la scadenza

della chiave pubblica), le politiche di gestione del certificato (per esempio in caso di furto della chiave privata

e identificazione dell’utente). Non esiste tuttavia uno standard per identificare le procedure.

5.1.2 Ciclo di vita dei certificati

Durante e dopo l’emissione dei certificati occorre gestire correttamente le interazioni tra le entità della

Public Key Infrastructure PKI: l’utente deve interagire con la Registration Authority RA, la

U

quale richiede alla Certification Authority CA l’emissione del certificato. Ogni utente deve poi poter

accedere al database per recuperare i certificati e verificarli.

Esistono quindi vari protocolli per l’inizializzazione:

• richiesta del certificato;

• rilascio del certificato;

• pubblicazione del certificato;

e altri per lavorare con il certificato:

• recupero del certificato;

• richiesta di revoca del certificato;

• approvazione di revoca;

• pubblicazione di informazioni offline e online.

L’unico canale sicuro è quello tra la CA e la RA, tutti gli altri canali sono insicuri. Il database dei certificati

è gestito come una directory, quindi estremamente scalabile, replicabile e a rapido accesso. Il protocollo

di riferimento è X.500, nel quale i Directory Service Agent DSA si coordinano tra loro per recuperare

l’informazione, a prescindere da quale venga interrogato. Questo protocollo è tuttavia estremamente oneroso,

per cui si utilizza LDAP che però non è trasparente al recupero dell’informazione. Se il DSA è interrogato

e non ha l’informazione, restituisce un riferimento ad un altro da interrogare e la nuova richiesta è a carico

dell’utente.

5.1.2.1 Richiesta di un certificato

Per richiedere un certificato occorre un protocollo sicuro che permetta di scambiare i dati necessari. Per

fare questo è necessario identificare il richiedente, garantire l’integrità del messaggio e richiedere una prova

di possesso della chiave pubblica, al fine di evitare che venga registrata la chiave pubblica di qualcun altro.

Prima di richiedere un certificato, però, l’utente deve registrarsi presso una RA e una CA. Per assicurarsi

che l’utente possieda la chiave privata corrispondente a quella pubblica si potrebbe affidare alla CA la

32

generazione della coppia di chiavi. In questo caso, però, l’utente non sarà l’unico a conoscere la chiave

privata, la quale non potrà quindi avere validità legale.

Il protocollo effettivamente usato prevede tre modalità:

1. L’utente genera la coppia di chiavi e presenta le proprie credenziali ad una RA. L’RA inoltra la richiesta

ad una CA, la quale genera il certificato per la RA, la quale lo inoltra all’utente. Ciò può essere fatto

secondo diverse modalità:

a. L’utente si presenta fisicamente alla RA che lo identifica secondo le sue procedure. La RA conse-

gna un modulo crittografico all’utente, il quale avvia la generazione delle chiavi (che rimarranno

in suo possesso esclusivo). Sempre in compresenza con la RA, l’utente può inviare la propria

chiave pubblica alla RA stessa, per poi comunicare con la CA. In questo modo è presente una

grande sicurezza sull’identità dell’utente e su chi conosce le chiavi, tuttavia si ha lo svantaggio

che l’utente debba stare, per un certo periodo di tempo, presso la RA, la quale durante questo

periodo non può gestire altre richieste.

b. La RA prepara un modulo crittografico con una coppia di chiavi pre-generate, consegna il modulo

all’utente dopo l’identificazione, quindi procede alla registrazione presso la CA. Questa modalità

permette di parallelizzare maggiormente la registrazione, tuttavia non si ha garanzia che la RA

non abbia, in precedenza, eseguito una copia della chiave privata.

2. L’utente si registra presso la RA e riceve un identificatore univoco condiviso tra la RA e l’utente.

Quest’ultimo, in un secondo momento, può quindi usare un software crittografico per inviare una

richiesta di certificato da remoto alla CA, utilizzando l’identificatore ottenuto in precedenza. Si userà

quindi un protocollo, tra l’utente e la CA, che deve coinvolgere l’uso dell’autenticatore rilasciato e la

chiave privata al fine di garantirne il possesso: ))

( (

∥S H(A∥k ) .

A∥E k Apub

Apub k Apriv

3. L’utente genera le chiavi e richiede un certificato direttamente alla CA, la quale si appoggia quin-

di alla RA per le dovute verifiche. Questo modello è solitamente non utilizzato, perché richiede il

coinvolgimento della CA per tutte le richieste.

Per le chiavi di firma è indispensabile fornire alla RA una prova di possesso della chiave privata corri-

spondente. Per questo motivo la CA si tutela legalmente a priori, emettendo il certificato soltanto se in

quel momento il richiedente ha la chiave privata e può fornire una prova del suo possesso. Una soluzione

alternativa prevede di fornire la prova di possesso al momento della firma del documento, richiedendo quindi

un protocollo applicativo dedicato che risulta più pesante e non attualmente supportato. Per le chiavi di

cifratura, invece, questa prova non è richiesta.

5.1.2.2 Revoca di un certificato

Durante la vita naturale del certificato può capitare che ci si trovi impossibilitati ad utilizzare la chiave

privata perché, ad esempio, viene perso il PIN di accesso alla smart card dove era salvata oppure la chiave

privata viene rubata da terze parti che si trovano quindi in grado di firmare come se fossero altri.

Qualunque sia il motivo, il possessore di un certificato può, in qualunque momento, chiederne la revoca

e la CA, non appena riceve questa richiesta, deve comunicare a tutto il dominio da lei amministrato che

il certificato non è più valido. Come si è visto i certificati sono salvati in una directory pubblica e per

comunicare a tutti gli utilizzatori le variazioni si possono usare due modelli:

• Pull: viene distribuita in una repository pubblica l’informazione che il certificato è stato revocato,

sarà poi compito degli utenti controllare che il certificato sia valido ogni volta che viene usato.

• Push: secondo un modello publish-subscribe, ogni utente specifica i certificati di interesse e la CA si

incarica di segnalare a tutti gli interessati ogni cambiamento sui certificati.

Un modello push risulta molto oneroso per la CA, che deve in questo modo anche tenere traccia di dove

si trovino gli utenti per poter inoltrare la segnalazione di revoca. Per questo motivo, solitamente ci si

33

appoggia quindi ad un modello pull e si utilizza il push solo per certificati estremamente sensibili. I modelli

di notifica di revoca si distinguono anche a seconda del fatto che permettano, o meno, la verifica offline o

online, richiedendo una connessione tra gli utenti finali e la CA.

5.1.2.2.1 Certificate Revocation List CRL Questo modello di notifica è un modello pull che permette

anche una verifica offline della validità del certificato. La CA ha il compito di costruire una struttura dati

detta lista di revoca in cui compaiono i certificati non più validi. Essa viene distribuita su una directory

pubblica a cui gli utenti dovranno accedere per verificare lo stati dei certificati.

Come nel caso di un certificato, la struttura dati deve essere autentica e integra. Essa è pertanto firmata

e contiene:

• algoritmo e parametri di firma;

• nome di chi l’ha rilasciata;

• data di rilascio e prossima data di rilascio. Questi due campi permettono di definire l’intervallo

temporale di validità della lista di revoca stessa e ogni quanto questa verrà aggiornata con eventuali

nuove informazioni;

• numero seriale univoco del certificato revocato e data di revoca. Questi due campi sono ripetuti per

ogni certificato contenuto nella lista;

• estensioni per informazioni aggiuntive;

• firma della lista.

La CRL è pubblicata sulla directory pubblica e, ogni volta che l’utente deve verificare un certificato, deve

scaricarla e controllare se contiene o meno il numero seriale del certificato che ha intenzione di usare. Questo

metodo permette di effettuare verifiche offline, perché durante il periodo di validità della CRL stessa si ha

la garanzia che questa non cambi sulla directory. Questo intervallo di aggiornamento, tuttavia, rappresenta

anche uno svantaggio, perché non permette un aggiornamento in tempo reale dello stato di revoca. Si può

sempre ridurre l’intervallo di aggiornamento, ma se diventa troppo piccolo risulta più conveniente utilizzare

altri modelli.

Ad ogni aggiornamento, la CLR cresce, occupando quindi più spazio sulla directory. Essa deve essere

scaricata, memorizzata da ogni utente e utilizzata per effettuare la ricerca dei numeri seriali dei certificati;

ciò aumenta quindi il tempo di ricerca. Esistono diverse soluzioni per migliorare la gestione della CRL in

crescita:

• Eliminare la revoca a partire dalla prima CRL successiva alla scadenza naturale del certificato. Dopo

questa data, infatti, il certificato non dovrebbe essere usato. Questa soluzione non viene quasi mai

adottata perché la durata dei certificati è molto grande e, pertanto, permetterebbe una piccolissima

ottimizzazione.

• Rilasciare gli aggiornamenti in maniera incrementale, pubblicando una Base CRL e successive Delta

CRL. Questa soluzione non riduce lo spazio occupato sulla directory, ma permette di ridurre la banda

in download in quanto, ogni volta, occorre scaricare le Delta CRL mancanti. In verifica di un certificato

che non compare nella CRL già scaricata, inoltre, si potrebbe scaricare una delta per volta e controllare

se il certificato è contenuto in quanto scaricato prima di passare alla delta successiva.

• La CRL viene partizionata secondo un certo criterio scelto dalla CA. Ancora una volta, l’occupazione

di spazio sulla directory non cambia ma, se la tecnica di partizionamento è stata scelta in maniera

opportuna, risulta possibile scaricare solo la partizione in cui il certificato sarebbe incluso se revocato.

Ciò limita l’occupazione di banda e lo spazio di ricerca una volta scaricato. Ciò è solitamente realizzato

aggiungendo, al certificato stesso, un’estensione che prende il nome di CRL Distribution Point

CRL-DP. Essa specifica la partizione della CRL in cui sarà inserito, garantendo che non sarà mai

inserito in altre partizioni.

5.1.2.2.2 Online Certificate Status Protocol OCSP Questo protocollo permette ad un utente di

contattare una terza parte fidata, anche diversa dalla CA, per chiedere se un determinato certificato è

ancora valido. Il server risponderà con un messaggio firmato che contiene lo stato del certificato.

34

Il server OCSP, che deve essere sempre online, avrà meccanismi propri per determinare lo stato del

certificato. Questi meccanismi non sono vincolati dal protocollo e possono, per esempio, appoggiarsi alle

liste di revoca o a meccanismi in tempo reale.

Il server è solitamente delegato dalla CA quindi, per firmare i messaggi, potrebbe usare chiavi sia uguali

che diverse da quelle della CA.

5.1.3 Valutazione e organizzazione della PKI

Ogni sistema progettato per la verifica dei certificati dovrà essere valutato a livello di prestazioni secondo

vari criteri:

• Tempestività nel fornire aggiornamenti sulla revoca dei certificati. Le CRL non risultano molto forti

in questo aspetto, poiché gli aggiornamenti vengono recapitati ad intervalli regolari.

• Carico computazionale di tutte le entità coinvolte, dalla CA per l’emissione della notifica fino

all’utente, il quale deve memorizzare le strutture dati ed effettuare ricerche al loro interno.

• Occupazione di banda.

• Scalabilità: le CRL, fondamentalmente, non sono scalabili, tuttavia l’uso del partizionamento le

rende tali.

• Sicurezza: la struttura dati che l’utente utilizza per verificare lo stato di un certificato deve essere

autentica, integra, confidenziale e non ripudiabile. Per le CRL la confidenzialità non è garantita,

ma non è nemmeno richiesta; occorre quindi privilegiare i soli parametri effettivamente necessari per

fornire maggiore efficienza.

• Standard: è utile che il meccanismo usato si appoggi a strutture dati standardizzate.

• Espressività: la revoca di un certificato è solitamente accompagnata dall’istante in cui tale certificato

è stato revocato e per quale motivo, ma può essere utile permettere di fornire più informazioni.

• Automatizzazione dello schema.

• Verifica online o offline.

In una PKI la gestione delle chiavi è, come si è visto, affidata ad una CA. Essa registra le informazioni in

una directory sotto forma di entry, le quali utilizzano delle classi standardizzate per rappresentare utenti,

CA e liste di revoca, sia con partizionamento che con CRL incrementali (e molto altro).

In conclusione, è possibile identificare un sistema come PKI se integra:

• CA;

• cross-certificates;

• aggiornamento automatico delle chiavi, ossia permette di generare automaticamente nuove chiavi

per un certificato che si sta avvicinando alla scadenza piuttosto che lasciarlo scadere, quindi generarne

uno nuovo (avendo perciò un periodo in cui non esiste il certificato);

• non ripudio delle firme digitali;

• database dei certificati;

• cronologia delle chiavi;

• backup e recovery delle chiavi usate per la sola cifratura;

• revoca dei certificati;

• timestamping.

5.2 Modelli di fiducia

Per ora ci si è concentrati su un solo dominio di certificazione, ma a livello globale esistono molte CA che si

coordinano tra loro, permettendo ad utenti appartenenti a domini diversi di inter-operare fra loro.

35

Ogni utente può verificare i certificati degli altri utenti del suo stesso dominio utilizzando la chiave pubblica

della propria CA. Ma come fa un utente ad ottenere in maniera sicura questa chiave?

Nella directory è salvato, oltre ai certificati degli utenti, anche quello della CA, che risulta firmato con

la chiave privata corrispondente a quella pubblica che contiene, ossia è auto-firmato. Questo certificato

viene consegnato, in maniera sicura all’utente durante la fase di richiesta del certificato, al momento della

consegna della smart card oppure come messaggio di completamento del protocollo di richiesta online.

5.2.1 Coordinamento tra CA

Ogni CA può rendersi garante di una o più altre CA, rilasciando in questo modo un certificato detto cross-

certificate. In questo processo, essa firma la chiave pubblica dell’altra CA con la propria chiave, portando

la CA ad assumersi varie responsabilità poiché vincola ad accettare come valido ogni certificato firmato con

la chiave dall’altra CA e, quindi, ogni elemento firmato con le chiavi dei suoi utenti.

Per verificare un certificato di un utente di un altro dominio occorre partire dalla propria CA e cercare

un cammino di certificazione fino a giungere all’altra CA. Se tutti i certificati lungo questo cammino sono

validi si può allora ritenere valido il certificato (a patto che non sia stato revocato o sia scaduto).

∈ ∈

Esempio 5.1 Sia , e riceve una mail fir-

U CA U CA U

1 5 2 3 1 CA CA

mata da con allegata la sua chiave pubblica firmata da . Per 3 5

U CA

2 3

verificare la firma, dovrà quindi controllare che la chiave pubblica

U

1

ricevuta sia autentica. Per fare ciò esso interroga la propria CA al CA CA CA

1 2 4

fine di ottenere ogni cross-certificate rilasciato. Ad ogni CA così indi-

viduata viene nuovamente chiesto quali altre CA essa certifica, fino a Figura 5.1: Relazioni di fiducia tra

trovare, o meno, un cross-certificate. Ciò avviene fino a , da cui si

CA 3 CA: le frecce partono da quella che ri-

ottiene la chiave pubblica, si verifica la chiave pubblica di e infine

U

2 lascia un cross-certificate e terminano

l’email. In questo caso, facendo riferimento alla Figura 5.1, si ottiene in quella a cui viene data fiducia dal

e poi, interrogando il dominio di questa, la

prima la chiave di CA certificato.

4

chiave di .

CA 3

Si nota come ciò risulti essere un problema di ricerca di un nodo in un grafo, pertanto può risultare più

semplice o più difficile a seconda di come le CA risultano organizzate fra di loro. Ognuno dei cross-certificates,

inoltre, non deve essere scaduto né revocato, pertanto esiste un meccanismo di notifica di revoca parallelo

per i cross-certificates, solitamente gestito con liste di revoca del tutto identiche a quelle per i certificati

normali, le quali però prendono il nome di Authority Revocation List ARL. È inoltre possibile anche

complicare la validazione quanto lo si desideri, per esempio valutando le politiche di emissione dei certificati

per verificare che essi siano sufficientemente sicuri. Si può, per esempio, scegliere di ritenere non validi

certificati rilasciati solo sulla base delle informazioni anagrafiche prive di controlli, quindi richiedere almeno

la verifica di queste e delle impronte digitali.

Il cammino di certificazione può partire, come si è visto, dalla propria CA, ma è possibile che sul sistema di

verifica siano installati altri certificati di Root Certification Authority. Essi risultano auto-firmati e ven-

gono assunti come autentici e fidati, permettendo quindi di usarli come radici di un cammino di certificazione.

Sulla base di un modello completamente distribuito, la struttura che rende più semplice il problema del

ritrovamento del cammino è l’organizzazione gerarchica ad albero, nella quale ogni nodo certifica i suoi figli

che, a loro volta, certificano il padre. Dal punto di vista tecnico, questo modello permette di ricostruire

facilmente il cammino e risulta facilmente scalabile. Sorgono tuttavia problemi organizzativi tra le CA, in

quanto la radice dell’albero si troverebbe ad avere molte più responsabilità e, spesso, le CA non possono

essere organizzate gerarchicamente.

Sulla base di questa struttura è inoltre possibile aggiungere altri cross-certificate, al fine di rendere più

facile la ricerca dei cammini. 36

5.3 Sicurezza delle reti

Si è visto come lo scambio di Diffie-Hellman (§ 4.4.3) permetta di concordare un segreto comune, ma presenti

il problema di non poter identificare l’entità con cui si sta dialogando. Per sopperire a tale problema vengono

in sostegno i certificati.

Come prima cosa, per randomizzare al meglio il segreto condiviso che viene concordato si introduce una

variante dello scambio. Essa prevede di scambiare inizialmente due numeri casuali e tra le parti,

R R

A B

quindi generare normalmente gli e gli . Successivamente alla generazione della chiave condivisa che

X Y k,

∥R

ora prende il nome di pre-master secret, si calcola quindi il master secret condiviso come H(k∥R ).

A B

Per garantire l’autenticazione si possono quindi seguire due modalità:

• Fixed: prevede l’uso di un certificato autenticato da una CA che garantisce l’autenticità di p, g

e (o ); in questo modo si utilizza sempre la stessa chiave. All’inizio della sessione e

Y Y A B

A B

si scambieranno i rispettivi certificati, assumendo che abbiano stesso e quindi si procede come

p g,

illustrato in precedenza a generare la chiave condivisa sfruttando anche i numeri casuali scambiati

all’inizio. Sebbene ogni parte invii il proprio certificato, non si avrà la garanzia che esse ne abbiano

il possesso legittimo, pertanto alla fine del protocollo non si avrà autenticazione. Per come la chiave

condivisa è stata calcolata, però, si ha la certezza che, se invia un certificato non suo, non potrà mai

A

generare la chiave per decifrare quanto inviato da non si garantisce però che non invii dati se

B; B A

non è chi dice di essere. A seconda del contesto applicativo, ciò può costituire un problema o meno.

• Ephemeral: i valori non sono fissati dal certificato, il quale invece garantisce semplicemente l’au-

Y

tenticità di una chiave pubblica scollegata dallo scambio di Diffie-Hellman. Il processo ha inizio con lo

scambio di e (in alternativa possono essere già concordati), quindi vengono normalmente generati

p g

e . e si scambiano quindi e , firmati con la rispettiva chiave privata e in allegato il

X Y A B Y Y

A B

certificato. Una volta ricevuto l’Y della controparte e verificata la firma, si procede alla generazione

della chiave condivisa e del suo hash con i numeri casuali scambiati all’inizio (come nel caso prece-

dente). Questo ultimo passaggio non è necessario in questo caso, ma viene eseguito per compatibilità.

Nel caso venga praticato un attacco con replica in cui un intrusore invii un precedente messaggio di

il protocollo terminerà normalmente ma, come nel caso precedente, non si arriverà a concordare la

A,

stessa chiave, perché non conosce . Questo modello risulta tuttavia più scalabile del precedente, in

X

A

quanto non vincola la scelta di e a un certificato.

p g

5.3.1 SSH

Il protocollo SSH si appoggia allo scambio di Diffie-Hellman per la generazione della chiave di sessione tra

il client ed il server come:

C S X

X e

1. Il client genera ed invia , il server lo riceve, genera , calcola S mod p

mod p k = Y

Y X Y = g S

C S S C

ed infine calcola l’hash della concatenazione di vari parametri di protocollo, , , e

H k Y k.

Y

S C S

pub X

2. Il server risponde con , e il client preleva e calcola la sua C

k Y S (H), Y k = Y mod p.

S S S

k

pub S

S priv

Quando il client riceve la risposta è in grado di verificare la parte firmata del messaggio per garantire

che sia autentico. A questo punto, una volta estratto con la garanzia che sia stato creato dal

H

server, il client ricostruisce il contenuto dell’hash e lo ricalcola, per verificare che sia corretto e sia

stato generato per l’Y della sessione corrente. Ciò permette di evitare attacchi con replica.

C

Questo protocollo non esegue alcuna verifica sull’identità del server, ma assicura unicamente che si stia

dialogando con il legittimo possessore della chiave pubblica che viene comunicata. L’autenticazione è presente

solo se il client è già a conoscenza della chiave pubblica del server, la quale quindi deve essere scambiata

fuori banda. Queste operazioni aggiuntive non garantiscono l’autenticazione e, di fatto, risultano inutili. Se

il server non è chi dice di essere, infatti, si arriva semplicemente a generare una chiave diversa.

k

37

Capitolo 6

Crittografia a chiave pubblica

La crittografia a chiave pubblica si basa, come già visto, sull’uso di problemi difficili della matematica e su

insiemi numerici dotati di regole precise, al fine di garantire la robustezza del cifrario.

6.1 Richiami di algebra modulare

Ci si concentrerà ora sull’algoritmo RSA che, oltre che sulle definizioni note di divisore, numero primo,

fattorizzazione, modulo e massimo comune divisore, si basa su:

• Coprimi o relativamente primi: due numeri sono coprimi se il loro massimo comune divisore è 1.

• Congruenza: un numero è congruo a modulo e si indica con se

a b n a b (mod n) a mod n = b mod n.

Esso si basa inoltre sugli insiemi:

Z {0, −

• che risulta un anello rispetto a somma e moltiplicazione in modulo

= 1, . . . , n 1} n.

n

Z {a ∈ Z |MCD(a,

• ossia l’insieme dei coprimi con strettamente minori di Un caso

= n) = 1}, n n.

n

n ∗

Z {1, −

particolare si ha quando è un numero primo e, in questo caso, si ha cioè tutti

n p = . . . , p 1},

p

Z

gli elementi non nulli di , in quanto MCD(p, 0) = p.

p

• Funzione totiente di Eulero, ossia il numero di interi minori di e coprimi con

n n:

( )

) (

1 1

···

− −

1 ,

n 1

Φ(n) = p p

1 k

dove sono i primi che compongono la fattorizzazione di e si ha:

p n

k −

– se è primo;

Φ(n) = n 1 n

− −

– se è il prodotto di due primi e

Φ(n) = (p 1)(q 1) n p q.

Riprendendo le nozioni di algebra e geometria, si definisce gruppo finito un insieme finito di elementi

G

·

su cui è possibile definire un’operazione binaria moltiplicazione che associa, ad ogni coppia degli elementi,

un terzo elemento sempre appartenente all’insieme. Ciò è vero se vale:

∈ · ∈

• Chiusura: se allora anche

a, b G a b G.

· · · · ∀a, ∈

• Associatività: a (b c) = (a b) c, b, c G.

∃e ∈ · · ∀a ∈

• Identità: ed prende il nome di elemento neutro dell’operazione.

G, a e = e a = a, G e

∀a ∈ ∃b ∈ · ·

• Inverso: G, G, a b = b a = e.

Si definisce gruppo abeliano un gruppo finito la cui operazione binaria gode anche della proprietà

· · ∀a, ∈

commutativa, ossia a b = b a, b G.

Si definisce gruppo ciclico un gruppo abeliano in cui esiste un elemento fisso, detto generatore. Tutte

le potenze con esponente intero di questo elemento appartengono all’insieme, ed ogni elemento del gruppo

ciclico è una potenza del generatore.

Si definisce anello un gruppo ciclico in cui si definisce un’ulteriore operazione binaria somma la quale

+,

gode di tutte le proprietà già viste per la moltiplicazione:

38

• chiusura;

• associatività;

• identità;

• inverso;

• la moltiplicazione è distributiva rispetto alla somma.

Si definisce infine campo un anello in cui ogni elemento diverso dall’elemento neutro della somma ha

inverso moltiplicativo. 4.4.3) si è visto come occorra scegliere dei numeri appar-

In relazione allo scambio di Diffie-Hellman (§ Z

tenenti al campo di Galois, definito a partire dall’insieme , nel quale, sulla base della proprietà di

p

congruenza, vale:

• (a + b) mod m = ((a mod m) + (b mod m)) mod m;

· ·

• (a b) mod m = ((a mod m) (b mod m)) mod m.

Queste proprietà risultano molto utili per gestire operazioni tra numeri molto grandi, poiché risulta infatti

possibile eseguire la stessa operazione tra numeri più piccoli, previa esecuzione del modulo.

Rispetto alle semplici operazioni di trasposizione e sostituzione, l’esponenziazione risulta molto costosa.

Ad ogni moltiplicazione, infatti, il range di valori su cui essa opera continua ad aumentare, per cui, ad ogni

passo, l’efficienza degrada. Poiché si lavora però su un campo di Galois è possibile applicare, in algebra

modulare, le proprietà appena viste, per scrivere: · · ·

· · · ·

e modm = ((b mod m)(b mod m) (b mod m)) modm,

a = b mod m = (b b b)

{z } | {z }

| e volte e volte

in questo modo si è ridotto il range di valori su cui si opera di volta in volta. Per ridurre il numero di

operazioni occorre utilizzare un altro metodo: il generatore del gruppo ciclico. Siccome si devono ottimizzare

tali operazioni per un computer, ci si appoggia alla rappresentazione binaria: assumendo di dover calcolare

53 , si ha che Si ottiene quindi:

g 53 = 110101 = 32 + 16 + 4 + 1.

10 2 53 32 16 4 1

g = g g g g , 4

Si può inoltre ridurre ulteriormente il numero di operazioni riciclando il risultato finale di , per esempio

g

per calcolare le potenze maggiori.

e

Formalizzando, per calcolare si procede trasformando in rappresentazione binaria l’esponente

b mod m,

i

quindi si calcolano i , dove sono i soli bit dell’esponente non a 0, si moltiplicano quindi fra loro e si

e, b i

calcola il modulo secondo Se l’esponente ha tutti i bit impostati a 1 non si ha alcun miglioramento, ma

m.

se alcuni sono impostati a 0 si ha una riduzione del numero di moltiplicazioni. Questo algoritmo prende

quindi il nome di repeated squaring: si inizializza il risultato parziale a e il valore corrente a quindi ad

1 b,

ogni passo (cioè per ogni bit) si moltiplica il risultato parziale per il valore corrente se questo è a 1, quindi

si calcola il quadrato del valore corrente per prepararsi al passo successivo.

Un secondo algoritmo, detto repeated square and multiply, si basa su quanto appena illustrato, ma

permette di ridurre ulteriormente il range di valori utilizzati. Ciò è ottenuto eseguendo l’operazione di

modulo ad ogni moltiplicazione, sia del risultato parziale, sia del valore corrente, invece che solo alla fine.

32

Questo algoritmo permette in questo modo di eseguire moltiplicazioni con una media di dove è

t + n t, t

il numero di bit dell’esponente e il numero di bit a 1.

n

6.2 Numeri primi

È stato dimostrato che i numeri primi hanno una certa distribuzione e che, per un numero molto grande x,

ln x

è certo trovare un numero primo in un suo intorno di ampiezza In al massimo tentativi quindi, per

ln x. 2

escludere i numeri pari, si ha la certezza di trovare un numero primo.

Per realizzare ciò si utilizzano i test di primalità, i quali possono essere sia deterministici (e molto

onerosi) o probabilistici (che invece hanno una complessità polinomiale). Il test più comunemente utilizzato

è il test di Miller e Rabin. 39

6.3 Cifrari asimmetrici

Qualunque sia l’algoritmo che si sta utilizzando, a prescindere dalla funzione per cui lo si utilizza, sono

previsti sempre tre algoritmi:

• algoritmo di generazione delle chiavi, legate fra di loro da una funzione unidirezionale;

• algoritmo di firma o cifratura, o, come nel caso di RSA, entrambe;

• algoritmo di verifica o decifrazione.

Questi sono sempre impiegati secondo 5 principi:

1. frammentazione del testo in chiaro;

2. aleatorietà del testo cifrato;

3. variabilità della trasformazione;

4. problema difficile su cui si basa la sicurezza;

5. modalità di impiego.

6.3.1 Frammentazione del testo in chiaro

Per garantire che vi sia una corrispondenza biunivoca tra il testo in chiaro e il cifrato, poiché si lavora in

algebra modulare, occorre che il testo in chiaro sia frammentato in blocchi di valore strettamente inferiore

al modulo. Se così non fosse si avrebbe il rischio che messaggi diversi abbiano lo stesso testo cifrato.

Si può quindi utilizzare un cifrario asimmetrico per cifrare effettivamente un testo con un cifrario a blocchi,

oppure per implementare un PRNG da utilizzare per un cifrario a flusso.

6.3.2 Determinismo e probabilismo

Un cifrario è detto deterministico se a messaggi in chiaro uguali corrispondono testi cifrati uguali (è il

caso di RSA). Questo tipo di cifrario risulta vulnerabile a certi tipi di attacchi, pertanto occorre adottare

tecniche specifiche che permettano di renderlo probabilistico, ossia non deterministico.

Ciò può essere realizzato aggiungendo non determinismo al messaggio in chiaro, per esempio concatenan-

dolo ad un numero casuale, oppure, in maniera analoga ai cifrari simmetrici, sfruttando diverse modalità di

applicazione dell’algoritmo.

6.3.3 Modalità di impiego

Per implementare in maniera interoperabile diversi tipi di algoritmi occorre seguire gli standard PKCS, i

quali dettano il formato dei messaggi per il rispettivo algoritmo.

6.4 Cifrario RSA

Nel cifrario RSA la chiave pubblica è costruita a partire da due numeri ed è ottenuto come prodotto

n e. n

di due numeri primi e mentre deve essere coprimo con la funzione totiente di Eulero di

p q, e n Φ(n) =

−1

− − La chiave privata, invece, è composta dallo stesso e

(p 1)(q 1). n d = e mod Φ(n). ≤

k k+1

Per cifrare, quindi, si prende il messaggio e lo si suddivide in blocchi di bit, con , quindi

m k 2 < n 2

e

si cifra ogni blocco come L’operazione inversa a questa operazione è la radice che

c = m mod n. e-esima,

risulta essere computazionalmente complessa. Il possesso della chiave privata, tuttavia, permette di poter

d

eseguire una seconda esponenziazione che permette di ottenere il testo in chiaro in quanto

m = c mod n d

è inverso moltiplicativo di Ciò è vero perché si dimostra, se come specificato in precedenza, che:

e. m < n

≡ ≡

d e

c mod n m mod n m.

40

Il cifrario RSA gode della proprietà di reversibilità: come già accennato è possibile utilizzarlo sia per

cifrare che per decifrare invertendo semplicemente l’uso delle chiavi nelle due operazioni.

6.4.1 Generazione delle chiavi

Per generare la coppia di chiavi si procede come segue:

1. genero due numeri primi molto grandi e

p q;

·

2. calcolo n = p q; − −

3. calcolo Φ(n) = (p 1)(q 1);

4. cerco un intero coprimo con utilizzando l’algoritmo di Euclide per verificare che il loro massimo

e Φ(n),

comune divisore sia 1; −1

5. calcolo inverso moltiplicativo di come

d e d = e mod Φ(n);

si è quindi generata la chiave pubblica e la chiave privata

(e, n) (d, n).

L’algoritmo di Euclide e quello di Euclide esteso permettono di trovare facilmente e, al contempo, di

e

determinare è fondamentale che il numero sia coprimo con altrimenti verrebbe meno la robustezza

d: e Φ(n),

dell’algoritmo.

6.4.2 Aspetti computazionali

Per ottimizzare gli algoritmi di cifratura e decifrazione occorre ridurre i tempi di elaborazione. Per realizzare

ciò si sfrutta l’algoritmo repeated square and multiply, mentre in decifrazione si sfruttano le proprietà della

chiave privata per applicare il teorema cinese dei resti.

Per quanto concerne la generazione della chiave, le parti più complesse risultano essere: i calcoli dei numeri

primi e il trovare e calcolarne l’inverso moltiplicativo. In questo caso però la chiave è generata una

p q, e

sola volta, pertanto ciò non costituisce un problema.

Nella scelta di si possono operare delle considerazioni atte ad ottimizzare la cifratura, per esempio

e

scegliendo dei valori con pochi 1 nella rappresentazione binaria (sulla base di quanto visto in precedenza).

Alcuni di questi valori comodi, tuttavia, possono anche permettere attacchi di analisi statistica facilitati.

16

Molte implementazioni procedono quindi a fissare ma occorre che la scelta fatta sia tale da

e = 2 1,

permettere poi di trovare un tale che

n MCD(e, Φ(n)) = 1.

6.4.3 Tipologie di attacchi

6.4.3.1 Forza bruta

È possibile tentare tutti i valori della chiave privata per riuscire a decifrare il testo. Se fosse possibile

solo questo tipo di attacco la chiave pubblica avrebbe bisogno di soli ma non è così, pertanto sono

128 bit,

richiesti, ad oggi, 2 048 bit.

6.4.3.2 Attacchi matematici

Il secondo problema difficile della matematica in RSA è la fattorizzazione. Senza avere a disposizione e

p q,

e quindi infatti risulta computazionalmente impossibile calcolare e ciò è tanto più difficile quanto

Φ(n), d,

più è grande.

n

6.4.3.3 Attacchi a tempo

Basandosi solo sul testo cifrato si è dimostrato che, analizzando il tempo di decifrazione, è possibile dedurre

informazioni sulla chiave. Questo tipo di attacco risulta molto difficile da realizzare e, per contrastarlo in

maniera più efficace riducendone la probabilità di successo, si utilizza la tecnica di blinding, la quale attua

una trasformazione al testo cifrato come: 41

′ · e

• ;

c = c r

′ ′ d

• m = (c ) mod n;

′ −1 −1

·

• con inverso moltiplicativo di in modulo

m = m r mod n, r r n.

6.4.3.4 Testo cifrato scelto

Se il testo cifrato è a scelta dell’attaccante (magari con anche quello in chiaro noto), risulta possibile dedurre

informazioni sulla chiave. È possibile contrastare questo tipo di attacco utilizzando una tecnica di padding

non deterministico detto OAEP.

6.4.4 Cifrario ibrido

Per cifrare messaggi di grosse dimensioni non è una buona idea utilizzare un cifrario asimmetrico, in quanto

esso comporterebbe una perdita di tempo nei processi di cifratura e decifrazione. Occorre quindi utilizzare

un cifrario simmetrico, pertanto si ha la necessità di scambiare la chiave in uno dei modi visti in precedenza

(§ 4.4). In alternativa, è possibile far uso di un cifrario ibrido, ossia di un cifrario in cui si cifra la chiave

simmetrica a con la chiave pubblica a del destinatario. Viene quindi cifrato qualcosa di

k 128 bit 2 048 bit

molto più piccolo della chiave pubblica secondo i vincoli specificati.

Inviare equivale però ad inviare in chiaro perché, essendo la chiave pubblica nota, è possibile

E (k) k

k

B pub

eseguire un attacco di forza bruta sui valori di quindi verificare con la chiave pubblica se la sua cifratura

k,

è uguale a quella trasmessa. Se è molto piccolo occorre quindi trasformarlo opportunamente prima di

k

cifrarlo con la chiave pubblica, eseguendo:

• concatenazione opportuna di un numero casuale secondo gli standard PKCS#1;

• uso del padding OAEP. k

B pub k

B priv

E

k k

B pub D k

B priv

c

1

m E

k c m

D

2 k

Figura 6.1: Schema del cifrario ibrido.

6.4.5 Firma digitale

Si è visto come risulti estremamente complesso realizzare un sistema di firma digitale che garantisca non

ripudio utilizzando solo la crittografia simmetrica (§ 4.3.2). Ciò risulta invece molto più facile se si utilizza

la crittografia asimmetrica, garantendo i seguenti requisiti:

1. Consentire a chiunque di identificare univocamente il firmatario: ciò è possibile assumendo che la

chiave privata, usata per la firma, sia disponibile solo al legittimo proprietario. La relativa chiave

pubblica è infatti distribuita pubblicamente, certificata e autenticata attraverso una CA secondo le

leggi in vigore in ogni paese.

2. Non deve poter essere imitata.

3. Non deve poter essere utilizzata su altri documenti.

4. Non deve poter essere ripudiata dall’autore.

5. Deve rendere inalterabile il documento a cui è applicata.

42

Da un punto di vista crittografico la firma digitale è supportata dagli algoritmi RSA, El Gamal, DSA e

altri. Nel caso di RSA si ha una firma con recupero in quanto si autentica l’intero messaggio, eseguendo

semplicemente l’operazione di cifratura utilizzando la chiave privata (nota quindi come firma), ed eseguendo

la decifrazione utilizzando la chiave pubblica (che prende quindi il nome di verifica). Gli altri algoritmi

citati, invece attuano una firma con appendice in quanto viene firmato l’hash del messaggio.

Nel caso di firma con recupero di RSA, partendo da un messaggio , questo viene diviso in blocchi

M m < n

ed ognuno sarà cifrato e concatenato agli altri. A seconda della lunghezza del messaggio, quindi, si rende

necessario eseguire numerose esponenziazioni modulari. Se invece si utilizzasse uno schema con appendice,

cifrando quindi l’hash del messaggio, si avrà la garanzia di dover eseguire sempre una sola esponenziazione

modulare.

Nel caso di firma con appendice si rende pertanto necessario inviare sia il messaggio che la relativa firma,

mentre nel caso di firma con recupero è sufficiente inviare la firma. In quest’ultimo caso, tuttavia, per

ottenere il messaggio occorre sempre prima verificare la firma, mentre nella firma con appendice si ha la

disponibilità immediata del contenuto del messaggio con la possibilità di ritardare la verifica della firma e

dell’integrità.

Nella firma con recupero viene firmato ogni blocco singolarmente, pertanto si ha la garanzia che ogni

singolo blocco sia stato originato dal firmatario legittimo e non l’intero messaggio. È quindi possibile

intercettare vari messaggi e riorganizzare diversi blocchi per creare un nuovo messaggio i cui singoli blocchi

siano stati firmati e siano autentici. L’intero messaggio non potrà invece essere autentico e, pertanto,

non avrà validità legale; sulla base di ciò vengono infatti a cadere anche tutti gli altri requisiti sull’intero

messaggio, mentre restano validi sui singoli blocchi.

Un meccanismo di firma con recupero può quindi essere utilizzato solo se corredato da funzioni di ridon-

danza che allegano al messaggio informazioni aggiuntive. Ciò significherebbe però definire delle funzioni di

ridondanza interoperabili adatte a molti scenari applicativi, pertanto spesso risulta utilizzata solo la firma

con appendice al fine di garantire valore legale.

Nel caso di un workflow con firma digitale di documenti si possono adottare due modalità:

• Firme concatenate: l’applicazione di una firma approva solo il contenuto del messaggio, a prescindere

dalle firme applicate in precedenza.

• Firme a cipolla: l’applicazione di una firma approva il contenuto del messaggio e anche tutte le firme

applicate in precedenza.

A prescindere dai casi, però, occorre verificare tutte le firme applicate in precedenza.

43

Capitolo 7

Servizi sicuri per le comunicazioni di rete

7.1 SSL

Il protocollo SSL, al giorno d’oggi, non è utilizzato nelle comunicazioni di rete in quanto non sicuro. Tuttavia,

esso risulta posto alla base dei protocolli oggi in uso per garantire autenticità, confidenzialità e integrità

attraverso canali di comunicazione non sicuri, dando luogo a comunicazioni ripudiabili.

SSL è un insieme di protocolli:

• Subito sopra al livello di trasporto si colloca il protocollo record, che definisce il formato dei messaggi

per le comunicazione sicure.

• Al livello applicativo si ha: 1

– handshake: per concordare i parametri crittografici, come le chiavi di cifratura simmetrica, e

per eseguire HMAC;

– change cipher spec: per finalizzare la definizione dello stato di sessione;

– alert: per comunicare diverse situazioni di errore.

SSL si basa sul concetto di sessione sicura, ossia un’associazione logica tra un client ed un server, e può

contenere al suo interno una o più connessioni che fungono da canale di trasporto. Ogni sessione è creata dal

protocollo handshake di negoziazione e, solo quando questo si è completato, è possibile comunicare in maniera

sicura sulle connessioni negoziate. SSL è nato per lavorare su Internet in un ambiente completamente libero

in cui client e server non si conoscono, pertanto le chiavi vengono sempre concordate con Diffie-Hellman o

con un cifrario ibrido.

Ogni sessione è caratterizzata da:

• un identificatore univoco della sessione stessa;

• il certificato del nodo che sta negoziando la connessione;

• il metodo di compressione dei dati;

• un cifrario e un algoritmo di hash;

• la chiave di cifratura della sessione a 48 bit;

ogni singola connessione è invece caratterizzata da:

• un numero casuale per client e server;

• le chiavi di cifratura dei dati;

• le chiavi per la creazione dell’autenticatore con HMAC;

• il vettore di inizializzazione del cifrario simmetrico;

• i numeri di sequenza per riordinare i messaggi trasmessi sul canale.

1 Per trasferire dati confidenziali, integri e autentici si utilizzerà sempre una cifratura simmetrica per soli motivi prestazionali.

44

7.1.1 Handshake

Il protocollo di handshake è piuttosto complesso ed è composto da varie fasi, ognuna con più messaggi.

Ognuno di questi messaggi è composto dal suo tipo, dalla sua lunghezza e dal suo contenuto effettivo.

Le 4 fasi sono:

1. server e client si accordano sui meccanismi per la riservatezza: il client propone quali supporta e il

server ne sceglie uno;

2. il server si autentica presso il client e, utilizzando un cifrario ibrido o Diffie-Hellman, vengono scambiate

le chiavi;

3. se nella fase precedente il server l’ha richiesto, il client si autentica presso il server;

4. vengono controllati tutti i dati scambiati, anche mediante l’utilizzo del protocollo change cipher spec

per creare l’autenticatore;

a questo punto è possibile utilizzare il protocollo record per scambiare messaggi sicuri.

7.1.1.1 Fase 1

I messaggi della prima fase sono e che contengono: la versione di SSL, i

client_hello server_hello,

numeri random da utilizzare (nel caso si scelga di usare Diffie-Hellman), l’ID di sessione (che, in base al

valore, può portare a definire una nuova sessione, una nuova connessione o la rinegoziazione dei parametri

di una sessione esistente), gli algoritmi di cifratura disponibili uniti ai relativi parametri tra cui il server può

scegliere ed infine i metodi di compressione dei dati applicativi (usati dal protocollo record) tra cui il server

può scegliere.

Per lo scambio delle chiavi si può decidere di procedere con:

• un cifrario ibrido basato su RSA;

• uno scambio Diffie-Hellman che può essere fixed, ephemeral o anche anonimo;

• Fortezza, uno schema proprietario di scambio delle chiavi.

7.1.1.2 Fase 2

La fase 2 ha inizio dal server, il quale invia un messaggio di contenuto variabile in funzione del

certificate

metodo di scambio scelto nella prima fase. Questo messaggio può essere seguito da un certificate_request,

in caso si voglia successivamente eseguire la fase 3 per autenticare il client (se si è scelto di utilizzare Diffie-

Hellman anonimo il messaggio certificate non viene inviato). Se il metodo di scambio delle chiavi scelto o il

certificato scambiato non contengono abbastanza informazioni, per terminare lo scambio si usa il messaggio

aggiuntivo il quale permette di comunicare le informazioni necessarie.

server_key_exchange,

Il protocollo di negoziazione prevede di verificare i certificati solo per firma e data di validità; non viene

verificato invece lo stato di revoca. Come si è visto, il solo invio del certificato in Diffie-Hellman non è

sufficiente ad autenticare il server, la cui verifica dell’identità è demandata a varie operazioni di cifratura e

firma con le chiavi del certificato.

La fase 2 termina con il messaggio con il quale il server segnala di aver terminato

server_hello_done,

l’elaborazione dello scambio delle chiavi ed è in attesa della risposta del client.

7.1.1.3 Fase 3

Se il server l’ha richiesto, il client procede a inviare il suo certificato con un messaggio (e altri

certificate

per informazioni aggiuntive, se necessari).

7.1.1.4 Fase 4

Il messaggio terminale è tale da autenticare la sessione evitando attacchi con replica. Esso invia un hash

di tutti i messaggi in precedenza scambiati, costituendo il primo messaggio che utilizza tutti gli algoritmi

negoziati e quindi verifica che tutto sia andato buon fine.

45

7.1.2 Record

Per garantire autenticazione, riservatezza e integrità il protocollo ha inizio con la frammentazione dei dati

applicativi in blocchi. Ognuno di questi viene corredato dalla sua lunghezza e dal suo numero di sequenza,

quindi ne viene calcolato l’HMAC secondo il segreto condiviso. L’autenticatore così costruito viene concate-

nato al messaggio e il tutto viene cifrato. Lato ricevitore vengono svolte le operazioni inverse di decifrazione,

ricalcolando l’autenticatore e verificando che esso sia corretto.

Questa soluzione non risulta ottimizzata computazionalmente per il destinatario, in quanto questo è

sempre obbligato a decifrare quindi a calcolare l’autenticatore. Sarebbe invece più efficiente poter prima

svolgere la verifica dell’autenticità, avendo in questo modo la possibilità di scartare i dati (risparmiandone

la decifrazione) se questi non sono autentici. Dati

Dati deframmentazione Alert

frammentazione −1 sì/no

Z Z

tipo

∥ lunghezza s M AC =?

n° sequenza

H H

tipo ∥

lunghezza

s

M AC n° sequenza

∥ Autenticazione

Riservatezza

IV IV

E D

k k

k k intestazione

∥ intestazione TCP

Figura 7.1: Schema di funzionamento del protocollo record.

7.1.3 Problemi di autenticazione

Il protocollo SSL si occupa solamente di verificare un certificato che viene fornito, senza controllare che il

certificato sia effettivamente relativo al server che ci si aspettava.

Questo problema deriva dal fatto che SSL lavora ad un livello più basso di quello applicativo. Occorre

quindi che le applicazioni si occupino di verificare che l’URL del server e quello contenuto nel certificato

corrispondano e, in caso contrario, interrompere la connessione.

7.2 Pretty Good Privacy PGP

PGP è un servizio di sicurezza applicativo che introduce un modello di autenticazione completamente

distribuito per garantire autenticazione per scambio di email e salvataggio di file.

Ciò è realizzato mediante l’utilizzo di servizi di:

• autenticazione con firma digitale (solitamente con appendice);

• confidenzialità, mediante l’utilizzo di cifrari simmetrici (per invio di posta e salvataggio dei file) e

asimmetrici (per il cifrario ibrido per lo scambio di chiavi);

46

• compressione, per la riduzione di banda e spazio occupato;

• compatibilità, per l’integrazione con numerosi programmi di posta elettronica (questi infatti, solita-

mente, visualizzano solo caratteri ASCII e non flussi binari, pertanto applicano una conversione basata

su Radix-64).

7.2.1 Autenticazione e confidenzialità

Gli schemi di autenticazione e riservatezza utilizzano gli schemi standard già visti, con l’unica differenza

dell’aggiunta della funzione di compressione (come prima operazione nella riservatezza e come ultima nel-

l’autenticazione). La chiave di cifratura simmetrica non sarà sempre la stessa, ma sarà una chiave monouso

scambiata con un cifrario ibrido.

È comunque possibile combinare le soluzioni, applicando prima la firma, quindi cifrando il solo messaggio

con la chiave di sessione unica concordata o scambiata con il cifrario ibrido.

PGP permette anche di preparare un messaggio per più destinatari cifrando la chiave simmetrica con

la chiave pubblica di ogni destinatario secondo il cifrario ibrido, permettendo, inoltre, di scegliere quale

modalità di cifratura si desideri utilizzare.

7.2.2 Compressione e compatibilità

In PGP la funzione di compressione si rende necessaria in quanto, utilizzando la conversione con Radix-64,

la dimensione del messaggio originario aumenta di circa il il quale viene quindi compensato con la

33 %,

compressione.

Si è visto come la compressione venga eseguita dopo la firma, ma sarebbe stato possibile eseguirla anche

prima, così come nella riservatezza è possibile eseguirla dopo la cifratura. La scelta del momento in cui

viene svolta l’operazione di compressione è data dal fatto che, utilizzando una firma con appendice, questa

verrebbe apposta sul messaggio compresso e, quindi, nel caso di un sistema di archiviazione, sarebbe stato

necessario salvare sia il messaggio, sia la sua compressione, andando a costituire un overhead (che si vorrebbe

evitare). Tra diverse versioni di PGP, inoltre, la funzione di compressione cambia e la compressione, posta

dopo, permette di essere più resistente alla prova del tempo. Poiché le funzioni di compressione non sono

sempre deterministiche occorre comunque tenere traccia nel tempo dell’esatta versione usata. Nel caso della

cifratura di file, la compressione prima della cifratura permette di ridurre ulteriormente le ridondanze nel

messaggio, riducendo pertanto la possibilità di analisi statistica.

Alcuni sistemi di posta permettono di visualizzare solo i caratteri ASCII, pertanto occorre trasformare la

rappresentazione a del flusso binario in una rappresentazione ASCII a Ciò è fatto processando

6 bit 8 bit.

i dati a blocchi di alla volta, quindi trasformando ogni blocchetto di in un carattere in codifica

24 bit 6 bit

ASCII.

7.2.3 Gestione delle chiavi

Nel modello di PGP ogni utente avrà una o più coppie di chiavi pubbliche e private che dovranno essere

conservate opportunamente in una struttura detta portachiavi, la quale sopperisce al ruolo svolto dalla

directory della CA: mano a mano che ogni utente viene in contatto con altri, la sua chiave pubblica verrà

salvata nel portachiavi a chiave pubblica. Il portachiavi a chiave privata è un sistema che conserva

le proprie chiavi private come entry composte da:

• chiave privata opportunamente cifrata con un’altra chiave;

• la corrispondente chiave pubblica;

• il momento della generazione;

• l’identificatore dell’utente per quella chiave;

• l’identificatore della chiave.

Ogni entry del portachiavi a chiave pubblica è invece formata da:

47

• timestamp del momento della memorizzazione;

• chiave pubblica;

• identificatore della chiave pubblica, ossia un suo sottoinsieme di bit;

• identificatore dell’utente per quella chiave;

• livello di fiducia, detto owner trust, a scelta del possessore del portachiavi tra:

– sconosciuto;

– non fidato;

– normalmente fidato;

– completamente fidato;

– ultimate trust;

• nel caso in cui la chiave sia distribuita come certificato, tale certificato sarà incluso, oppure la lista dei

signature trust,

certificati con relativo livello di fiducia, che PGP compila automaticamente in base

alla fiducia che il possessore ha attribuito al firmatario del certificato (se esiste nel portachiavi);

• key legitimacy, ossia il livello di fiducia che PGP calcola sulla base di owner trust e signature trust.

Questo modello non si basa quindi su nessuna CA, ma solo sul passaparola fra gli utenti per la distribuzione

delle chiavi pubbliche, pertanto non potrà avere valore legale. Allo stesso modo, la revoca di una chiave non

è propagata automaticamente, pertanto il diffondersi di questa informazione risulterà molto più lento. La

legittimità di ogni chiave e la fiducia per ogni certificato non è statica e, periodicamente, PGP le ricalcola

sulla base di nuove aggiunte o variazioni.

7.2.4 Formato dei messaggi

PGP definisce uno standard per il formato dei messaggi scambiati. Nel caso di messaggi cifrati e firmati,

essi devono sempre contenere:

• identificatore della chiave pubblica del destinatario;

• chiave di sessione cifrata con la chiave pubblica del destinatario;

• timestamp del messaggio;

• identificatore della chiave pubblica del mittente;

• primi due byte della firma e firma del messaggio;

• nome del file, timestamp del file e suo contenuto.

Poiché questi messaggi dovranno essere salvati è bene ridurne la dimensione. Invece di tutti i 2 048 bit

della chiave pubblica si passeranno solo i meno significativi, poiché è altamente improbabile che si

64 bit

trovino due chiavi con gli stessi meno significativi. Quando il messaggio giungerà a destinazione, questi

64 bit

bit verranno usati per accedere al portachiavi a chiave pubblica ed estrarre le chiave pubblica completa. Per

evitare di usare una chiave pubblica sbagliata quindi, a causa di una possibile collisione dell’identificatore, si

esegue la verifica sui soli primi due byte della firma: se questa verifica ridotta va a buon fine, si può procedere

a verificare l’intero messaggio, altrimenti si tenta con un’altra chiave che corrisponde all’identificatore.

7.3 Marche temporali sicure

Nel mondo legale si presenta spesso la necessità di sapere quando un documento sia stato creato, inviato

o altro. La marcatura temporale risulta estremamente importante in quanto permette di determinare il

momento esatto in cui una certa azione è stata effettuata. Tra queste, in particolare, risulta fondamentale

conoscere la marca temporale della firma digitale, poiché permette di decidere se la firma vada considerata

valida o meno sulla base del confronto con le date di eventuali revoche di certificati.

Per garantire questa funzionalità ci si appoggia quindi al Time Stamping Service TSS, che permette

di ottenere una marcatura temporale, la quale deve: 48

• contenere un tempo non falso, garantito da un ente fidato sulla base degli standard internazionali

forniti dagli orologi atomici;

• individuare univocamente il documento, l’istante in cui è stato marcato e l’autore;

• essere rilevabile la modifica di un solo bit della marca;

• il documento deve poter rimanere riservato all’ente fidato che costruisce la marca temporale;

• chiunque deve poter far marcare i propri documenti e verificare quelli marcati.

Per realizzare questo servizio sono sufficienti i meccanismi di firma digitale e le funzioni hash già viste. Queste

ultime risultano fondamentali perché permettono di garantire la marcatura senza rivelare il contenuto all’ente

fidato.

Ogni documento avrà quindi, come allegato, sia la firma dell’autore, sia la marca temporale. Occorre

quindi gestire, nel tempo, due chiavi diverse, e ciò può comportare una complicazione nella gestione dei

documenti. Per questo motivo, la marca temporale viene utilizzata in contesti applicativi molto ridotti, e

non tutti i documenti firmati con valore legale necessitano di una marca temporale. Quando le chiavi di

firma delle marche temporali scadono occorre inoltre che i documenti già firmati risultino ancora validi. La

complessità della gestione, quindi, aumenta, in quanto si procede ad apporre ulteriori firme di altre entità

sulle marche temporali. 7.2 si nota come l’autore del documento invii all’ente fidato solo un hash del

Nel protocollo in Figura

documento, concatenato al proprio identificatore. Ciò è fondamentale per garantire la riservatezza del

documento e limitare il consumo di banda. L’ente fidato, quindi, genera la marca e la invia in risposta;

per garantirne valore legale, esso deve firmarla con la sua coppia di chiavi ed archiviarla. L’autore, quindi,

firmerà con la sua chiave privata il documento concatenato alla marca generata ed al proprio identificatore.

∥ ∥ ∥ S Archivio

H k

T SS priv

t

T SS k T SS priv k Apriv

A H marcato

m

∥ ∥ ∥

S

m H k

Apriv e firmato

Figura 7.2: Protocollo di marcatura temporale affidata ad un ente fidato.

7.4 Kerberos

Kerberos è un sistema di autenticazione di utenti. Il nome deriva dal fatto che, inizialmente, il servizio

era stato progettato per offrire anche accounting ed auditing, ma queste due funzionalità non sono mai

2

state realizzate.

Kerberos gestisce l’autenticazione di utenti in un sistema distribuito che offre accesso a più servizi remoti.

Gli utenti possono accedere dalle workstation utilizzando una sola password, con concessione di accesso e

risorse sulla base dei privilegi dell’utente.

Avendo a disposizione workstation e server, si pone il problema di decidere quale entità identifichi l’utente:

• Assumendo le workstation fidate, queste possono identificare gli utenti. I server devono solo identificare

le workstation, ed ogni server conterrà le politiche di accesso sulla base dell’utente.

• Se viene a mancare la fiducia verso le workstation, il server dovrà prendersi carico di tutte le operazioni.

Questi due modelli presentano però il problema di essere applicabili solo in domini piccoli, chiusi e statici:

se il database degli utenti cambia, infatti, occorre propagare le modifiche a tutte le workstation o tutti i

2 Cerbero, secondo la mitologia greca, è il cane a tre teste guardiano della porta degli inferi.

49


ACQUISTATO

1 volte

PAGINE

65

PESO

353.70 KB

PUBBLICATO

6 mesi fa


DESCRIZIONE APPUNTO

Conoscenze e abilità da conseguire
Conoscenza degli algoritmi e dei protocolli per la difesa dei sistemi per l'elaborazione dell’informazione da attacchi intenzionali. Conoscenza dei meccanismi protettivi impiegati in contesti di rilevante interesse applicativo.

Programma/Contenuti
1. Sicurezza dei sistemi informatici: attacchi, proprietà di sicurezza e contromisure.
2. Crittografia e crittanalisi. Meccanismi di base: PRNG, Funzioni Hash crittograficamente sicure
3. Crittologia classica e fondamenti di teoria dell'informazione.
4. Cifrari simmetrici e meccanismi simmetrici per la riservatezza e l'autenticazione. Casi di studio: RC4, DES, AES, HMAC.
5. Protocolli d'identificazione passivi e attivi: Password, protocolli a sfida/risposta.
6. Fondamenti di teoria dei numeri. Scambio DH. Cifrari asimmetrici, cifrari ibridi e meccanismi asimmetrici di autenticazione. Firma digitale. Casi di studio: RSA.
7. Sistemi a supporto dell'identificazione e dell'autenticazione. Certificati a chiave pubblica -PKI e PGP. Protocolli di identificazione-Kerberos. Tecnologie basate su token crittografici. Sistemi basati su dati biometrici.
8. Protocolli per la comunicazione sicura. Sicurezza a livello di rete-IPSEC, VPN. Sicurezza a livello di trasporto-SSL/TLS
9. Programmazione di Applicazioni Sicure in ambiente Java


DETTAGLI
Corso di laurea: Corso di laurea magistrale in ingegneria informatica
SSD:
Università: Bologna - Unibo
A.A.: 2018-2019

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher piscoTech di informazioni apprese con la frequenza delle lezioni di Sicurezza dell'Informazione M e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Bologna - Unibo o del prof Montanari Rebecca.

Acquista con carta o conto PayPal

Scarica il file tutte le volte che vuoi

Paga con un conto PayPal per usufruire della garanzia Soddisfatto o rimborsato

Recensioni
Ti è piaciuto questo appunto? Valutalo!

Altri appunti di Sicurezza dell'informazione m

Domande di Teoria di Sicurezza dell'Informazione
Appunto
Domande di Teoria di Sicurezza dell'Informazione
Appunto