Key Management
Ozalp Babaoglu
ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA
Key management
■ Distribuzione delle chiavi pubbliche
■ Gestione delle chiavi segrete
■ Uso dei protocolli a chiave pubblica per distribuire chiavi
segrete
© Babaoglu 2001-2014
Sicurezza
2
Distribuzione delle chiavi pubbliche
■ Annuncio pubblico
■ Elenco pubblico
■ Certificati
© Babaoglu 2001-2014
Sicurezza
3
Annuncio pubblico
■ L’utente rende di pubblico dominio la propria chiave
pubblica
■ Pubblicazione chiavi:
● Tutti possono pubblicare la propria chiave
■ Accesso:
● Tutti possono accedere alle chiavi degli altri
© Babaoglu 2001-2014
Sicurezza
4
Annuncio pubblico
ub
p
[
KA
Utente A
KA[pub]
KA
[pu
b
ub
p
[
KB
Utente B
]
]
Ad esempio: la chiave pubblica
viene messa in allegato ai messaggi
di posta elettronica o inserito nel
home page dell’utente
KB[pub]
KB
© Babaoglu 2001-2014
]
[pu
b
]
Sicurezza
5
Annuncio pubblico
■ Vantaggi
● Semplice, veloce, non necessita di intermediari
■ Svantaggi
● Nessuna garanzia: l’annuncio può essere facilmente alterato.
L’intruso può pubblicare la propria chiave pubblica a nome di un
altro utente! Soggetto a “man-in-the-middle attack”
© Babaoglu 2001-2014
Sicurezza
6
Man-in-the-middle Attack
■ Attacco attivo
■ X si mette nel mezzo tra A e B
■ X si comporta come A per B
■ X si comporta come B per A
■ X devia la comunicazione tra A e B facendola passare per
se stesso...
© Babaoglu 2001-2014
Sicurezza
7
Man-in-the-middle Attack
kB[pub]
B: Destinatario
A: Mittente
kX[pub]
kB[pub]
Intruso X
kB[pub]
kX[pub]
© Babaoglu 2001-2014
Sicurezza
8
Man-in-the-middle Attack
■ A richiede a B la sua chiave pubblica kB[pub] (per e-mail
ad esempio)
■ X intercetta kB[pub] e la sostituisce con kX[pub]
■ X intercetta i crittogrammi da A verso B, li decodifica con
kX[priv], li ri-codifica con kB[pub] e li rispedisce a B
■ Funziona perché A e B non hanno nessun modo per
verificare che stanno (o non stanno) comunicando con il
vero interlocutore
© Babaoglu 2001-2014
Sicurezza
9
Back to key distribution:
Elenco pubblico
■ Directory mantenuta da un’entità fidata (authority)
● copie <user, key>
■ Pubblicazione chiavi:
● Ogni partecipante registra la propria chiave presso l’authority (di
persona o in modo sicuro)
● Può aggiornarla nello stesso modo in qualsiasi momento
■ Accesso:
● Pubblicazione periodica della directory (ad esempio su un
periodico ad ampia diffusione)
● Accesso diretto alla directory tramite comunicazione elettronica
(occorre una comunicazione autenticata e sicura)
© Babaoglu 2001-2014
Sicurezza
10
Elenco pubblico
■ Svantaggi
● Necessita di un’entità fidata super-partes: authority
● La Directory può essere violata
● Necessita di protocolli di comunicazione sicuri per la
pubblicazione e l’accesso alle chiavi
© Babaoglu 2001-2014
Sicurezza
11
Certificati
■ L’autenticità delle chiavi è certificata da una Autorità
aggiungendo la sua firma
■ Garantisce l’identità dei partecipanti e l’attualità delle
chiavi (mitiga il problema del furto della chiave privata)
■ Elimina un attacco man-in-the-middle: un intruso non può
sostituire la chiave pubblica perché non può firmare e
certificare con la chiave (privata) dell’Authority
■ Necessita di un’entità fidata super-partes che possa
certificare in maniera sicura
■ (More on certificates later)
© Babaoglu 2001-2014
Sicurezza
12
Management of Private
Keys
ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA
Management of secret keys
■ n parties (clients, server, users, processes, etc.) need to
communicate securely (confidential)
■ Use private key cryptography to establish secure
communication channels
■ If every pairwise communication is possible and needs to
be secured, then we need to generate and maintain O(n2)
secret keys
■ For large n, this may be infeasible since secret keys
cannot be long lived but should be replaced often
© Babaoglu 2001-2014
Sicurezza
14
Management of secret keys
■ Assume that a (trusted) Key Distribution Server (KDS) a
priori shares a different secret key with each user
■ A and B want to establish a secure communication
■ KDS generates and distributes to A and B a one-time
session key to be used for the duration of that
communication
■ Future communications between A and B will generate
and use different session keys
© Babaoglu 2001-2014
Sicurezza
15
Management of secret keys:
Basic Protocol
■ A and KDS share KA
■ B and KDS share KB
1. A sends to KDS:
{A, “request session key for B”}
2. KDS generates new session key KS and sends to A:
C(KA, {KS, C(KB, KS)})
3. A stores KS and sends to B: C(KB, KS)
4. B stores KS
5. A sends confidential message m to B: C(KS, m)
© Babaoglu 2001-2014
Sicurezza
16
Basic Protocol: Commenti
■ Alla base di molti altri protocolli più sofisticati
■ Difetti:
● B non può sapere con certezza che il messaggio arriva da A
● Soggetto a “replay attack”
▴ Un attaccante può catturare e rispedire nel futuro i crittogrammi
C(KA, {KS, C(KB, KS)})
C(KB, KS)
© Babaoglu 2001-2014
Sicurezza
17
Management of secret keys:
Needham-Schroeder Protocol
■ A and KDS share KA
■ B and KDS share KB
1. A sends to KDS:
{A, “request session key for B”, N1}
2. KDS generates new session key KS and sends to A:
C(KA, {KS, A, B, N1, C(KB, {KS, A})})
3. A stores KS and sends to B: C(KB, {KS, A})
4. B sends to A:
C(KS, N2)
(challenge)
5. A replies to B: C(KS, N2 +1) (response)
6. A sends confidential message m to B:
© Babaoglu 2001-2014
Sicurezza
C(KS, m)
18
Management of secret keys:
Needham-Schroeder Protocol
KDS
➀
➁
KA
KS
A
© Babaoglu 2001-2014
➂
➃
➄
Sicurezza
B
19
Management of secret keys:
Needham-Schroeder Protocol
KS
KS
B
…
A
■ N1 and N2 are called “nonces” (number used once) and
prevent replay attacks
■ Basis for the Kerberos system
© Babaoglu 2001-2014
Sicurezza
20
Needham-Schroeder Protocol:
Commenti
■ A si fida di KDS ed è sicuro di aver ricevuto la chiave di
sessione da KDS. Infatti il messaggio da KDS contiene N1
■ A è sicuro di comunicare KS a B perché spedisce la chiave
KS cifrata con KB, che solo B è il grado di decifrare
■ B si fida di KDS e KDS gli garantisce che la chiave può
essere usata per comunicare con A
■ B può riconoscere un replay attack ed essere sicuro di
comunicare con A
© Babaoglu 2001-2014
Sicurezza
21
Management of secret keys:
Needham-Schroeder Protocol
■ If A wants to communicate with a different principal C, it
has to restart the protocol with KDS to generate a new
session key KS using its shared secret key KA
■ Since the shared key is based on a secret, this results in
an increased risk that it may be compromised
© Babaoglu 2001-2014
Sicurezza
22
Kerberos
■ Developed at MIT during the 1980’s to serve as an
distributed authentication service in an academic
environment
■ Principals (clients running on behalf of users) prove their
identity to servers without sending data across the
network that would allow an attacker to impersonate them
■ Each principal initially shares a secret key (password) with
the KDS
■ To reduce the exposure of the secret key, KDS used only
once per login session
■ All communication within a single session secured through
keys obtained from a Ticket Granting Server (TGS)
© Babaoglu 2001-2014
Sicurezza
23
Kerberos
Often, co-located
KDS
➀
➁
KA
KS
A
➂
➃
TGS
KAB
© Babaoglu 2001-2014
Sicurezza
24
Kerberos
A
KAB
…
KAB
B
© Babaoglu 2001-2014
Sicurezza
25
Kerberos
■ If A wants to communicate with a different principal C, it
has to restart the protocol with TGS (not KDS) to generate
a new session key KAC using the key KS (not the shared
secret key KA)
■ In a very large system, the KDS may be performance and
reliability bottleneck
■ The KDS can be replicated to obtain increased
performance and reliability using a master-slave scheme
■ In a very large systems, a single (or replicated) KDS may
not be acceptable for administrative reasons
© Babaoglu 2001-2014
Sicurezza
26
Management of secret keys:
Key Distribution Server
■ Vantaggi
● Garantisce riservatezza ed autenticazione
● Mantiene buone prestazioni anche con forte ricambio delle chiavi
per molti utenti
● Per n principali, riduce da O(n2) a O(n) numero di chiavi segrete
■ Svantaggi
● Richiede la presenza di un KDS sicuro
© Babaoglu 2001-2014
Sicurezza
27
Management of secret keys:
Hybrid solutions
■ Crittografia a chiave pubblica relativamente lenta (circa
1000 volte rispetto a crittografia a chiave privata)
■ Una volta distribuite le chiavi pubbliche, le uso per
generare le chiavi segrete
© Babaoglu 2001-2014
Sicurezza
28
Management of secret keys:
Hybrid solution
1.
2.
3.
4.
5.
A generates (KA[pub], KA[priv])
A sends to B: {KA[pub], A}
B generates KS
B sends to A: C(KA[pub], KS)
A decrypts to obtain KS = D(KA[priv], C(KA[pub], KS))
6. Delete (KA[pub], KA[priv])
7. Pass to symmetric cryptography using session key KS
© Babaoglu 2001-2014
Sicurezza
29
Management of secret keys:
Hybrid solution
■ Garantisce riservatezza ma non autenticazione
■ Soggetto a man-in-the-middle attack
© Babaoglu 2001-2014
Sicurezza
30
Management of secret keys:
General hybrid solution
■ General solution based on certificates to guarantee mutual
authentication
■ Basis for SSL
© Babaoglu 2001-2014
Sicurezza
31

Download Report