1. Modelling and Analyzing of Security Protocol: Introductions to Modelling Protocols

2. “You have zero privacy anyway, get over it”
Scott, CEO of SUN microsystems.

3. A Simple Protocol A M B “A” sends message “M” to “B”: written as:
A  B : M A M B

4. Rules
We write down protocols as a list of messages sent between “principals”, e.g.
1. A  B : “Hello”
2. B  A : “Offer”
3. A  B : “Accept”

5. A Simple Protocol A M B
Message “M” can be read by the attacker

6. Rule
The attacker can read all the messages sent across the network.

7. Encryption { M }Kab A B We can keep our data safe by using encryption:
A  B : { M }Kab

8. Rule We can use We assume that these are prefect
Encryption {M}K, EK(M)
Signing SignK(M), SK(M), MACK(M)
Hashing #(M), Hash(M)
We assume that these are prefect
cannot be broken by brute force.

9. Encryption
“M” is now secret
{ M }Kab A B
but the protocol is not safe

10. Replay Attack
1: { Pay Elvis €5 }Kab A B
1) A  B : { Pay Eve €5 }Kab

11. Replay Attack A B E 1) A  B : { Pay Eve €5 }Kab
1: { Pay Elvis €5 }Kab A B E
2: { Pay Elvis €5 }Kab
1) A  B : { Pay Eve €5 }Kab
2) E  B : { Pay Eve €5 }Kab

12. Rule
The attacker can repeat any message it see.

13. A Nonce A B A  B : A 2. B  A : { Na }Kab
3. {Na + 1}Kab , { Pay Elvis €5 }Kab
A  B : A
2. B  A : { Na }Kab
3. A  B : { Na + 1 }Kab , { Pay Elvis €5 }Kab

14. Rule We can generate nonces. This is a new random values.
If you generate a new nonce for a session you know that all future messages with that include that nonce are part of the same session.

15. A Nonce A B 1. A 2. { Na }Kab 3. {Na + 1}Kab , { Pay Elvis €5 }Kab
6. {Na2 + 1}Kab , { Pay Bob €5 }Kab

16. A Nonce A B E 1. A 2. { Na }Kab 3. {Na + 1}Kab , { Pay Elvis €5 }Kab
{ Pay Bob €5 }Kab
6’. {Na2 + 1}Kab ,
{ Pay Elvis €5 }Kab

17. Rule The attacker can run multiple rounds of the protocol.
break up messages,
invent new values, keys, nonces,..
combine any of these into new message.

18. A Better Protocol A B 1. A  B : A, Na 2. B  A : { Na }Kab
3. {Na , Pay Elvis €5 }Kab
1. A  B : A, Na
2. B  A : { Na }Kab
3. A  B : {Na, Pay Elvis €5 }Kab

19. Key Establishment Protocol
This was easy because A and B shared a key.
Often the principals do not share a key, in which case we need a “Key Establishment Protocol”.
This usually involves a “Trust Third Party” who has a shared key with each party.

20. The Needham-Schroeder Public Key Protocol
A famous authentication protocol
1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb )
3. A  B : EB( Nb )
Na and Nb can then be used to generate a symmetric key

