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