Key Management. Key management. Distribuzione delle chiavi pubbliche. Annuncio pubblico. Ozalp Babaoglu

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "Key Management. Key management. Distribuzione delle chiavi pubbliche. Annuncio pubblico. Ozalp Babaoglu"

Giancarlo Meli
6 anni fa
Visualizzazioni

1 Key management Key Management Ozalp Babaoglu Distribuzione delle chiavi pubbliche Gestione delle chiavi segrete Uso dei protocolli a chiave pubblica per distribuire chiavi segrete LM MTER STUDIORUM UNIVERSIT DI BOLOGN 2 Distribuzione delle chiavi pubbliche nnuncio pubblico nnuncio pubblico Elenco pubblico Certificati L utente rende di pubblico dominio la propria chiave pubblica Pubblicazione chiavi: Tutti possono pubblicare la propria chiave ccesso: Tutti possono accedere alle chiavi degli altri 3 4

2 nnuncio pubblico nnuncio pubblico K[pub] Utente Utente B K[pub] K[pub] KB[pub] KB[pub] d esempio: la chiave pubblica viene messa in allegato ai messaggi di posta elettronica o inserito nel home page dell utente 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 man-in-the-middle attack KB[pub] 5 6 Man-in-the-middle ttack Man-in-the-middle ttack ttacco attivo Si verifica durante la pubblicazione della chiave pubblica X si mette nel mezzo tra e B X si comporta come per B X si comporta come B per X devia la comunicazione tra e B facendola passare per se stesso... B: Destinatario kb[pub] kb[pub] Intruso X kb[pub] kx[pub] : Mittente kx[pub] 7 8

3 Man-in-the-middle ttack richiede a B la sua chiave pubblica kb[pub] (ad esempio per ) X intercetta kb[pub] e la sostituisce con kx[pub] X intercetta i crittogrammi da verso B, li decodifica con kx[priv], li recodifica con kb[pub] e li rispedisce a B Funziona perché e B non hanno nessun modo per verificare che stanno (o non stanno) comunicando con il vero interlocutore 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 ccesso: Pubblicazione periodica della directory (ad esempio su un periodico ad ampia diffusione) ccesso diretto alla directory tramite comunicazione elettronica (occorre una comunicazione autenticata e sicura) 9 10 Elenco pubblico Certificati 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 L autenticità delle chiavi è certificata da una utorità 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 uthority Necessita di un entità fidata super-partes che possa certificare in maniera sicura (More on certificates later) 11 12

4 Management of secret keys Management of Private 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(n 2 ) secret keys For large n, this may be infeasible since secret keys cannot be long lived but should be replaced often LM MTER STUDIORUM UNIVERSIT DI BOLOGN 14 Management of secret keys Basic Protocol and KDS share K ssume that a (trusted) Key Distribution Server (KDS) a priori shares a different secret key with each user and B want to establish a secure communication KDS generates and distributes to and B a one-time session key to be used for the duration of that communication Future communications between and B will generate and use different session keys B and KDS share KB 1. sends to KDS: {, request session key for B } 2. KDS generates new session key and sends to : C(K, {, C(KB, )}) 3. stores and sends to B: C(KB, ) 4. B stores 5. sends (confidential) message m to B: C(, m) 15 1

5 Basic Protocol: Commenti and KDS share K lla base di molti altri protocolli più sofisticati Difetti: B non può sapere con certezza che il messaggio arriva da Soggetto a replay attack Un attaccante può catturare e rispedire nel futuro i crittogrammi C(K, {, C(KB, )}) C(KB, ) B and KDS share KB 1. sends to KDS: {, request session key for B, N1} 2. KDS generates new session key and sends to : C(K, {,, B, N1, C(KB, {, })}) 3. stores and sends to B: C(KB, {, }) 4. B sends to : C(, N2) (challenge) 5. replies to B: C(, N2 +1) (response) 6. sends (confidential) message m to B: C(, m) KDS N1 and N2 are called nonces (number used once) and prevent replay attacks Basis for the Kerberos system ➀ K ➁ ➃ ➂ ➄ B 19 20

6 : Commenti B si fida di KDS ed è sicuro di aver ricevuto la chiave di sessione da KDS perché il messaggio da KDS contiene N1 è sicuro di comunicare a B perché spedisce la chiave 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 B può riconoscere un replay attack ed essere sicuro di comunicare con If wants to communicate with a different principal C, it has to restart the protocol with KDS to generate a new session key using its shared secret key K Since the shared key is based on a secret, this results in an increased risk that it may be compromised 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 ll communication within a single session secured through keys obtained from a Ticket Granting Server (TGS) 23 24

7 Kerberos Kerberos KDS Often, co-located ➀ K ➁ ➃ ➂ TGS KB KB KB B Kerberos Kerberos If wants to communicate with a different principal C, it has to restart the protocol with TGS (not KDS) to generate a new session key KC using the key (not the shared secret key K ➀ ➁ TGS KC KC KC C 27 28

8 Kerberos Key Distribution Server In a very large system, KDS may be performance and reliability bottleneck 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 Vantaggi Garantisce riservatezza ed autenticazione Mantiene buone prestazioni anche con forte ricambio delle chiavi per molti utenti Per n principali, riduce da O(n 2 ) a O(n) numero di chiavi segrete Svantaggi Richiede la presenza di un KDS sicuro Hybrid solutions Hybrid solution 1. generates (K[pub], K[priv]) 2. sends to B: {K[pub], } 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 3. B generates 4. B sends to : C(K[pub], ) 5. decrypts to obtain = D(K[priv], C(K[pub], )) 6. Delete (K[pub], K[priv]) 7. and B switch to symmetric cryptography using session key 31 32

9 Hybrid solution General hybrid solution Garantisce riservatezza ma non autenticazione Soggetto a man-in-the-middle attack General solution based on certificates to guarantee mutual authentication Basis for SSL 33 34

Documenti analoghi

Babaoglu 2006 Sicurezza 2

Babaoglu 2006 Sicurezza 2 Key Escrow Key Escrow Ozalp Babaoglu! In many situations, a secret (key) is known to only a single individual " Private key in asymmetric cryptography " The key in symmetric cryptography or MAC where the