21. An Attack Against the Needham-Schroeder Protocol
The attack acts as a man-in-the-middle:
1. A  C : EC( Na, A )
1`. C(A)  B : EA( Na, A )
2`. B  C(A) : EA( Na, Nb )
2. C  A : EA( Na, Nb )
3. A  C : EC( Nb )
3`. C(A)  B : EB( Nb )

22. The Corrected Version A very simple fix: 1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb )
3. A  B : EB( Nb )

23. The Corrected Version A very simple fix: 1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb, B)
3. A  B : EB( Nb )

24. Rule The attacker can act as a participant of the protocol.
... (sometimes)

25. Kerberos
A protocol for key establishment and authentication used in Windows, MacOS, Apache, OpenSSH, ...
A S : A,B,NA
S A : {KAB,B,L,NA,..}KAS,{KAB,A,L,..}KBS
A B : {A,TA}KAB,{KAB,A,L,..}KBS
B A : {TA+1}KAB

26. Kerberos A S : A,B,NA S A : {KAB,B,L,NA,..}KAS,{KAB,A,L,..}KBS
A and S share the key KAS and B and S share KAS
Both A and B trust S to generate a new key for them: KAB
N is a nonce, T is a timestamp and L is an expiration time.
A S : A,B,NA
S A : {KAB,B,L,NA,..}KAS,{KAB,A,L,..}KBS
A B : {A,TA}KAB,{KAB,A,L,..}KBS
B A : {TA+1}KAB

27. The Needham-Schroeder Protocol
An (in) famous authentication protocol
1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb )
3. A  B : EB( Nb )
Na and Nb can then be used to generate a symmetric key

28. An Attack Against the Needham-Schroeder Protocol
The attack acts as a man in the middle:
1. A  C : EC( Na, A )
1`. C(A)  B : EA( Na, A )
2`. B  C(A) : EA( Na, Nb )
2. C  A : EA( Na, Nb )
3. A  C : EC( Nb )
3`. C(A)  B : EB( Nb )

29. The Corrected Version A very simple fix: 1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb )
3. A  B : EB( Nb )

30. The Corrected Version A very simple fix: 1. A  B : EB( Na, A )
2. B  A : EA( Na, Nb, B)
3. A  B : EB( Nb )

31. A Hierarchy of Goals
Good Key
Fresh Key
Key Exclusivity

32. A Good Key is Not Enough
A “Good Key” provides a secure communication channel....
... but we have no idea who is on the other end of the channel.
We need authentication as well.

33. Authentication Goals The most simple:
Far-end Operative: A knows that “B” is currently active:
For instance B might have signed a nonce generated by A e.g.
A  B : Na
B  A : SignB ( Na )

34. Authentication Goals
and
Once Authentication: A knows that B wishes to communicate with A
For instance, B might have the name A in a message e.g.
B  A : SignB ( A )

35. Entity Authentication
Both of these together give:
Entity Authentication: A knows that B is currently active and wants to communicate with A.
e.g.
A  B : Na
B  A : SignB ( A, Na )

36. A Hierarchy of Goals Entity Authentication Good Key Fresh Key
Key Exclusivity
Far-end
Operative
Once
Authenticated

37. Key Confirmation A common goal is:
Key Confirmation of A to B is provided if
B can be sure that “K” is a good key to communicate with A
and that A knows “K”.

38. A Hierarchy of Goals Key Confirmation Entity Authentication Good Key
Fresh Key
Key Exclusivity
Far-end
Operative
Once
Authenticated

39. The Highest Goal Mutual Belief in Key: is provided for B only if
“K” is a good key with A
A believes that “K” is a good key for “B”
and A wishes to communicate with B using “K”

40. A Hierarchy of Goals Mutual Belief in Key Key Confirmation Entity
Authentication
Good Key
Fresh Key
Key Exclusivity
Far-end
Operative
Once
Authenticated

41. Example: Diffie-Hellman
The Diffie-Hellman is a widely used key agreement protocol.
It relies on some number theory:
a mod b = n where m s.t. a = m.b + n
The protocol uses two public parameters
generator “g” (often 160 bits long)
prime “p” (often 1024 bits long)

42. Diffie-Hellman K = grArB mod p
A and B pick random numbers rA and rB and calculate “tA = grA mod p” and “tB = grB mod p”
The protocol just exchanges these numbers:
A  B : tA
B  A : tB
A calculates “tBrA mod p” and B “tA rB mod p”
this is the key:
K = grArB mod p
Ta^rb mod p = ( g^ra mod p )^rb mod p = g^rarb mod p = g^rbra mod p = ( g^rb mod p )^ra mod p = Tb^ra mod p

