Computer Security Authentication in Distributed Systems 3 16 2018 1

Computer Security Authentication in Distributed Systems 3/16/2018 1

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. 2

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. 3

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: Encryption Signature Master key Decryption Non-repudiation Transaction key … • With RSA, we don’t use a single key pair both for encryption and for digital signatures. 4

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 5

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) 6 memorandum on Internet systems and standards]

HTTP Basic Authentication • Client: • Server: GET /index. html HTTP/1. 0 HTTP/1. 1 401 Unauthorized WWW-authenticate Basic realm="Secure. Area" GET /index. html HTTP/1. 0} Authorization: Basic am 9 ld. XNlcjph. Lm. Iu. Qy 5 E HTTP/1. 1 200 Ok (plus document) • Password sent in the clear, base 64 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. ] 7

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] 8

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. 9

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 10

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? 11

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. 12

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. 13

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. 14

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

Key Establishment Protocols AKEP Needham-Schroeder protocol Kerberos

AKEP 2 • AKEP 2: 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 17

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

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

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 ga mod p to B • B picks a random value b, 2 b p-2, computes the shared key (ga)b = gab mod p and sends gb mod p to A • Upon receiving gb mod p, A computes the shared key (gb)a = gab mod p. 20

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. 21

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

Station-to-station Protocol • Authenticated variant of Diffie-Hellman key agreement. • A and B use a digital signature algorithm: SA(m) denotes A’s signature on m. • A and B use a symmetric encryption algorithm: Ek(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. 23

Station-to-station Protocol A B: ga mod p B A: gb mod p, Ek(SB(gb, ga)) A B: Ek(SA(ga, gb)) shared key k = gab mod p Security properties of STS: • Key agreement • Mutual entity authentication • Explicit key authentication 24

Man-in-the-middle Attack? C needs B’s signature on ga A ? ? C ? ? B C could forward B’s message but cannot compute gab 25

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 Kab from server S (Trusted Third Party). • A shares a secret key Kas with S, B shares a secret key Kbs with S. • Nonces n. A and n. B are used to prevent 26 replay attacks.

Needham-Schroeder Protocol S A B 27

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. 28

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

Password-based Protocols • Use the password P to encrypt a randomly generated session key Ks; use session key to encrypt further data. – A B: e. P(Ks) – B A: e. Ks(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. 30

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 Ka, Ka-1. • Step 1: A sends public key Ka to B, encrypted under the password P (symmetric encryption). • Step 2: B randomly generates session key Ks; sends Ks to A encrypted first under Ka (publickey enc. ) and then under P (symmetric enc. ): – A B: e. P(Ka) – B A: e. P(e. Ka(Ks)) 31

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. 32 • Uses a symmetric encryption algorithm.

Kerberos TGS 4 3 KAS 2 1 A 5 6 B 1. A, TGS, L 1, N 1 2. e. Ka(TGS, Ka, tgs, Ticketa, tgs, L 1, N 1) Ticketa, tgs= e. Ktgs(Ka, tgs, A, T 1, L 1) 3/16/2018 33

Kerberos TGS 4 3 KAS 3. 4. 5. 6. 2 1 A 5 6 B A, B, L 2, N 2 , Ticketa, tgs, e. Ka, tgs(A, T 3) e. Ka, tgs(B, Ka, b, Ticketa, b, L 2, N 2) e. Ka, b(A, T 4), Ticketa, b e. Ka, b(T 4) Ticketa, b = e. Kb(Ka, b, A, T 2, L 2) 3/16/2018 34

Kerberos Remarks: In the basic Kerberos scheme the session keys are symmetric. The encryption keys Ka (or Kb) can be symmetric, or alternatively Public Encryption Keys may be used. Revocation: The KAS and TGS update their access rights database. 3/16/2018 35

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 3/16/2018 36

The DSSA/SPX authentication protocol CDC 1 5 2 A 1. 2. 4 3 6 B B Certificate (B, CAa) = s. SCAa (CAa , B, Lc , Pb) (signed with the private signature key of CAa) Lc , expiry date; Pb longterm public key of B 3/16/2018 37

DSSA/SPX CDC 1 5 2 A 3. 4. 5. 6. 4 3 6 B A, e. Ka, b (T, A), s. Sa(Lt, A, Pa’), e. Pb(Ka, b), e. Ka, b(Sa’) A Certificate (A, CAb) e. Ka, b(T) T = timestamp, Pa’, Sa’, short term public/private keys of A 3/16/2018 38

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. 3/16/2018 39

Security Application Program Interfaces • Software engineering uses a well-established strategy for dealing with such issues. • Application Program Interfaces allow an application Lc , P b 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 securityspecific tasks. 3/16/2018 40

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. 3/16/2018 41

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. 3/16/2018 42

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 3/16/2018 43

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

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. 3/16/2018 45

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. 3/16/2018 46