1. 8/13/20151 Computer Security Authentication in Distributed Systems

2. 2 Introduction Crypto transforms (communications) security problems into key management problems. To use encryption, digital signatures, or MACs, the parties involved have to hold the “right” cryptographic keys. With public key algorithms, parties need authentic public keys. With symmetric key algorithms, parties need shared secret keys.

3. 3 Session Keys Public key algorithms tend to be more expensive than symmetric key algorithm. Cost factors: key length, computation time, bandwidth. It is desirable to use long-term keys only sparingly to reduce the “attack surface”. Potential problem: attacks that collect a large amount of encrypted material. Solution: long-term keys establish short term session keys.

4. 4 Key Usage It is good cryptographic practice to restrict the use of keys to a specific purpose. In key management, we may use key encrypting keys and data encrypting keys. Examples for key usages: EncryptionDecryption Signature Non-repudiation Master key Transaction key … With RSA, we don’t use a single key pair both for encryption and for digital signatures.

5. 5 Agenda Remote user authentication Definitions for key establishment Diffie-Hellman key agreement Man-in-the-middle attacks STS – station-to-station protocol AKEP Needham-Schroeder Perfect forward secrecy Kerberos

6. 6 Using Passwords Remotely Sending passwords over the network –HTTP Basic Access Authentication (http protocol) —password in clear –HTTP Digest Access Authentication (http protocol) —digest of password –Password sniffers Challenge-response protocols Off-line dictionary attacks Remote Authentication Dial-In User Service (RADIUS), RFC 2865 [RFC = Request for Comments, an Internet Engineering Task Force (IETF) memorandum on Internet systems and standards]

7. 7 HTTP Basic Authentication Client: GET /index.html HTTP/1.0 Server: HTTP/1.1 401 Unauthorized WWW-authenticate Basic realm="SecureArea" Client: GET /index.html HTTP/1.0} Authorization: Basic am9ldXNlcjphLmIuQy5E Server: HTTP/1.1 200 Ok (plus document) Password sent in the clear, base64 encoded. Not really secure: anybody who can see the user’s reply learns the password. [NB: GET /index.html HTTP/1.0 is a client request for a specified resource HTTP/1.1 401 is a status code that indicates a provisional response; 401 indicates unauthorized. ]

8. 8 HTTP Digest Authentication Challenge-response protocol (RFC 2617). Server sends random challenge (nonce) to user. User replies with hash (digest) of username+password+nonce+uri: request-digest = h ( h (username:realm:password): nonce: h (method:digest-uri)) Better security but still vulnerable to off-line dictionary attacks. [uri = uniform resource identifier of abstract or physical resource]

9. 9 Nonces The term “nonce” was proposed Needham & Schroeder for unique values that are used only once. Three ways of generating nonces: –Random numbers –Time stamps –Sequence numbers Nonces are used to prevent replay attacks Nonces are used to guarantee “freshness”. In some applications, nonces have to be unpredictable.

10. 10 Terminology Once, protocols establishing a session key were called authentication protocols After all, it is their purpose to let you know “whom you are talking to” In the literature, in particular in older sources, you may still find this convention Today’s convention in cryptology distinguishes between authentication and key establishment

11. 11 Types of Assurances Reciprocity: unilateral or mutual authentication. Key freshness: is there a protection against replay attacks? Key control: who generates the key? Sometimes attacks are possible if one party can pick a key with specific properties. Third party requirements: is a Trusted Third Party (TTP) involved, off-line or on-line?

12. 12 Key Establishment (HAC) Key establishment is a process whereby a shared secret key becomes available to two or more parties, for later cryptographic use. Key transport: one party creates the secret value and securely transfers it to the other(s). Key agreement: both parties contribute to the generation of the secret value much that no party can predict the outcome.

13. 13 Key Authentication Key authentication: one party is assured that no other party aside from a specifically identified second party may gain access to a particular secret key. Key confirmation: one party is assured that a second (possibly unidentified) party has possession of a particular secret key. Explicit key authentication: both key authentication and key confirmation hold.

14. 14 Key Establishment & TTPs In a protocol like STS where key authentication is based on digital signatures, a Trusted Third Party (TTP) may have to vouch for the authenticity of verification keys. In a protocol where authentication is based on symmetric cryptographic algorithms, a TTP may serve as a key distribution centre (KDC) supplying parties with session keys.

15. 15 Authentication – Overview (Entity) authentication Peer entity authentication – IS 7498 Key agreement Key establishment Key transport Entity authentication – IS 9798 Key authentication Key confirmation Explicit key authentication Dead peer detection

