Computer Networks & Security 2016/2017

Transcription

1 Computer Networks & Security 2016/2017 Network Security Protocols (10) Dr. Tanir Ozcelebi Courtesy: Jerry den Hartog Courtesy: Kurose and Ross TU/e Computer Science Security and Embedded Networked Systems

2 Why network security protocols? Alice Bob A: To allow trustworthy communication over an untrusted channel (e.g. the Internet) Slide 2

3 What is a network security protocol? Message exchanges between several parties format and order of messages Uses (mainly) symmetric or public key crypto Typical goals: Confidentiality Who can read it? Authentication Who sent it? Integrity Has it been altered? Anonymity Who could ve sent it? Non-Repudiation Can deny usage?. Slide 3

4 Security protocols are out there Confidentiality Authentication Slide 4

5 Design of an example authentication protocol Goal: Alice wants to authenticate herself to Bob over the Internet. The informal dialog: Hi, I m Alice Prove It! Here s the proof Slide 5

6 Recall: Authentication over a Network Protocol ap1.0: Alice says I am Alice I am Alice Failure scenario?? Slide 6

7 Recall: Authentication over a Network Protocol ap1.0: Alice says I am Alice I am Alice in a network, Bob can not see Alice, so Trudy simply declares herself to be Alice Slide 7

8 Recall: Authentication: another try Protocol ap2.0: Alice says I am Alice in an IP packet containing her source IP address Alice s IP address I am Alice Failure scenario?? Slide 8

9 Recall: Authentication: another try Protocol ap2.0: Alice says I am Alice in an IP packet containing her source IP address Alice s IP address I am Alice Trudy can create a packet spoofing Alice s address Slide 9

10 Recall: Authentication: another try Protocol ap3.0: Alice says I am Alice and sends her secret password to prove it. Alice s IP addr Alice s password I m Alice Alice s IP addr OK Failure scenario?? Slide 10

11 Recall: Authentication: another try Protocol ap3.0: Alice says I am Alice and sends her secret password to prove it. Alice s IP addr OK playback attack: Trudy records Alice s packet and later plays it back to Bob Alice s IP addr Alice s password I m Alice Slide 11

12 Recall: Authentication: yet another try Protocol ap3.1: Alice says I am Alice and sends her encrypted secret password to prove it. Alice s IP addr encrypted password I m Alice Alice s IP addr OK Failure scenario?? Slide 12

13 Recall: Authentication: yet another try Protocol ap3.1: Alice says I am Alice and sends her encrypted secret password to prove it. Alice s IP addr OK record and playback still works! Alice s IP addr encrypted password I m Alice Slide 13

14 NEW! Yet another try using shared key Goal: avoid playback attack Nonce: a random number (N) ap4.0: to prove Alice is live, Bob sends Alice nonce, N. Alice must return N, encrypted with shared secret key I am Alice N Drawback: Requires shared secret key! Failure?: Perhaps while sharing the secret key. K AB (N) Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice! Slide 14

15 NEW! Authentication: ap5.0 using public key ap5.0: use nonce, public key cryptography I am Alice N Failure scenario? Bob computes + - K (K (N)) = N A A - and knows only Alice could have the private key, that encrypted N such that + - K (K (N)) = N A A K (N) A Slide 15

16 ap5.0: Security hole MITM attack Trudy poses as Alice (to Bob) and as Bob (to Alice) - + m = K (K (m)) A A I am Alice N K A + - K A (N) send public key + K (m) A N Trudy gets - + m = K (K (m)) T T sends m to Alice encrypted with Alice s public key I am Alice send public key K + T + K (m) T - K (N) T Slide 16

17 Example: MIG-in-the-middle identify friends and enemies An example application where incorrect use of a good authentication protocol results in vulnerability. Green team security plan in own airspace: Identify friend fighter jets (remote authentication) Launch rockets against jets that are not able to authenticate Slide 17

18 Green team security plan incorrect use of remote authentication Slide 18

19 Example: MIG-in-the-Middle identify friends and enemies An example application where incorrect use of a good authentication protocol results in vulnerability. Green team security plan in own airspace: Identify friend fighter jets (remote authentication) Launch rockets against jets that are not able to authenticate Red team (counter-)strategy: Exploit vulnerability of green team strategy. MIG-in-the-middle attack Slide 19

20 Red team plan: MIG-in-the-Middle authenticated locally present Slide 20

21 Authentication with secret identify in one of the two ways Identify by sending secret e.g. garage door remote control Problems: reveals secret, can be replayed Identify by challenge-response challenge guarantees freshness; e.g. a fresh nonce response proves known secret; e.g. encryption of nonce but does not reveal secret (the private key in this case) key holder is known to be active after sending of nonce still need to establish they want to authenticate authenticating party can be anywhere on network... Slide 21

