1 / 25

Network Security: Security Protocols

Network Security: Security Protocols. Tuomas Aura T-110.5240 Network security Aalto University, Nov-Dec 2013. Outline. First security protocols: replay and freshness Key exchange protocol Diffie-Hellman key exchange Classic key-exchange protocols and flaws.

bessie
Télécharger la présentation

Network Security: Security Protocols

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related