16. Key Establishment Protocols AKEP Needham-Schroeder protocol Kerberos

17. 17 AKEP2 AKEP2: Authenticated Key Exchange Protocol 2 Uses symmetric authentication mechanisms but does not rely on a TTP Parties A and B share long-term symmetric keys K and K’ They use a keyed hash function (MAC) h K and a keyed one-way function h’ K’ It is frequently a design criterion to avoid the use of encryption algorithms

18. 18 AKEP2 Let n A and n B be random nonces picked by A and B respectively. AKEP2 is a three-pass protocol: 1.A  B: A, n A 2.B  A: B, A, n A, n B, h K (B,A,n A,n B ) 3.A  B: A, n B, h K (A,n B ) The shared key is k = h’ K’ (n B ) AKEP2 provides mutual entity authentication and (implicit) key authentication.

19. 19 Reminder: DLP Let p be a prime and a generator g of high order modulo p Exponentiation a  g a mod p is a one-way function. Discrete Logarithm Problem (DLP): given p, g, and y, find the discrete logarithm a so that y = g a mod p Exponentiation mod p is commutative: (g a ) b mod p = g ab mod p = (g b ) a mod p

20. 20 Diffie-Hellman Key Agreement Parties A and B do not share an initial secret but agree on a prime p and a generator g A picks a random value a, 2  a  p- 2, and sends g a mod p to B B picks a random value b, 2  b  p- 2, computes the shared key (g a ) b = g ab mod p and sends g b mod p to A Upon receiving g b mod p, A computes the shared key (g b ) a = g ab mod p.

21. 21 Diffie-Hellman – Security Which security properties do we get from Diffie- Hellman key agreement? It is a key agreement protocol. Secrecy: An attacker observing the messages exchanged does not learn the key. No authentication: The parties do not know whom they are establishing a key with.

22. 22 Man-in-the-middle Attacks An attacker C sitting between A and B can mount a man-in-the- middle attack: ACB

23. 23 Station-to-station Protocol Authenticated variant of Diffie-Hellman key agreement. A and B use a digital signature algorithm: S A (m) denotes A ’s signature on m. A and B use a symmetric encryption algorithm: E k (m) denotes encryption of m under key k. A and B agree on a prime p and a generator g of order p-1 modulo p.

24. 24 Station-to-station Protocol Security properties of STS: Key agreement Mutual entity authentication Explicit key authentication A  B: g a mod p B  A: g b mod p, E k (S B (g b,g a )) A  B: E k (S A (g a,g b )) shared key k = g ab mod p

25. 25 Man-in-the-middle Attack? ACB C needs B’s signature on g a ?? C could forward B’s message but cannot compute g ab ??

26. 26 Needham-Schroeder Protocol Proposed in a landmark paper in 1978 and basis for the widely used Kerberos protocol. Key transport protocol based on a symmetric encryption algorithm: A and B obtain a session key K ab from server S (Trusted Third Party). A shares a secret key K as with S, B shares a secret key K bs with S. Nonces n A and n B are used to prevent replay attacks.

27. 27 Needham-Schroeder Protocol S AB

28. 28 Needham-Schroeder Protocol The server (key distribution centre) has to be “trusted”: it knows the session keys and could deceive A and B about the actual identity of the corresponding party. Achieves unilateral entity authentication of A to B (messages 4+5), key establishment, and key confirmation. There exists also a public key version of the Needham-Schroeder protocol.

29. 29 Denning-Sacco Attack The NS protocol achieves its goals under the (standard) assumption that the long term keys K as and K bs are not compromised. Denning & Sacco discovered an attack where the adversary C impersonates A re-using a compromised session key K ab : CB from original protocol run

30. 30 Password-based Protocols Use the password P to encrypt a randomly generated session key K s ; use session key to encrypt further data. – A  B : e P ( K s ) –B  A: e K s (data) Vulnerable to off-line dictionary attack. Attacker guesses password P, decrypts first message and gets a candidate session key K' s ; decrypt the second message with K' s. When result is meaningful text, it is likely that the password had been guessed correctly.

31. 31 Encrypted Key Exchange (EKE) Symmetric encryption algorithm to encrypt data with the password as the key. In a protocol run, user A generates a random public key/private key pair K a, K a -1. Step 1: A sends public key K a to B, encrypted under the password P (symmetric encryption). Step 2: B randomly generates session key K s ; sends K s to A encrypted first under K a (public-key enc.) and then under P (symmetric enc.): – A  B : e P ( K a ) –B  A: e P (e K a ( K s ))

