Bishop Chapter 10 Key Management csci 5233 Computer

Bishop: Chapter 10 Key Management csci 5233 Computer Security 1

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

Notation • X Y : { Z || W } k. X, Y – X sends Y the message produced by concatenating Z and W enciphered by key k. X, Y, which is shared by users X and Y • A T : { Z } k. A || { W } k. A, T – A sends T a message consisting of the concatenation of Z enciphered using k. A, A’s key, and W enciphered using k. A, T, the key shared by A and T • r 1, r 2: nonces (nonrepeating random numbers) csci 5233 Computer Security 3

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 k. B • k. B enciphers all session keys Alice uses to communicate with Bob • Called an interchange key – Alice sends { m } ks { ks } k. B csci 5233 Computer Security 4

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” } k. B and { “SELL” } k. B. Eve intercepts enciphered message, compares, and gets plaintext at once. csci 5233 Computer Security 5

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 csci 5233 Computer Security 6

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 k. A – Bob and Cathy share secret key k. B • Use this to exchange shared key ks csci 5233 Computer Security 7

Simple Protocol 1. Alice 2. Alice 3. Alice { request for session key to Bob } k. A { ks } k. A || { ks } k. B Cathy Bob • Then ks can be used as the secret key between Alice and Bob. e. g. , 4. Alice Bob {M} ks csci 5233 Computer Security 8

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. csci 5233 Computer Security 9

Needham-Schroeder 1. Alice 2. Alice 3. Alice 4. Alice 5. Alice || Bob || r 1 { Alice || Bob || r 1 || ks || { Alice || ks } k. B } k. A { Alice || ks } k. B { r 2 } k s { r 2 – 1 } k s csci 5233 Computer Security Cathy Bob Bob 10

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 r 1 in it matches r 1 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 csci 5233 Computer Security 11

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 r 2 and so can’t respond, or responds incorrectly csci 5233 Computer Security 12

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. a. Eve { Alice || ks } k. B b. Alice (intercepted by Eve) c. Eve { r 2 – 1 } k s csci 5233 Computer Security Bob { r 2 } k s Bob 13

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 csci 5233 Computer Security 14

Needham-Schroeder with Denning-Sacco Modification 1. Alice || Bob || r 1 Cathy { Alice || Bob || r 1 || ks || { Alice || T || ks } k. B } k. A 2. Alice Cathy 3. Alice { Alice || T || ks } k. B Bob • Bob will reject the message if T is too old. 4. Alice 5. Alice { r 2 } k s { r 2 – 1 } k s csci 5233 Computer Security Bob 15

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. csci 5233 Computer Security 16

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 csci 5233 Computer Security 17

The Protocol 1. Alice n || Alice || Bob || { r 1 || n || Alice || Bob } k. A Bob n || Alice || Bob || { r 1 || n || Alice || Bob } k. A || 2. Cathy Bob { r 2 || n || Alice || Bob } k. B 3. Cathy 4. Alice n || { r 1 || ks } k. A || { r 2 || ks } k. B n || { r 1 || ks } k. A csci 5233 Computer Security Bob 18

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 k. A. – Alice determines that the enciphered part belongs to the exchange as r 1 matches r 1 in encrypted part of the first message. csci 5233 Computer Security 19

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 k. B. – Bob knows that the enciphered part belongs to the exchange as r 2 matches r 2 in encrypted part of the second message. csci 5233 Computer Security 20

Replay Attack against the Otway. Rees Protocol ? • Eve acquires a ks and the message in the third step – n || { r 1 || ks } k. A || { r 2 || ks } k. B • 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. csci 5233 Computer Security 21

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 csci 5233 Computer Security 22

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 csci 5233 Computer Security 23

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 service s. – 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 csci 5233 Computer Security 24

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 csci 5233 Computer Security 25

csci 5233 Computer Security 26

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

Exercises 1. 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. 2. How is the session key between u and the TGS, i. e. , ku, TGS , used in the protocol? 3. How is the session key between u and the service provider s, i. e. , ku, s , used in the protocol? 4. c. f. , An alternative illustration of the Kerberos protocol: http: //sce. cl. uh. edu/yang/teaching/csci 5233 fall 02/Kerberos_Authenticati on_Steps. html csci 5233 Computer Security 28

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 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 csci 5233 Computer Security 29

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 csci 5233 Computer Security 30

Key Exchange using Public Key • Here interchange keys known – e. A, e. B : Alice and Bob’s public keys known to all – d. A, d. B : Alice and Bob’s private keys known only to the owner • Simple protocol – ks is the desired session key Alice { ks } e. B csci 5233 Computer Security Bob 31

Problem and Solution • Vulnerable to forgery or replay – Because e. B 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 Alice { { ks } d. A } e. B csci 5233 Computer Security Bob 32

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) csci 5233 Computer Security 33

Man-in-the-Middle Attack (in key exchange using public keys) Alice send Bob’s public key Eve Alice e. E Eve intercepts request send Bob’s public key e. B Eve Cathy Eve { ks } e. E Eve intercepts message Eve { ks } e. B csci 5233 Computer Security Bob 34

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 csci 5233 Computer Security 35

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

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– 1 j + … + a 1 nk– 1 a 0) mod n]: broken too • Here, “broken” means next number in sequence can be determined csci 5233 Computer Security 37

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, MD 5, SHA-1 – Use on UNIX-based systems: (date; ps gaux) | md 5 where “ps gaux” lists all information about all processes on system csci 5233 Computer Security 38

Next q Continued (Bishop, Chapter 10): • Cryptographic key infrastructure – • Key storage – – • Certificates Key escrow Key revocation Digital signatures csci 5233 Computer Security 39