Network Security Protocol Design Tuomas Aura T110 5240

Network Security: Protocol Design Tuomas Aura T-110. 5240 Network security Aalto University, Nov-Dec 2012

Outline First security protocols: replay and freshness Key exchange protocol Diffie-Hellman key exchange Classic key-exchange protocols and flaws 2

First security protocols: replay and freshness 3

The first broken protocol Meet Alice and Bob! A → B: M, SA(M) E. g. , SA(“Attack now!”) What is wrong with this protocol? 4

Replay and freshness Replay problem: A → B: M, SA(M) // SA(“Attack now!”) Authentication is usually not enough in network security! Need to also check freshness of the message “Fresh” may mean that the message was sent recently, or that has not been received before (exact definition depends on application) Freshness mechanisms: Timestamp Nonce Sequence number 5

Timestamps Checking freshness with A’s timestamp: A → B: TA, M, SA(TA, M) e. g. SA(“ 2010 -11 -03 14: 15 GMT”, “Attack now!”) Timestamp implementations: Sender’s clock value and time zone (fixed validity period) Validity period start and end times, or just end time Q: What potential problems remain? Timestamps require clocks at the signer and receiver, and secure clock synchronization Secure fine-grained synchronization is hard to achieve; loose synchronization (accuracy from minutes to days) is easier Also, fast replays possible while the timestamp is fresh: SA(TA, “Transfer £ 10. ”) 6

Nonces What if there are no synchronized clocks? Checking freshness with B’s nonce: A → B: “Hello, I’d like to send you a message. ” B → A: NB A → B: NB, M, SA(NB, M) Bob’s nonce is a bit string selected by Bob, which is never reused and (in many applications) must be unpredictable Nonce implementations: 128 -bit random number (unlikely to repeat and hard to guess) timestamp and a random number (protects against errors in RNG initialization and/or clock errors) More problematic nonces: sequence number, deterministic PRNG output, timestamp Nonces require extra messages and are not well suited for asynchronous or broadcast communication 7

Sequence numbers What if there are no synchronized clocks and nonces do not fit into the protocol design? Sequence numbers in authenticated messages allow the recipient to detect message deletion, reordering and replay A → B: seq, M, SA(seq, M) e. g. SA(“Transaction id=43542. Transfer 30€ to account 1006443. ”) Dangerous, but can sometimes ensure that messages are not processes out of order or twice Good combination: timestamp from a loosely synchronized clock and sequence number 8

Key exchange protocol

Purpose of key exchange Public-key cryptography: A and B each have a public-private key pairs and certificates Need to generate a symmetric shared secret session key Motivation: the session key is used for efficient protection (symmetric encryption and MAC) on session data Symmetric cryptography: A and B share a secret master key Need to generate a shared session key for short-term use Motivation: compromise of a session key quite likely; the seldom-used master key can be better protected The master key and certificates are called trust roots

Diffie-Hellman key exchange 12

Discrete logarithm problem Exponentiation in multiplicative group Zp*: Choose a large prime number p (e. g. 1024 bits long) Zp* is the group of integers 1…p-1 where the group operation is multiplication modulo p Exponentiation xk simply means multiplying x with itself k times (modulo p) g is a generator if gk for k=0, 1, 2, 3, … produces all the values 1…p-1 (see crypto literature for how to choose g) Discrete logarithm problem: given gk, solve k Believed to be a hard problem for large random values k (but quantum computers might change this) Exponentiation is commutative, i. e. (gx)y = (gy)x 13

Diffie-Hellman protocol: A chooses a random x. B chooses a random y. 1. A → B: A, gx 2. B → A: B, gy A calculates shared secret Kses = (gy)x = gxy. B calculates shared secret Kses = (gx)y = gxy. It works because exponentiation is commutative Sniffing attacker learns gx and gy but not x, y or gxy Security based on the computational Diffie-Hellman assumption: given g, gx and gy, it is infeasible to solve gxy Note 1: The calculations are done in Zp* i. e. modulo p Note 2: The prime p and generator g have been chosen beforehand are known by everyone (e. g. they can be standardized) Note 3: If you can solve discrete logarithms module p, then you can also solve the gxy 14

Impersonation and Mit. M attacks Unauthenticated Diffie-Hellman is insecure Protocol: 1. A → B: A, gx 2. B → A: B, gy SK = h(gxy) Impersonation attack: A → T(B): A, gx // Trent intercepts the message to B T(B) → A: B, gz // Trent spoofs the message from B SK = h(gxz) // A thinks SK is shared by A and B Man-in-the-middle attack: A → T(B): A, gx // Trent intercepts the message to B T(A) → B: A, gz // Trent spoofs the message from A B → T(A): B, gy // Trent intercepts the message to A T(B) → A: B, gz // Trent spoofs the message from B SK 1 = h(gxz) // A thinks SK 1 is shared by A and B SK 2 = h(gzy) // A thinks SK 2 is shared by A and B 15

Signed Diffie-Hellman (Toy protocol) Mit. M is prevented by authenticating the DH public keys Signed Diffie-Hellman (freshness? !): 1. A → B: A, gx, SA(A, gx), Cert. A 2. B → A: B, gy, SB(B, gy), Cert. B SK = h(gxy) Cert. A is a standard public-key certificate, e. g. X. 509, where the subject key is A’s public signature key But what about freshness? Freshness solution 1: use fresh random x and y each time Freshness solution 2: nonces (in which case x and y may be reused) 20

