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

Network Security: Protocol Design

Tuomas AuraT-110.5240 Network security

Aalto University, Nov-Dec 2012

2

OutlineFirst security protocols: replay and freshnessKey exchange protocolDiffie-Hellman key exchangeClassic key-exchange protocols and flaws

First security protocols:replay and freshness

3

4

The first broken protocolMeet Alice and Bob!A → B: M, SA(M)

E.g., SA(“Attack now!”)

What is wrong with this protocol?

5

Replay and freshnessReplay 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:

TimestampNonceSequence number

6

TimestampsChecking 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 synchronizationSecure fine-grained synchronization is hard to achieve; loose synchronization (accuracy from minutes to days) is easierAlso, fast replays possible while the timestamp is fresh: SA(TA, “Transfer £10.”)

7

NoncesWhat 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 unpredictableNonce 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, timestampNonces require extra messages and are not well suited for asynchronous or broadcast communication

8

Sequence numbersWhat 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 replayA → 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 twiceGood combination: timestamp from a loosely synchronized clock and sequence number

Key exchange protocol

Purpose of key exchangePublic-key cryptography:

A and B each have a public-private key pairs and certificatesNeed to generate a symmetric shared secret session keyMotivation: the session key is used for efficient protection (symmetric encryption and MAC) on session data

Symmetric cryptography:A and B share a secret master keyNeed to generate a shared session key for short-term useMotivation: 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

13

Discrete logarithm problemExponentiation 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 pExponentiation 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 kBelieved 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

14

Diffie-HellmanDiffie-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 commutativeSniffing 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 and 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

15

Impersonation and MitM attacksUnauthenticated Diffie-Hellman is insecureProtocol: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 BT(B) → A: B, gz // Trent spoofs the message from BSK = h(gxz) // A thinks SK is shared by A and BMan-in-the-middle attack:A → T(B): A, gx // Trent intercepts the message to BT(A) → B: A, gz // Trent spoofs the message from AB → T(A): B, gy // Trent intercepts the message to AT(B) → A: B, gz // Trent spoofs the message from BSK1 = h(gxz) // A thinks SK1 is shared by A and B

SK2 = h(gzy) // A thinks SK2 is shared by A and B

20

Signed Diffie-HellmanMitM is prevented by authenticating the DH public keysSigned Diffie-Hellman (freshness?!):1. A → B: A, gx, SA(A, gx), CertA

2. B → A: B, gy, SB(B, gy), CertB

SK = h(gxy)CertA 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 timeFreshness solution 2: nonces (in which case x and y may be reused)

(Toy protocol)

21

Signed DH with nonces and key confirmation

Signed Diffie-Hellman with nonces and key confirmation:1. A → B: A, B, NA, gx, SA(“Msg1”, A, B, NA, gx), CertA

2. B → A: A, B, NB, gy, SB(“Msg2”, A, B, NB, gy), CertB, 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 easilyAlmost unlimited ways to structure the protocol into 3 or 4 messages

(Somewhat realistic protocol)

Classic key-exchange protocols and flaws

23

Needham-Schroeder secret-key protocolThe first secret-key key-exchange protocol 1978Kerberos is based on this protocolTrusted server T shares a secret master key with everyone. It distributes a session key encrypted with the master keys:

1. A → T: A, B, NA1

2. T → A: ETA(NA1, B, Kses, ticketAB)

3. A → B: ticketAB, Eses(NA2)

4. B → A: Eses(NA2-1, NB)

5. A → B: E ses (NB-1)KTA, KTB = A’s and B’s master keys

Kses = session key selected by T

ticketAB = ETB(Kses,A)

“Encryption” must also protect integrity

25

Needham-Schroeder analysisThe protocol again:

1. A → T: A, B, NA1

2. T → A: ETA(NA1, B, Kses, ticketAB) // ticketAB = ETB(Kses,A)

3. A → B: ticketAB, Eses (NA2)

4. B → A: Eses (NA2-1, NB)

5. A → B: Eses (NB-1)

T encrypts session key under A’s and B’s master keysAuthenticators in messages 4–5 for key confirmationNA1 guarantees freshness of ticket and session key to A

NA2 and NB guarantee freshness of authenticators to A and B, respectivelyBut no freshness of the ticket to B…

26

Needham-Schroeder vulnerabilityThe protocol again:

1. A → T: A, B, NA0

2. T → A: ETA(NA0, B, Kses, ticketAB) // ticketAB = ETB(Kses,A)

3. A → B: ticketAB, Eses (NA)

4. B → A: Eses (NA-1, NB)

5. A → B: Eses (NB-1)

Vulnerability discovered by Denning and Sacco 1981Freshness of the ticket not guaranteed to BAssume attacker compromises an old session key and has sniffed the corresponding ticket, orOr 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: ticketAB-old, Eses-old (NA) // ticketAB-old = EKTB-old(Kses-old,A)

4’. B → C(A): Eses-old (NA-1, NB)

5’. C(A) → B: Eses-old (NB-1)

Lesson: protocols should withstand compromise of old secretsHow to fix?

27

Denning-Sacco protocolPublic-key key exchange 1981; flaw found in 1994A obtains certificates from trusted server T for both A’s and B’s public keys

1. A → T: A, B2. T → A: CertA, CertB

3. A → B: EB(TA, Kses, SA(TA, Kses)), CertA, CertB

Kses = session key selected by A

EB = encryption with B’s public key

CertA = 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?

28

Denning-Sacco vulnerabilityThe protocol again:

1. A → T: A, B2. T → A: CertA, CertB

3. A → B: EB(TA, Kses, SA(TA, Kses)), CertA, CertB

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 BDoes 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)), CertA, CertC

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 attacksHow to fix?

29

Needham-Schroeder public-key protocolThe first public-key key-exchange protocol 1978; flaw found in 1995 [Lowe95]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 okSession key not bound to A

33

What is a protocol flaw?Researchers like to present spectacular attacks and flaws but the reality is often less black and whiteLimitations 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 attacksDoS protection, identity protectionWhat next? E.g. firewall traversal, mobility support, load balancing in server farms, distribution to the cloud, session migration, ...

35

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