Bishop: Chapter 9 Key Management

Bishop: Chapter 9Key Management Computer Security

Topics • Key exchange • Session vs interchange keys • Classical vs public key methods • Key generation • Cryptographic key infrastructure • Certificates • Key storage • Key escrow • Key revocation • Digital signatures Computer Security

Notation • XY : { Z || W } kX,Y • X sends Y the message produced by concatenating Z and W enciphered by key kX,Y, which is shared by users X and Y • AT : { Z } kA || { W } kA,T • A sends T a message consisting of the concatenation of Z enciphered using kA, A’s key, and W enciphered using kA,T, the key shared by A and T • r1, r2: nonces (nonrepeating random numbers) Computer Security

Session, Interchange Keys • Alice wants to send a message m to Bob • Assume public key encryption • Alice generates a random cryptographic key ks and uses it to encipher m • To be used for this message only • Called a session key • She enciphers ks with Bob’s public key kB • kB enciphers all session keys Alice uses to communicate with Bob • Called an interchange key • Alice sends { m } ks{ ks} kB Computer Security

Benefits • Limits amount of traffic enciphered with single key • Standard practice, to decrease the amount of traffic an attacker can obtain • Possible attacks • Example: Alice will send Bob a message that is either “BUY” or “SELL”. Eve computes possible ciphertexts { “BUY” } kB and { “SELL” } kB. Eve intercepts enciphered message, compares, and gets plaintext at once. Computer Security

Key Exchange Algorithms • Goal: Alice, Bob get shared key • Key cannot be sent in clear • Attacker can listen in • Key can be sent enciphered, or derived from exchanged data plus data not known to an eavesdropper • Alice, Bob may trust third party • All cryptosystems, protocols publicly known • Only secret data is the keys, ancillary information known only to Alice and Bob needed to derive keys • Anything transmitted is assumed known to attacker Computer Security

Classical Key Exchange • Bootstrap problem: how do Alice, Bob begin? • Alice can’t send it to Bob in the clear! • Assume trusted third party, Cathy • Alice and Cathy share secret key kA • Bob and Cathy share secret key kB • Use this to exchange shared key ks Computer Security

Simple Protocol { request for session key to Bob } kA 1. Alice Cathy { ks } kA || { ks } kB 2. Alice Cathy { ks } kB 3. Alice Bob • Then ks can be used as the secret key between Alice and Bob. • e.g., 4. Alice  Bob {M} ks Computer Security

Problems ? • How does Bob know he is talking to Alice? • Replay attack: Eve records message from Alice to Bob (esp. messages 3 and 4), later replays it; Bob may think he’s talking to Alice, but he isn’t. e.g., Session key reuse: Eve replays message from Alice to Bob, so Bob re-uses session key. e.g., Eve replays the message {“Deposit $500 to Jack’s account” }, originally sent from Alice to Bob. • Protocols must provide authentication and defense against replay. Computer Security

Needham-Schroeder Alice || Bob || r1 1. Alice Cathy { Alice || Bob || r1 || ks || { Alice || ks } kB } kA 2. Alice Cathy { Alice || ks } kB 3. Alice Bob { r2 } ks 4. Alice Bob { r2 – 1 } ks 5. Alice Bob Computer Security

Argument: Alice talking to Bob • Second message • Enciphered using key only she and Cathy know • So Cathy must have enciphered it • Response to first message • As r1 in it matches r1 in first message • Third message • Alice knows only Bob can read it • As only Bob can derive session key from that message • Any messages enciphered with that key are from Bob Computer Security

Argument: Bob talking to Alice • Third message • Enciphered using key only he and Cathy know • So Cathy must have enciphered it • Names Alice, session key • Cathy provided session key, says Alice is the other party //identity associated with the session key • Fourth message • Uses session key to determine if it is replay from Eve • If not, Alice will respond correctly in fifth message • If so, Eve can’t decipher r2 and so can’t respond, or responds incorrectly Computer Security

Denning-Sacco Modification • Assumption of Needham-Schroeder: All keys are secret. • Question: Suppose Eve can obtain the session key. How does that affect the protocol? • In what follows, Eve knows ks . { Alice || ks } kB a. Eve Bob { r2 } ks b. Alice (intercepted by Eve) Bob { r2 – 1 } ks c. Eve Bob Computer Security

Problem & Solution • In the protocol above, Eve impersonates Alice. • Problem: replay in the third step of Needham-Schroeder • i.e., Step a in the previous slide • Solution: use time stamp T to detect replay Computer Security

Needham-Schroeder with Denning-Sacco Modification Alice || Bob || r1 1. Alice Cathy { Alice || Bob || r1 || ks || { Alice || T || ks } kB } kA 2. Alice Cathy { Alice || T || ks } kB 3. Alice Bob • Bob will reject the message if T is too old. { r2 } ks 4. Alice Bob { r2 – 1 } ks 5. Alice Bob Computer Security