Signed DH with nonces and key confirmation (Somewhat realistic protocol) Signed Diffie-Hellman with nonces and key confirmation: 1. A → B: A, B, NA, gx, SA(“Msg 1”, A, B, NA, gx), Cert. A 2. B → A: A, B, NB, gy, SB(“Msg 2”, A, B, NB, gy), Cert. B, MACSK(A, B, “Responder done. ”) 3. A → B: A, B, MACSK(A, B, “Initiator done. ”) SK = h(NA, NB, gxy) Mutual entity authentication with nonces for freshness requires at least three messages Three messages also achieves key confirmation easily Almost unlimited ways to structure the protocol into 3 or 4 messages 21

Classic key-exchange protocols and flaws

Needham-Schroeder secret-key protocol The first secret-key key-exchange protocol 1978 Kerberos is based on this protocol Trusted server T shares a secret master key with everyone. It distributes a session key encrypted with the master keys: 1. 2. 3. 4. 5. A → T: A, B, NA 1 T → A: ETA(NA 1, B, Kses, ticket. AB) A → B: ticket. AB, Eses(NA 2) B → A: Eses(NA 2 -1, NB) A → B: E ses (NB-1) KTA, KTB = A’s and B’s master keys Kses = session key selected by T ticket. AB = ETB(Kses, A) “Encryption” must also protect integrity 23

Needham-Schroeder analysis The protocol again: 1. 2. 3. 4. 5. A → T: A, B, NA 1 T → A: ETA(NA 1, B, Kses, ticket. AB) A → B: ticket. AB, Eses (NA 2) B → A: Eses (NA 2 -1, NB) A → B: Eses (NB-1) // ticket. AB = ETB(Kses, A) T encrypts session key under A’s and B’s master keys Authenticators in messages 4– 5 for key confirmation NA 1 guarantees freshness of ticket and session key to A NA 2 and NB guarantee freshness of authenticators to A and B, respectively But no freshness of the ticket to B… 25

Needham-Schroeder vulnerability The protocol again: 1. 2. 3. 4. 5. A → T: A, B, NA 0 T → A: ETA(NA 0, B, Kses, ticket. AB) A → B: ticket. AB, Eses (NA) B → A: Eses (NA-1, NB) A → B: Eses (NB-1) // ticket. AB = ETB(Kses, A) Vulnerability discovered by Denning and Sacco 1981 Freshness of the ticket not guaranteed to B Assume attacker compromises an old session key and has sniffed the corresponding ticket, or Or assume attacker compromises A’s master key KTA. A’s master key is replaced but, before that, the attacker manages to obtain a ticket for B Replay attack by C who knows an old session key, pretending to be A: 3’. C(A) → B: ticket. AB-old, Eses-old (NA) 4’. B → C(A): Eses-old (NA-1, NB) 5’. C(A) → B: Eses-old (NB-1) // ticket. AB-old = EKTB-old(Kses-old, A) Lesson: protocols should withstand compromise of old secrets How to fix? 26

Denning-Sacco protocol Public-key exchange 1981; flaw found in 1994 A obtains certificates from trusted server T for both A’s and B’s public keys 1. A → T: A, B 2. T → A: Cert. A, Cert. B 3. A → B: EB(TA, Kses, SA(TA, Kses)), Cert. A, Cert. B Kses = session key selected by A EB = encryption with B’s public key Cert. A = A, PKA, ST (A, PKA) Analysis: Expiration time missing from certificates → should be added! Public-key encryption for secrecy of Kses → ok Time stamp for freshness → should do something about fast replays! Public-key signature for authentication → but what information exactly is authenticated? 27

Denning-Sacco vulnerability The protocol again: 1. A → T: A, B 2. T → A: Cert. A, Cert. B 3. A → B: EB(TA, Kses, SA(TA, Kses)), Cert. A, Cert. B The signed message SA(TA, KAB) does not contain all possible information What is missing? The signed message is not bound to the identity of B Does it matter when only B can decrypt the message? Yes because B could be bad! B can forward the last message to anyone else, e. g. to C: 3’. B(A) → C: EC(TA, KAB, SA(TA, KAB)), Cert. A, Cert. C C will think it shares Kses with A but it is really shared with B Legitimate user B can impersonate legitimate user A. Lesson: protocols should withstand insider attacks How to fix? 28

Needham-Schroeder public-key protocol The first public-key key-exchange protocol 1978; flaw found in 1995 [Lowe 95] A and B know each other’s public encryption keys or obtain certificates from a trusted server T as needed. Then, A and B exchange key material: 1. A → B: EB(NA, A) 2. B → A: EA(NA, NB) 3. A → B: EB(NB) NA, NB = secret nonces, also serving as key material EA, EB = encryption with A’s or B’s public key Kses = h(NA, NB) Analysis: Session key secret and fresh; entity authentication ok Session key not bound to A 29

What is a protocol flaw? Researchers like to present spectacular attacks and flaws but the reality is often less black and white Limitations on the applicability of the protocol: Can the protocols withstand insider attacks? Should multiple parallel executions be allowed with the same peer? Is the protocol used for its original purpose or for something different? Requirements for implementations: Encryption mode in old protocols is often assumed to protect integrity (MAC or non-malleable encryption) Signed and MAC’d messages must include type tags and be parsed unambiguously New attacks and requirements arise over time: Man-in-the-middle attacks Do. S protection, identity protection What next? E. g. firewall traversal, mobility support, load balancing in server farms, distribution to the cloud, session migration, . . . 33

Related reading Dieter Gollmann. Computer Security, 2 nd ed. : chapter 12; 3 rd ed. : chapter 15 Ross Anderson. Security Engineering, 2 nd ed. : chapter 3 William Stallings. Network security essentials: applications and standards, 4 th ed. chapter 4. 1 35