32. 32 Kerberos Kerberos was developed at MIT for user authentication in a distributed system. The parties involved are client A, server B, and Kerberos authentication server (KAS) S. Based on the Needham-Schroeder key establishment (“authentication”) protocol: the server provides A and B with a session key. Uses a symmetric encryption algorithm.

33. 8/13/201533 Kerberos 1.A, TGS, L 1, N 1 2.e K a (TGS,K a,tgs,Ticket a,tgs,L 1,N 1 ) Ticket a,tgs = e K tgs (K a,tgs, A, T 1, L 1 ) TGS B A KAS 2 16 5 4 3

34. 8/13/201534 Kerberos 3.A, B, L 2, N 2, Ticket a,tgs, e K a,tgs (A, T 3 ) 4.e K a,tgs (B, K a,b, Ticket a,b, L 2, N 2 ) 5.e K a,b (A, T 4 ),Ticket a,b 6.e K a,b (T 4 ) Ticket a,b = e K b (K a,b, A, T 2, L 2 ) TGS B A KAS 2 16 5 4 3

35. 8/13/201535 Kerberos Remarks: In the basic Kerberos scheme the session keys are symmetric. The encryption keys K a (or K b ) can be symmetric, or alternatively Public Encryption Keys may be used. Revocation: The KAS and TGS update their access rights database.

36. 8/13/201536 DSSA/SPX DSSA = Distributed Secure System Architecture SPX = a product developed by Digital Equipment Corporation Authentication is based on credentials and authentication Tokens. Certification authority Issues certificates off-line. Certificate Distribution Centre Stores certificates and issues these on-line

37. 8/13/201537 The DSSA/SPX authentication protocol 1.B 2.Certificate (B, CA a ) = sS CA a (CA a, B, L c, P b ) (signed with the private signature key of CA a ) L c, expiry date; P b longterm public key of B CDC 2 1 B A 6 3 5 4

38. 8/13/201538 DSSA/SPX 3.A, e K a,b (T, A), sS a (L t, A, P a ’), e P b (K a,b ), e K a,b (S a ’) 4.A 5.Certificate (A,CA b ) 6.e K a,b (T) T = timestamp, P a ’, S a ’, short term public/private keys of A CDC 2 1 B A 6 3 5 4

39. 8/13/201539 Security Application Program Interfaces A comprehensive Distributed Secure System Architecture must address the following: Security requirements that may exceed mere authentication. Different components will not necessarily use the same security mechanisms. Users and application writers are not necessarily security experts.

40. 8/13/201540 Security Application Program Interfaces Software engineering uses a well-established strategy for dealing with such issues. Application Program Interfaces allow an application in one layer to call a service in an application in the layer below. By hiding implementational details the API can relieve the application programmer from security- specific tasks. L c, P b

41. 8/13/201541 GSS- Application Program Interface The Generic Security Services (GSS) of an Application Program Interface were originally conceived to provide portability between DSSAs such as Kerberos. Their main goals is to support: Mechanism independence Protocol environment independence Suitability to a range of implementation placements.

42. 8/13/201542 Generic Security Services-API A typical GSS-API caller is a communications protocol that calls on GSS-API services to protect its communication with authentication, integrity and/or confidentiality. The basic security elements of a GSS-API are: Credentials (contain security related data) Tokens Security contexts Status codes.

43. 8/13/201543 Generic Security Services-API Credentials Contain security related data Tokens Data supplied to GSS-API is converted to mechanism-specific tokens. Security contexts Capture the information related to the management of the security services. Security contexts are established between peers using credentials. Multiple contexts may exist simultaneously between pairs of peers, using the same or different sets of credentials

44. 8/13/201544 Application Program Interfaces and Security Status codes Status flags bare are set to indicate which features are desired, e.g. mutual_req_flag indicates that mutual authentication is requested

45. 8/13/201545 Application Program Interfaces and Security Interface descriptions There are 4 types of calls Credential management calls, to acquire & release credentials Context-level calls, for initiation, acceptance or deletion of contexts Per-message calls, for integrity & confidentiality Support calls, for general housekeeping and support routines Provision of security services does not only depend on the proper implementation of the relevant security mechanisms, but also on proper security management.

46. 8/13/201546 Common Object Request Broker Architecture Security The Generic Security Services of an Application Program Interface are an interface to a set of security services. For a distributed system the services layer is the most appropriate location for security enforcement. An object request broker (ORB) handles interactions between users and objects, and objects themselves. Sharing data between applications may involve programs written in different languages, for different hardware and software platforms, using different data formats. That is, we have interoperability problems. The Common Object Request Broker Architecture (CORBA) is the specification of an industry standard to deal with such problems.