Needham-Schroeder with Denning-Sacco Modification • Weakness: If clocks are not synchronized, Bob may either reject valid messages or accept replays. • [Denning-Sacco]Parties with slow clocks are vulnerable to replay. • [Gong] Parties with fast clocks are also vulnerable. + Resetting clock does not eliminate vulnerability. Computer Security

Otway-Rees Protocol • Corrects the problem in the Needham-Schroeder • That is, Eve replaying the third message in the protocol • Does not use timestamps • Not vulnerable to the problems that Denning-Sacco modification has • Uses an integer n to associate all messages with particular exchange Computer Security

The Protocol n || Alice || Bob || { r1 || n || Alice || Bob } kA 1. Alice Bob n || Alice || Bob || { r1 || n || Alice || Bob } kA || { r2 || n || Alice || Bob } kB 2. Cathy Bob n || { r1 || ks } kA || { r2 || ks } kB 3. Cathy Bob n || { r1 || ks } kA 4. Alice Bob Computer Security

Argument: Alice talking to Bob • Fourth message • If n matches the first message, Alice knows it is part of this exchange protocol. • Cathy generated ks because only she and Alice know kA . • Alice determines that the enciphered part belongs to the exchange as r1 matches r1 in encrypted part of the first message. Computer Security

Argument: Bob talking to Alice • Third message • If n matches the second message, Bob knows it is part of this exchange protocol. • Cathy generated ks because only she and Bob know kB . • Bob knows that the enciphered part belongs to the exchange as r2 matches r2 in encrypted part of the second message. Computer Security

Replay Attack against the Otway-Rees Protocol ? • Eve acquires a ks and the message in the third step • n || { r1 || ks } kA || { r2 || ks } kB • Eve forwards appropriate part to Alice • Alice has no ongoing key exchange with Bob: n matches nothing, so is rejected. • Alice has ongoing key exchange with Bob: n does not match, so is again rejected. • If replay is for the current key exchange, and Eve sent the relevant part before Bob did, Eve could simply listen to traffic; no replay is needed for Eve to get the information. Computer Security

Kerberos • Authentication system • Based on Needham-Schroeder with Denning-Sacco modification • Central server plays role of trusted third party (“Cathy”) • Ticket • Issuer vouches for identity of requester of service • Authenticator • Identifies sender Computer Security

Idea • User u authenticates to the Kerberos server: • Obtains ticket Tu,TGS for ticket granting service (TGS) • User u wants to use service s: • User u sends authenticator Au, ticket Tu,TGS to the TGS asking for ticket for service s. • TGS sends ticket Tu,s to user u. • User sends Au, Tu,s to the server as a request to use s. • Details follow Computer Security

Ticket • Credential saying the ticket issuer (i.e., the authentication server) has identified the ticket requester (i.e., user u) • Example ticket issued to user u for service s Tu,s = s || { u || u’s address || valid time || ku,s } ks where: • ku,s is session key for user u and the ticket granting services. • ks is the key shared between s and the authentication server • Valid time is interval for which the ticket is valid. • u’s address may be IP address or something else • Note: more fields, but not relevant here Computer Security

Authenticator • Credential containing identity of the sender of a ticket • Used to confirm the sender is the entity to which the ticket was issued. • Example: an authenticator that user u generates for authenticating himself to service s Au,s = { u || generation time || kt } ku,s where: • kt is an alternate session key • Generation time is when authenticator generated • Note: more fields, not relevant here Computer Security

Computer Security

Protocol user || TGS 1. user Cathy { ku,TGS } ku || Tu,TGS Cathy 2. user service || Au,TGS || Tu,TGS 3. user TGS user || { ku,s } ku,TGS || Tu,s 4. user TGS Au,s || Tu,s 5. user service { t + 1 } ku,s 6. user service Computer Security

Exercises • In constructing Au,s (see steps 3 and 5), the user u needs to know his session key with s, i.e., ku,s. How does u get the session key? Hint: Show details of Au,s and Tu,s . • How is the session key between u and the TGS, i.e., ku,TGS, used in the protocol? • How is the session key between u and the service provider s, i.e., ku,s , used in the protocol? • c.f., An alternative illustration of the Kerberos protocol: http://sce.cl.uh.edu/yang/teaching/csci5233fall02/Kerberos_Authentication_Steps.html Computer Security

Analysis • First two steps get user ticket to use TGS • User u can obtain session key, ku,TGS , only if u knows key shared with Cathy, Ku . • Next four steps show how u gets and uses ticket for service s • Service s validates request by checking sender (using Au,s) is the same as entity ticket issued to • Step 6 optional; used when u requests confirmation Computer Security

