Key management, Kerberos

Transcript

Key management, Kerberos
Gestione delle chiavi
Key Management
■ Distribuzione delle chiavi pubbliche
■ Uso dei protocolli a chiave pubblica per distribuire chiavi
segrete
Ozalp Babaoglu
ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA
© Babaoglu 2001-2011
Sicurezza
Distribuzione delle chiavi pubbliche
■
■
■
■
2
Annuncio pubblico
■ L’utente rende di pubblico dominio la propria chiave
pubblica
■ Pubblicazione chiavi:
Annuncio pubblico
Elenco pubblico
Autorità di distribuzione
Certificati
● Tutti possono pubblicare la propria chiave
■ Accesso:
● Tutti possono accedere alle chiavi degli altri
© Babaoglu 2001-2011
Sicurezza
3
© Babaoglu 2001-2011
Sicurezza
4
Annuncio pubblico
pub
KA[
Utente A
]
KA[pub]
KA
[pu
b
]
]
pub
KB[
Utente B
■ Vantaggi
Ad esempio: la chiave pubblica
viene messa in allegato ai messaggi
di posta elettronica o inserito nel
home page dell’utente
● 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”
KB[pub]
KB
[pu
b
© Babaoglu 2001-2011
Annuncio pubblico
]
Sicurezza
5
Sicurezza
© Babaoglu 2001-2011
Man-in-the-middle Attack
6
Man-in-the-middle Attack
kB[pub]
■
■
■
■
■
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...
B: Destinatario
A: Mittente
kX[pub]
kB[pub]
Intruso X
kB[pub]
kX[pub]
© Babaoglu 2001-2011
Sicurezza
7
© Babaoglu 2001-2011
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
■ Works because A and B have no way to verify that they
are (or are not) talking to each other
© Babaoglu 2001-2011
Sicurezza
Interlock Protocol
9
B sends to A his public key kB[pub] as before
A encrypts m using kB[pub], and sends first half of it to B
A waits for an “Ack” from B (not subject to attack)
A sends B the second half of the encrypted message
B puts the two pieces together and decrypts using kB[priv]
X can still substitute his own public key for kB[pub] and
therefore decrypt the message sent by A (after he has
seen both pieces) but cannot replace the message with
his own since he cannot decrypt and re-encrypt half
messages
© Babaoglu 2001-2011
Sicurezza
Back to key distribution:
Public directory
10
Elenco pubblico
■ 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)
■ Directory mantenuta da un’entità fidata (authority)
■ 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
© Babaoglu 2001-2011
Sicurezza
■ Svantaggi
● Necessita di un’entità fidata super-partes: authority
● Necessita di protocolli di comunicazione sicuri per la
pubblicazione e l’accesso alle chiavi
● La Directory può essere violata
11
© Babaoglu 2001-2011
Sicurezza
12
Autorità di distribuzione
■ Directory mantenuta da una Authority che ne ha l’accesso
esclusivo
■ Controllo più rigido sulla distribuzione delle chiavi rispetto
alla tecnica dell’elenco pubblico
■ Pubblicazione chiavi:
■ Vantaggi
● Garantisce l’identità dei partecipanti e l’attualità delle chiavi
■ Svantaggi
● Necessita di un’entità fidata super-partes che va interpellata per
ogni nuovo partecipante
● La Directory può essere violata
● Soggetto a man-in-the-middle attack
● Le chiavi vengono registrate presso l’Authority in maniera sicura
(es: di persona)
© Babaoglu 2001-2011
Sicurezza
Autorità di distribuzione
13
© Babaoglu 2001-2011
Sicurezza
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)
■ Eliminates man-in-the-middle attack since the intruder
cannot substitute his public key for someone else since he
cannot sign the certificate as the authority
■ Necessita di un’entità fidata super-partes che possa
certificare in maniera sicura
■ More on certificates later
© Babaoglu 2001-2011
Sicurezza
15
Management of Private
Keys
ALMA MATER STUDIORUM – UNIVERSITA’ DI BOLOGNA
14
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-2011
Sicurezza
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
17
Sicurezza
© Babaoglu 2001-2011
Management of secret keys:
Needham-Schroeder Protocol
18
Management of secret keys:
Needham-Schroeder Protocol
KDS
1. A sends to KDS: {A, 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)
© Babaoglu 2001-2011
Sicurezza
➀
➁
KA
KS
A
19
© Babaoglu 2001-2011
➂
➃
➄
Sicurezza
B
20
Management of secret keys:
Needham-Schroeder Protocol
KS
■ 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
KS
B
…
A
Management of secret keys:
Needham-Schroeder Protocol
■ N1 and N2 are called “nonces” (number used once) and
prevent replay attacks
■ Basis for the Kerberos system
© Babaoglu 2001-2011
Sicurezza
21
Sicurezza
© Babaoglu 2001-2011
22
Kerberos
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-2011
Sicurezza
23
Often, co-located
KDS
➀
➁
KA
KS
A
➂
➃
TGS
KAB
© Babaoglu 2001-2011
Sicurezza
24
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
A
KAB
…
KAB
B
© Babaoglu 2001-2011
Kerberos
Sicurezza
25
© Babaoglu 2001-2011
Management of secret keys:
Key Distribution Server
Sicurezza
26
Management of secret keys:
Hybrid solutions
■ 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
■ 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
● Richiede la presenza di un KDS sicuro
© Babaoglu 2001-2011
Sicurezza
27
© Babaoglu 2001-2011
Sicurezza
28
Management of secret keys:
First hybrid solution
■
■
■
■
■
■
■
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))
Delete (KA[pub], KA[priv])
Pass to symmetric cryptography using session key KS
© Babaoglu 2001-2011
Sicurezza
Management of secret keys:
First hybrid solution
■ Garantisce riservatezza ma non autenticazione
■ Soggetto a man-in-the-middle attack
29
© Babaoglu 2001-2011
Management of secret keys:
Second hybrid solution
Sicurezza
30
Management of secret keys:
General hybrid solution
■ Le chiavi pubbliche sono già state distribuite
■ Per autenticazione (challenge-response):
● A sends to B: C(KB[pub], {A, N1})
■ General solution based on certificates to guarantee mutual
authentication
■ Basis for SSL
● B sends to A: C(KA[pub], {N1, N2})
● A sends to B: C(KB[pub], N2)
■ A genera KS e la spedisce a B:
● A sends to B: C(KB[pub], D(KA[priv], KS))
■ Garantisce riservatezza ed autenticazione
© Babaoglu 2001-2011
Sicurezza
31
© Babaoglu 2001-2011
Sicurezza
32