43. Diffie-Hellman K = grArB mod p
A and B pick random numbers rA and rB and calculate “tA = grA mod p” and “tB = grB mod p”
The protocol just exchanges these numbers:
A  B : p, g, tA
B  A : tB
A calculates “tArA mod p” and B “tA rB mod p”
this is the key:
K = grArB mod p
Ta^rb mod p = ( g^ra mod p )^rb mod p = g^rarb mod p = g^rbra mod p = ( g^rb mod p )^ra mod p = Tb^ra mod p

44. Diffie-Hellman
An observer cannot work out rA and rB from tA and tB therefore the attacker cannot calculate the key
The values of “g” and “p” must be big enough to make it intractable to try all possible combinations.
So we have a “Good Key” but know nothing about the participants.
We did not need to share any keys at the start, therefore this is a very powerful protocol.

45. Some Common Types of Attack
Eavesdropping
Modification
Replay / Preplay
Man-in-the-Middle
Reflection
Denial of Service
Typing Attack

46. Eavesdropping An Eavesdropping attack only passively observe messages.
Protocols defend against Eavesdropping attacks by using encryption for confidentiality.
The attacker is a passive outsider.

47. Modification A Modification attack alters or replaces some messages.
Protocols often define against Modification attacks by using encryption for binding.

48. Replay / Preplay
The attacker sends a message that it has observed as part of the protocol run.
Protocols defend against replay attacks by make the message clear so that it cannot be replayed out of context.

49. Reflection
Reflection attacks are a kind of replay attack that use a protocol against itself.
The attacker provides the “proof” of authentication by challenging the challenger.

50. Reflection Attack Example
In this protocol A and B share the key K. They want to ensure they both take part in the protocol.
A  B : { Na }K
B  A : Na , { Nb }K
A  B : Nb

51. Reflection Attack Example
1. A  E(B) : { Na1 }K
1’. E(B)  A : { Na1 }K
2’. A  E(B) : Na1 , { Na2 }K
2. E(B)  A : Na1 , { Na2 }K
A  E(B) : Na2
3’. E(B)  A : Na2

52. Man-in-the-Middle
In a Man-in-the-Middle attack the attacker gets in the middle of a real run of a protocol. A B

53. Man-in-the-Middle A B E
In a Man-in-the-Middle attack the attacker gets in the middle of a real run of a protocol. A B E

54. Denial of Service (DoS)
Every communication request uses an amount of memory and CPU.
A DoS attack tries to use up all of a severs CPU or memory by making 1,000,000s of requests.
All systems can be subject to a DoS attack...
... but some protocols can make this better or worse.

55. A Protocol Vulnerable to Denial of Service
A uses its public key Ka to establish a session key Kas
A  S : A , Na
S  A : EKa ( Na , Ns, Kas )
A  S : { Ns }Kas
S is particularly vulnerable to a DoS attack because for
each connection is has to:
generate a nonce and a key,
perform a public key encryption.
allocate memory for the nonce and the key.

56. A Protocol Resistant to Denial of Service
A uses S’s public key Ks to establish a session key Kas
A  S : Eks(A, S, SignA(Na,Kas) )
S  A : { Na }Kas
Now A has to do the expensive encryption in order to make S do any more than a single decryption.
Therefore may more “bots” would be needed for a successful attack.

57. SYN flood DoS Attack TCP starts a session by:
A  S : SYN
S  A : ACK,SYN (add A to the table of connections)
A  S : ACK ( ~ 3 min. time out )
The “SYN flood” attack sends lots of SYN messages to S and fills its tables, therefore real requests will be ignored.

58. Typing Attack
In a typing attack the attacker passes off one type of message as being another.
This kind of attack may not work on a real implementation...
... but is also hard to spot.

59. Typing Attack Example
Andrews secure RPC protocol is a handshake, then a key distribution:
A  B : { NA }Kab
B  A : { NA + 1, NB }Kab
A  B : { NB + 1}Kab
B  A : { Ks , N’ }Kab