Problems • Relies on synchronized clocks • If not synchronized and old tickets, authenticators not cached, replay is possible. • Tickets have some fixed fields • Dictionary attacks possible • Kerberos 4 session keys weak (had much less than 56 bits of randomness); researchers at Purdue found them from tickets in minutes • Solutions? A potential research or survey project Computer Security

Key Exchange using Public Key • Here interchange keys known • eA, eB : Alice and Bob’s public keys known to all • dA, dB : Alice and Bob’s private keys known only to the owner • Simple protocol • ks is the desired session key { ks } eB Alice Bob Computer Security

Problem and Solution • Vulnerable to forgery or replay • Because eB known to anyone, Bob has no assurance that it was really Alice that sent the message • Simple fix uses Alice’s private key • ks is the desired session key { { ks } dA } eB Alice Bob Computer Security

Notes • Can include message enciphered with ks • Assumes Bob has Alice’s public key, and vice versa • If not, each must get it from a public server • If keys not bound to identity of the owner, attacker Eve can launch a man-in-the-middle attack (next slide; Cathy is public server providing public keys) • Solution to this (binding identity to keys) discussed later as public key infrastructure (PKI) Computer Security

Man-in-the-Middle Attack (in key exchange using public keys) Eve intercepts request send Bob’s public key Alice Cathy send Bob’s public key Cathy Eve eB Cathy Eve eE Eve Alice { ks } eE Eve intercepts message Bob Alice { ks } eB Bob Eve Computer Security

Key Generation • Goal: generate difficult-to-guess keys • Problem statement: given a set of K potential keys, choose one randomly • Equivalent to selecting a random number between 0 and K–1 inclusive • Why is this hard: generating random numbers • Actually, numbers are usually pseudo-random, that is, generated by an algorithm Computer Security

What is “Random”? • Sequence of cryptographically ransom numbers: a sequence of numbers n1, n2, … such that for any integer k > 0, an observer cannot predict nk even if all of n1, …, nk–1 are known • Best: physical source of randomness • Random pulses • Electromagnetic phenomena • Characteristics of computing environment such as disk latency • Ambient background noise Computer Security

What is “Pseudorandom”? • Sequence of cryptographically pseudorandom numbers: sequence of numbers intended to simulate a sequence of cryptographically random numbers but generated by an algorithm • Very difficult to do this well • Linear congruential generators [nk = (ank–1 + b) mod n]: broken • Polynomial congruential generators [nk = (ajnk–1j + … + a1nk–1 a0) mod n]: broken too • Here, “broken” means next number in sequence can be determined Computer Security

Best Pseudorandom Numbers • Strong mixing function: function of 2 or more inputs with each bit of output depending on some nonlinear function of all input bits • Examples: DES, MD5, SHA-1 • Use on UNIX-based systems: (date; ps gaux) | md5 where “ps gaux” lists all information about all processes on system Computer Security

Exercise #1 • The term “session” in “session keys” may be one of the following three cases: • A session is a fixed period of time, say 60 sec or 20 min, and so on. • A session is the time between two events. For example, a user session is established from the time the user logs in, until the user logs off. • A session is a message. In all three cases, a session key is created and used throughout that session. This exercise has two components: • Give an example of session keys for each of the three cases. Provide sufficient details for people to understand your examples. • What are the relative pros and cons of the three types of session keys? Justify your answer. Computer Security

Exercise #2 • Classical Key Exchange includes a set of protocols that use only classical cryptography to generate session keys. The Needham-Schroeder protocol was proposed as a remedy against replay attacks that may be launched against the simple protocol. This exercise has two components: • Would the Needham-Schroeder protocol successfully mitigate the replay attacks that can be effectively launched against the simple protocol? Justify your answer. • Perform a vulnerability analysis on the Needham-Schroeder protocol. Can any of the five steps in that protocol be effectively replayed? Justify your answer. Computer Security

Exercise #3 • Public Key Cryptographic Key Exchange is briefly discussed in 9.2.3. A simple protocol was proposed. In that protocol, when entity A wants to share a session key with entity B, A first encrypts the session key with her own private key and then enciphers the resulting ciphertext with the B’s public key. A  B: { { ks } dA } eB This exercise has two components: • Do you agree with the author that such a simple protocol based on public key cryptography would effectively enable key exchange between A and B. Justify your answer. Hint: What security services are provided in this protocol? Is it subject to common attacks like fabrication attacks, man-in-the-middle attacks, or replay attacks? • Present a complete solution relaying on public key cryptography. Explain why your protocol would be an effective solution. Computer Security

Bishop: Chapter 9 Key Management