network security security protocols n.
Skip this Video
Loading SlideShow in 5 Seconds..
Network Security: Security Protocols PowerPoint Presentation
Download Presentation
Network Security: Security Protocols

Network Security: Security Protocols

250 Vues Download Presentation
Télécharger la présentation

Network Security: Security Protocols

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Network Security: Security Protocols Tuomas Aura T-110.5240 Network securityAalto University, Nov-Dec 2013

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

  3. First security protocols:replay and freshness

  4. The first broken protocol • Please meet Alice and Bob! • Alice sends a signed message to Bob: A → B: M, SA(M) E.g., SA(“Attack now!”) • What is wrong with this protocol?

  5. Replay and freshness • Replayproblem: 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

  6. 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, UTC (validity period is fixed or determined by the receiver) • 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.”)

  7. 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) • Sometimes used as nonces: sequence number, deterministic PRNG output, timestamp only (easy to make mistakes) • Nonce requires an extra message or roundtrip • Not well suited for asynchronous or broadcast communication

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

  9. Key exchange protocol

  10. Purpose of key exchange • With public-key cryptography: • A and B each have a public-private key pairs and certificates • Need to generate a symmetric shared secret session key • The public keys are used for the key exchange, and the session keys are used for efficient protection (symmetric encryption and MAC) on session data • In systems that use symmetric cryptography only: • A and B share a secret master key, e.g. strong password • 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

  11. Diffie-Hellman key exchange

  12. Discrete logarithm problem • Exponentiation in multiplicative group Zp*: • Choose a large prime numberp (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 • Unauthenticated Diffie-Hellman key exchange: A and B have previously agreed on g and p. 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, p, 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 calculate the shared secret gxy • Note 4: It is generally assumed, but not proven, that solving gxy is as difficult as solving the discrete logarithm Note:Thisprotocol is notsecure likethis. Pleasereadfurther.

  14. Impersonation and MitM 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 SK1 = h(gxz) // A thinks SK1 is shared by A and B SK2 = h(gzy) // A thinks SK2 is shared by A and B

  15. Signed Diffie-Hellman • MitM is prevented by authenticating the DH public keys • Signed 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 (new) random x and y each time • Freshness solution 2: nonces (in which case x and y may be reused) Note: This is still an impracticaltoyprotocol. Pleasereadfurther.

  16. Signed DH with nonces and key confirmation Somewhatrealisticprotocol • 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 easily • There are almost unlimited ways to structure the protocol into 3 or 4 messages

  17. Classic key-exchange protocols and flaws

  18. 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 each user. When Alice and Bob need a session key, T creates a random one and distributes itencrypted 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: Eses(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

  19. Needham-Schroeder analysis • The 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 keys • Authenticators in messages 4–5 for key confirmation • NA1 guarantees freshness of ticket and session key to A • NA2 and NB guarantee freshness of authenticators to A and B, respectively • But no freshness of the ticket to B…

  20. Needham-Schroeder vulnerability • The 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 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: 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 secrets • How to fix?

  21. Denning-Sacco protocol • Public-key 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: 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?

  22. Denning-Sacco vulnerability • The protocol again: 1. A → T: A, B 2. 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 B • Does it matter when only B can decrypt the message? Yes because B could be bad! • B can forwardthe 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 attacks • How to fix?

  23. Needham-Schroeder public-key protocol • The 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 ok • Session key not bound to A

  24. What is a protocol flaw? • Security 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 in old protocol specifications is often assumed to protect also integrity (use a 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 • DoS protection, identity protection • What next? E.g. firewall traversal, mobility support, load balancing in server farms, protection of weak secrets, distribution to the cloud, session migration, ...

  25. Related reading • Colin Boyd, AnishMathuria. Protocols for authentication and key establishment, Springer 2003: chapter 1 • Dieter Gollmann. Computer Security, 2nd ed.: chapter 12; 3rd ed.: chapter 15 • Ross Anderson. Security Engineering, 2nd ed.: chapter 3 • William Stallings. Network security essentials: applications and standards, 4th ed. chapter 4.1