Digital Signatures Secure Digest Functions 8 requirements for one-way hash functions given M, H(M) is easy to compute given H(M), M is difficult to compute given M, it is difficult to find M such that H(M) = H(M ) 8 threat of birthday attack A generates M and M, M is favourable to B, M isn t A makes several subtly different versions of both M and M that are visually indistinguishable (e.g., by adding spaces at end of line) A compares hashes for all of the Ms and all for all of the M s until she finds two that are identical gives favourable variant of M to Bob for him to sign using his private key replaces M by variant of M that hashes to same value and combines it with the original signature obtained from M 8 64 bit hash values means we need 2 32 variants of M and M on average min key length 128 8 hash functions used in practice MD5: generates 128 bit digest from 512 bit block, very efficient SHA: based on MD4, produces 160 bit digest, much less efficient than MD5 Distributed Systems - Fall 2001 VII - 30 Stefan Leue 2002 tele
Cryptographic Algorithm Performance 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 Addison-Wesley Publishers 2000 8 key size: rough estimate of relative security against brute foce attacks 8 speed: estimate of algorithm s performance left column: non-optimized C code as given in literature PRB optimized: commercial, proprietary assembler implementation Distributed Systems - Fall 2001 VII - 31 Stefan Leue 2002 tele
Certificates Certificate 8 somebody s key, signed by a trusted authority 8 avoids substitution of one key for another 8 example authentication, that Alice has an account with Bob (a bank) 1. Certificate type: Account number 2. Name: Alice 3. Account: 6262626 4. Certifying authority: Bob s Bank 5. Signature: {Digest(field 2 + field 3)} KBpriv Addison-Wesley Publishers 2000 Alice needs to prove to merchant Carol that she can validate the signature using K Bpub attack ialice generates K B pub and K B priv ialice uses this to generate a forged certificate, claiming it comes from Bob solution icarol needs certificate for K Bpub signed by a trusted authority Distributed Systems - Fall 2001 VII - 32 Stefan Leue 2002 tele
1. Certificate type: Public key 2. Name: Bob s Bank Certificates 3. Public key: K Bpub 4. Certifying authority: Fred The Bankers Federation 5. Signature: {Digest(field 2 + field 3)} KFpriv Addison-Wesley Publishers 2000 Chained Certificates 8 choice of trusted authority? 8 revelation of private keys => keep chain as short as possible Revocation of Certificates 8 Bob manages a club, maintains email list 8 email list open only to members 8 Bob issues certificates ( Alice is a member, Bob, {digest( Alice is a member )}KB priv ) 8 problem: what if Alice leaves the club? explicit certificate revocation too expensive add expiry date to certificate Distributed Systems - Fall 2001 VII - 33 Stefan Leue 2002 tele
Certificates Subject Issuer Period of validity Administrative information Extended Information Distinguished Name, Public Key Distinguished Name, Signature Not Before Date, Not After Date Version, Serial Number Addison-Wesley Publishers 2000 X.509 Certificate Standard 8 useful if certificates have common format 8 used in Secure Socket Layer (SSL) protocol 8 certificate authorities Verisign Distributed Systems - Fall 2001 VII - 34 Stefan Leue 2002 tele
Authentication Authentication 8 authentication between pair of principals each principal is assured of the identity of its communication peer possible with secret and public key schemes Authenticated Communication via Authentication Server 8 assume Sara to be a securely operated authentication server maintains user passwords holds secret keys for all principals in system igenerated by applying a one-way function to principal s password maintains tickets iencrypted data object * identity of principal to whom it is issued * shared key that has been set up for the current principal-toprincipal communication session Distributed Systems - Fall 2001 VII - 35 Stefan Leue 2002 tele
Authentication Authenticated Communication via Authentication Server 8 a simple protocol: Alice sends plaintext request for ticket to access Bob to Sara Sara returns {{Ticket} KB, K AB } KA to Alice i{ticket} KB : ticket to be decoded and used by Bob * Ticket = {K AB, Alice} KB * K AB : session key ik A : key derived from Alice s password Alice decrypts received message iuses K A iif her password is consistent with that stored on Sara, she will obtain valid ticket for access to Bob * this is called a challenge * neither Alice nor any impostor can make use of ticket unless s/he can generate K A Alice sends {{Ticket} KB, Alice, access-request} in plaintext to Bob Bob decrypts ticket using K B 8 note password is not transmitted prior knowledge of Alice s password on Sara requires secure network Distributed Systems - Fall 2001 VII - 36 Stefan Leue 2002 tele
Authentication Authenticated Communication with Public Keys 8 using a hybrid cryptographic protocol assume Bob has generated K Bpub and K Bpriv and has a certificate with trusted authority Alice obtains Bob s public key certificate from trusted authority and retrieves K Bpub Alice creates shared key K AB and encrypts it using K Bpub Alice sends {keyname, {K AB }KB pub } to Bob iunique keyname, since Bob may be using a number of private/public key pairs at any given time Bob uses K Bpriv corresponding to keyname and obtains K AB 8 note if message corrupted in transit from Alice to Bob, then they don t share common key imessage may contain a string like email address so that having obtained an incorrect key can be detected by Bob Distributed Systems - Fall 2001 VII - 37 Stefan Leue 2002 tele
Authentication Authenticated Communication with Public Keys 8 man-in-the-middle attack Mallory intercepts Alice s initial request isends a response to Alice containing its own public key henceforth, Mallory can intercept all messages and pretend to be Bob protection: Alice needs to make sure that Bob s public key originates from a certificate that is signed by a trusted authority Distributed Systems - Fall 2001 VII - 38 Stefan Leue 2002 tele
Needham-Schroeder Authentication Needham-Schroeder (1978) 8 here: only secure key variant public key variant similar to ssl 8 goal: authentication and key distribution based on authentication server supplies secret keys to pairs of clients 8 basic principle A requests key from server ioften: A is client, and B provides some service obtains key ione version to use ione version encrypted for secure transfer to B authentication server maintains name and key (= password) for all clients in system protocol based on tickets to ensure freshness, protocol uses nonces iintegers used only once, generated on demand 8 protocol ensures A receives message decoded with K AB, it knows it can only come from B A sends message encoded with K AB, it knows it can only be read by B Distributed Systems - Fall 2001 VII - 39 Stefan Leue 2002 tele
Needham-Schroeder Authentication Needham-Schroeder Secret Key Authentication Protocol Header Message Notes 1. A->S: A, B, N A A requests S to supply a key for communication with B. 2. S->A: {N A, B, K AB, {K AB, A} K B } KA 3. A->B: {K AB, A} K A sends the ticket to B. B S returns a message encrypted in A s secret key, containing a newly generated key K AB and a ticket encrypted in B s secret key. The nonce N A 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. 4. B->A: {N B } K B decrypts the ticket and uses the new key K AB to AB encrypt another nonce N B. 5. A->B: {N B - 1} K A demonstrates to B that it was the sender of the AB previous message by returning an agreed transformation of N B. Addison-Wesley Publishers 2000 Distributed Systems - Fall 2001 VII - 40 Stefan Leue 2002 tele
Needham-Schroeder Authentication One Known Weakness in Needham-Schroeder 8 assume intruder manages to obtain K AB and get a copy of ticket {K AB, A}K B not unrealistic since these may reside in unprotected memory of an application programme 8 then intruder can later reuse ticket and pretend to be A 8 possible solution: add nonce or timeout to ticket {K AB, A, t}k B Distributed Systems - Fall 2001 VII - 41 Stefan Leue 2002 tele
Kerberos Kerberos 8 server based authentication 8 extension of Schroeder-Needham 8 often used to support secure client-server communication History 8 developed at MIT (1988) 8 Internet standard: RFC 1510 (1993) 8 part of OSF/DCE 8 part of Windows 2000 as default authentication protocol Distributed Systems - Fall 2001 VII - 42 Stefan Leue 2002 tele
Kerberos Security objects 8 ticket verifies that a client has recently been authenticated usually valid for a few hours ihas fixed begin/end time of validity 8 authenticator session-key encrypted token sent from client to server contains client name and timestamp proving identity of user and currency of server communication 8 session key randomly generated by authentication server used for encrypting all authenticators used for client-server communication whenever client requires it Comparison to Needham-Schroeder 8 uses time values to avoid re-use of old tickets impose lifetime for tickets iallows system to cancel authorization Distributed Systems - Fall 2001 VII - 43 Stefan Leue 2002 tele