60. Typing Attack Example A  B : { NA }Kab B  A : { NA + 1, NB }Kab
A  B : { NB + 1}Kab
E(B)  A : { NA + 1, NB }Kab
The attacker replays message 2. “A” now uses the wrong key...
but the attacker only learns it if NA is predicable.

61. Some Common Types of Attack
Eavesdropping
Modification
Replay / Preplay
Man-in-the-Middle
Reflection
Denial of Service
Typing Attack

62. Very Important :
Whenever you do something secure over the Internet (i.e., logon remotely, check your bank balance, pay a bill), think about the protocol used.
Is the communication secure?
Have you established a key? Is it fresh?
Think about who has been authenticated:
Have you been authenticated?
Has the computer you’re talking to?

63. Kerberos
A protocol for key establishment and authentication used in Windows, MacOS, Apache, OpenSSH, ...
A S : A,B,NA
S A : {KAB,B,L,NA,..}KAS,{KAB,A,L,..}KBS
A B : {A,TA}KAB,{KAB,A,L,..}KBS
B A : {TA+1}KAB

64. Kerberos Assumption A and S share the key KAS
B and S share the key KAS
A trusts S to generate a new key
B trusts S to generate a new key
N is a nonce, T is a timestamp and L is an expiration time.

65. What Do We Mean By Correct?
“Good Key” and “Key Confirmation”:
A believes that KAB is a good key to communicate with B
B believes that KAB is a good key to communicate with A
A believes that B believes that KAB is a good key to communicate with A

66. Why “A” Believes in the Key?
A’s belief in the key comes from the message:
2. {KAB,B,L,NA,..}KAS,{KAB,A,L,..}KBS
This line and the assumptions are all “A” needs.

67. Why “A” Believes in the Key?
Step 1: A sees the message part {KAB,B,L,NA,..}KAS
As the key KAS is only shared with A and S the part of
the message (KAB,B,L,NA) must have come from S.
Rule: If A and S share a key K
and A sees a message { M }K (not from A)
then A can conclude that S said “M” at some point.

68. Why “A” Believes in the Key?
Step 1: A believes that S said (KAB,B,L,NA) at some point
NA is A’s nonce therefore this cannot be an old message
therefore A can conclude that S said (KAB,B,L,NA) as part of the current run of the protocol.
Rule: If A believe that S once said M
and M includes a nonce
then A can conclude that S currently believes M

69. Why “A” Believes in the Key?
Step 1: A believes that S currently believes (KAB,B,L,NA) and in particular KAB as a key for A and B.
A trusts S to makes keys for A and B, therefore A can accept KAB as a key with B.
Rule: If A trusts S to produce keys
and A believes that S believes in a key
then A believe in the key.

70. Verify this Argument There are 4 parts to this argument:
The assumptions.
The protocol messages.
The rules.
The application of the rules.
If the check each of these parts you can be sure the whole proof is correct.

71. Logic
A “logic” is a formal system of reasoning. They specify rules for knowledge, e.g.
Rule: If you know that “A implies B” and you know “A” then you may conclude “B”
General Idea: the logic fixes the rules and you or a computer applies them. If the rules lead your goal then you know it’s true.

72. Logic Classic Logic uses: A /\ B and A \/ B or ~ A not
A => B implies
 x.A(x) For all
 x.A(x) Exist
and rules like:
A /\ B A
A => B A B

x. A(x)
A(y)

73. Proof Trees
All men are mortal, Plato is a man, therefore Plato is mortal.
 x. Man(x)  Mortal(x)
Man(Plato)  Mortal(Plato) Man(Plato)
Mortal(Plato)

74. Very Important :
Whenever you do something secure over the Internet (i.e., logon remotely, check your bank balance, pay a bill), think about the protocol used.
Is the communication secure?
Have you established a key? Is it fresh?
Think about who has been authenticated:
Have you been authenticated?
Has the computer you’re talking to?