Modelling and Analyzing of Security Protocol: Introductions to Modelling Protocols

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

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

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”

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

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

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

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.

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

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

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

Rule The attacker can repeat any message it see.

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

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.

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

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

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.

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

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.

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

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 )

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

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 )

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

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

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

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

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 )

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

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 )

A Hierarchy of Goals Good Key Fresh Key Key Exclusivity

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.

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 )

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 )

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 )

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

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

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

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”

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

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)

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

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

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.

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

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

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

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.

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.

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

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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?

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

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.

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

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.

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.

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

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.

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.

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.

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)

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)

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?