22 Authentication on a network Recall MIG-in-the-middle: not a flaw in authentication protocol flaw in security requirements / use of protocol; authenticated locally present In this case app. needs `locally present not `authenticated Networks: challenge-response vulnerable to relay attack A challenges C C passes challenge on to B and returns B s response Slide 22

23 Authentication on a network Network property: A almost never directly talks to B routers, ISPs, in between Relay is not considered an attack on protocol (*) C can be a (correctly behaving) part of network between A, B. Additional authentication property in network B authenticated to A: B is currently active, running same protocol. (*) Recall discussion security model Slide 23

24 So, how do we design an authentication protocol? We implement the dialog using public-key encryption and nonces AàB : A BàA : { Nb }pk(a) AàB : { Nb }pk(b) Hi, I m Alice Prove It! Here s the proof The first response does not have to be encrypted. can be encrypted to keep Nb secret; so A and B may use it to build a session key. Slide 24

25 Correct protocol design is difficult! Q : Are we completely sure that this protocol is secure? Equivalently: each time that Alice and Bob finish the execution, Is A really who she says she is? Is Nb secret? AàB : A BàA : { Nb }pk(a) AàB : { Nb }pk(b) Hi, I m Alice Prove It! Here s the proof Slide 25

26 What can go wrong? AàM : A M(A) 1 àb : A BàA : { Nb }pk(a) MàA: { Nb }pk(a) AàM: { Nb }pk(m) M(A)àB: { Nb }pk(b) Hi, I m Alice Hi, I m Alice Prove It! Prove It! Here s the proof Here s the proof M 1) M `pretending to be A. `M(A) is the same as `M. Slide 26

27 What can go wrong? AàM : A M(A) 1 àb : A BàA : { Nb }pk(a) MàA: { Nb }pk(a) AàM: { Nb }pk(m) M(A)àB: { Nb }pk(b) Hi, I m Alice Hi, I m Alice Prove It! Prove It! Here s the proof Here s the proof A successful man-in-the-middle attack against protocol: M has impersonated A wrt B! Moreover, M knows Nb Slide 27

28 Not an attack against the protocol as seen before AàM(B) : A M(A)àB : A BàM(A) : { Nb }pk(a) M(B)àA : { Nb }pk(a) AàM(B) : { Nb }pk(b) M(A)àB : { Nb }pk(b) Hi, I m Alice Hi, I m Alice Prove It! Prove It! Here s the proof Here s the proof M Slide 28

29 Not an attack against the protocol as seen before AàM(B) : A M(A)àB : A BàM(A) : { Nb }pk(a) M(B)àA : { Nb }pk(a) AàM(B) : { Nb }pk(b) M(A)àB : { Nb }pk(b) Hi, I m Alice Hi, I m Alice Prove It! Prove It! Here s the proof Here s the proof Here M is just being a faithful network. Sequence looks similar but is very different (authentication ok & also secrecy of Nb not broken). Slide 29

30 The patch Alice was tricked into answering a challenge from Bob. AàB : A BàA : { Nb, B }pk(a) AàB : { Nb }pk(b) Hi, I m Alice Prove It to B! Here s the proof Are we now completely sure that this protocol is secure? Slide 30

31 Patch fixes it AàM: A M(A)àB : A BàA : { Nb, B }pk(a) MàA: { Nb, B }pk(a) A?? was expecting {..., M }pk(a) Hi, I m Alice Hi, I m Alice Prove It to B! Prove It to B! (A stops protocol) But is that enough, are there no other attacks? formal analysis to be sure Slide 31

32 Motivation (formal) analysis Security Protocols are difficult to do right! Security protocols are three line programs that people still manage to get wrong. (Roger Needham) (Famous) example: Needham-Schroeder created in 1978, flaw found in Using formal methods! Security requirements Attacker model: What can an attacker do? Slide 32

33 What can do? Total network control: See all exchanged messages Delete, alter, inject and redirect messages Initiate new communications (has a valid identity) Reuse messages from past sessions Usually known as formal attacker, Dolev-Yao model. Good for automatic verification: Finite participants, infinite messages à decidable Infinite participants à undecidable Slide 33

34 What cannot do... Break strong crypto Solve hard problems (factor long primes, etc.) Guess pseudo-random values (e.g. nonces) Get other identities (identity theft) Slide 34

35 Attacker model (Dolev-Yao) All communication through attacker Attacker builds knowledge (AK) Sending message adds it to AK Derivation of other knowledge compose messages; m, m in AK => < m, m > in AK decompose messages; <m, m > in AK => m, m in AK decrypt if key known; { m }k and k in AK => m in AK encrypt with known key; m and k in AK => { m }k in AK Attacker can send messages that are in AK Slide 35

36 Checking authentication manually (validate with automated formal method) Checking authentication of Alice should at least address: 1. A secret of Alice is used; a challenge that only Alice can answer ensures that the attacker cannot complete the authentication without involving Alice 2. Freshness of Alice s response; the secret has to be used in this session and not be e.g. replayed from an earlier session. 3. Alice s response is meant for Bob; when Alice is not trying to authenticate to Bob it should not be possible to trick her into answering the challenge for the attacker. Slide 36

37 Manually checking authentication in our patched protocol AàB : A BàA : { Nb, B }pk(a) AàB : { Nb }pk(b) We ve solved a specific attack. Lets go through our checklist to convince ourselves it is now correct: 1. Secret of A used? Yes, her private key 2. Response is fresh? Yes due to fresh nonce 3. No tricking Alice into answering challenge? Alice only answers: {?, C }pk(a) in a run with user C So { Nb, B }pk(a) only answered in a run with B. Slide 37

38 Needham-Schroeder (1978) AàB : { A,Na }pk(b) BàA : { Na,Nb }pk(a) AàB : { Nb }pk(b) Goals: Mutual Authentication of A and B Exchange two secrets can be used to create a key for further interaction Slide 38

39 What can go wrong in NS? basically same attack as before An Attack: A à M: { A,Na }pk(m) M(A) à B: { A,Na }pk(b) B à A: { Na,Nb }pk(a) A à M: M(A) à B: { Nb }pk(m) { Nb }pk(b) AàB : { A,Na }pk(b) BàA : { Na,Nb }pk(a) AàB : { Nb }pk(b) Attack breaks: (M is attacker) Secrecy Na and Nb are disclosed Authentication B thinks he is talking to A, while he is talking to M Slide 39

40 The Patch same problem, same patch AàB : { A,Na }pk(b) BàA : { Na,Nb,B }pk(a) AàB : { Nb }pk(b) Flaw found & patch proposed by Lowe Patched protocol known as: Needham-Schroeder-Lowe (NSL) Slide 40

41 Manually checking mutual authentication in NSL AàB : { A,Na }pk(b) BàA : { Na,Nb,B }pk(a) AàB : { Nb }pk(b) Attack stopped as before, lets go through our checklist: 1. Secret of A, secret of B used? Their private keys 2. Response is fresh? Both encrypt a fresh nonce 3. No tricking A, B into answering challenge? B answers with { Nx,?,B }pk(x) in a run X starts with B A sends { A,? }pk(x) in a run A started with X Is there a way to confuse? Let us look at a slightly easier example. Slide 41

42 Otway-Rees Protocol 1. AàB : Ms, A, B,{ Na,Ms,A,B }Kas 2. BàS : Ms, A, B,{ Na,Ms,A,B }Kas, { Nb,Ms,A,B }Kbs 3. SàB : Ms, { Na,Kab }Kas, { Nb,Kab }Kbs 4. BàA : Ms, { Na,Kab }Kas Aim: key distribution using trusted server Ms: Session ID Kab: short-term key Na and Nb serve as challenges. Slide 42

43 Attack on O-R type flaw attack a.1 AàM(B) : Ms,A,B,{ Na,Ms,A,B }Kas a.4 M(B)àA : Ms,{ Na,Ms,A,B }Kas (A expects: Ms,{ Na, Kab }Kas) Type flaw attack A takes (Ms,A,B) to be the key Kab Authentication failure Secrecy failure (as attacker knows Ms, A and B). Check: The intruder just replies with part of the first message Alice accepts fake response, Kbs not used (check 1 fails) Slide 43

44 Type flaw attack on NSL AàB : { A,Na }pk(b) BàA : { Na,Nb,B }pk(a) AàB : { Nb }pk(b) I.1 AàM(B) : { A,Na }pk(b) (M intercepts msg from A) II.1 M(A)àB : { A,M }pk(b) (M starts fake session) II.2 BàM(A) : { M,Nb,B }pk(a) (B responds to fake session) III.1 MàA : { M,(Nb,B) }pk(a) (M starts helper session) III.2 AàM: { (Nb,B),Na',A }pk(m) (A s helper session response) II.3. M(A)àB: { Nb }pk(b) (M has Nb so can make this) helper session Note that msg II.2 is the same as msg III.1 Rather unrealistic; A would need to accept (Nb, B) as a nonce (msg III.1) B would have to accept M as a nonce (msg II.1) Slide 44

45 Running multiple protocols 2 `good protocols may not combine well: Basic challenge response: A à B: { Na }pk(b) B à A: Na Does not combine with protocol that uses pk(b) for secrecy Similar: Signing + pk encryption with RSA Solutions: Analyze protocols together Use different keys/secrets for different protocols Slide 45

46 Summary Finding flaws is not easy! Analysis is difficult to do by hand. One can use formal methods; belief logics, theorem proving, model checking, Slide 46