Security Case Studies: Needham-Schroeder, Kerberos, SSL, and Public Key Encryption, Study notes of Operating Systems

Download Security Case Studies: Needham-Schroeder, Kerberos, SSL, and Public Key Encryption and more Study notes Operating Systems in PDF only on Docsity! 1 CS 5523 Lecture 25: Security Case Studies ❚ Review scenarios ❚ Needham-Schroeder ❚ Brief summary of common algorithms ❚ Kerberos ❚ Secure Socket Layer Simplified overview of secret key encryption: Encrypted message: E(K, M) = {M}K Decrypted message: D(K, E(K, M)) = D(K, {M}K) = M It is hard to get M from {M}K without knowing K Scenario 1. Secret communication with shared secret key Alice and Bob share a secret key KAB. Alice wants to send a secret message M to Bob. 1. Alice uses KAB and an agreed encryption function E(KAB, M) to encrypt and send message M to Bob 2. Bob reads the encrypted messages using the corresponding decryption function D(KAB, M) How can Bob and Alice safely get the shared key KAB? How can Bob know that M wasn’t a replay? 2 Scenario 2. Authenticated communication with a server Alice wants to access Bob’s files on a local file server. Sara is a trusted authentication server that holds passwords and current secret keys. 1. Alice sends a message to Sara asking for a ticket to access Bob 2. Sara sends Alice a response encrypted with KA that is a ticket encrypted with KB and a new secret key KAB for communication: {{ticket}KB, KAB} KA 3. Alice decrypts response with KA 4. Alice sends ticket, her ID and request R to Bob: {ticket}KB, Alice, R 5. Bob decrypts ticket using KB (the ticket was {KAB, Alice} KB ) This is the simplified scenario for Kerberos. KAB is the session key. Simplified overview of public key encryption: Keys come in pairs K1 and K2. Keep one public and one private. If you encrypt with K1, you can decrypt with K2 and vice versa: D(K2 , E(K1 , M)) = M and D(K1 , E(K2 , M)) = M Scenario 3. Authenticated communication with public keys Bob has generated a public/private key pair. There is a trusted authority that gives out key certificates 1. Alice accesses a key distribution center to obtain a public key certificate with Bob’s public key. Alice extracts Bob’s public key KBpub 2. Alice creates a new secret key KAB and encrypts {KAB, known string} with KBpub 3. Alice sends {{unique keyname}, {KAB, known string}KBpub } to Bob. 4. Bob decrypts {KAB, known string}KBpub using KBpriv 5. Bob and Alice now communicate with KAB This is the scenario for the widely used hybrid cryptographic protocol. 5 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 7.14 Performance of encryption and secure digest algorithms Key size/hash size (bits) Extrapolated speed (kbytes/sec.) PRB optimized (kbytes/s) TEA 128 700 - DES 56 350 7746 Triple-DES 112 120 2842 IDEA 128 700 4469 RSA 512 7 - RSA 2048 1 - MD5 128 1740 62425 SHA 160 750 25162 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 7.15 The Needham–Schroeder secret-key authentication protocol Header Message Notes 1. A->S: A, B, NA A requests S to supply a key for communicationwith B. 2. S->A: {NA , B, KAB, {KAB, A}KB}KA S returns a message encrypted in A’s secret key, containing a newly generated key KAB and a ‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in response to the preceding one. A believes that S sent the message because only S knows A’s secret key. 3. A->B: A sends the ‘ticket’ to B. 4. B->A: B decrypts the ticket and uses the new key KAB to encrypt another nonce NB. 5. A->B: A demonstrates to B that it was the sender of the previous message by returning an agreed transformation of NB. {KAB, A}KB {NB}KAB {NB - 1}KAB Kerberos: ❚ Follows Needham and Schroeder very closely ❚ Uses time values as nonces ❚ When user logs in, the login program sends user’s name to the kerberos authentication server ❚ If user is known, server replies with a session key and a nonce encrypted in the user’s password and a ticket for TGS ❚ After login program authenticates the information, it can erase the user’s password from memory 6 Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 7.16 System architecture of Kerberos ServerClient DoOperation Authentication database Login session setup Ticket- granting service T Kerberos Key Distribution Centre Server session setup Authen- tication service A 1. Request for TGS ticket 2. TGS ticket 3. Request for server ticket 4. Server ticket 5. Service request Request encrypted with session key Reply encrypted with session key Service function Step B Step A Step C C S Kerberos (continued): ❚ When a program needs a service, it requests a ticket from TGS ❚ Server machines must take care to store their keys in a safe place ❚ Kerberos is implemented as a server running on a “secure” machine ❚ DES encryption is used, but it can be replaced ❚ Kerberos is scalable – world divided into realms ❚ Processes can authenticate themselves to servers in other realms through their local TGS ❚ Ticket lifetimes of 12 hours are typically used Secure socket layer (SSL) ❚ Developed by Netscape, 1996 ❚ Has been adopted as a standard under the name Transport Layer Security (TLS) ❚ Is supported by most browsers for electronic transactions ❚ Has negotiable encryption and authentication algorithms ❚ Bootstraps by establishing a secure channel based on public-key encryption ❚ Channel is fully configurable so not everything has to be encrypted 7 Secure socket layer (SSL) - continued ❚ SSL Record Protocol layer implements a secure channel that encrypts and authenticates message through any connection- oriented protocol ❚ SSL Handshake Layer – has three modules: ❙ SSL handshake protocol ❙ SSL change cipher specification ❙ SSL alert protocol ❚ Implemented as application level libraries ❚ Widely uses as a session-layer protocol ❚ In web servers the https URLs initiate a SSL connection ❚ Provides a practical hybrid security scheme ❚ Requires public-key certificates issued by a recognized authority Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 7.17 SSL protocol stack SSL Handshake protocol SSL Change Cipher Spec SSL Alert Protocol Transport layer (usually TCP) Network layer (usually IP) SSL Record Protocol HTTP Telnet SSL protocols: Other protocols: Instructor’s Guide for Coulouris, Dollimore and Kindberg Distributed Systems: Concepts and Design Edn. 3 © Addison-Wesley Publishers 2000 Figure 7.18 SSL handshake protocol Client Server ClientHello ServerHello Certificate Certificate Request ServerHelloDone Certificate Certificate Verify Change Cipher Spec Finished Change Cipher Spec Finished Establish protocol version, session ID, cipher suite, compression method, exchange random values Optionally send server certificate and request client certificate Send client certificate response if requested Change cipher suite and finish handshake