verification of security protocols chapter 3: secrecy and secrecy types

of 60/60
Verification of Security Protocols Chapter 3: Secrecy and Secrecy Types

Post on 19-Jan-2018

229 views

Category:

Documents

1 download

Embed Size (px)

DESCRIPTION

An External Attack on Secrecy A generates secrets s, s' and publics p, p' A -> B : ({s, p}k, {p', s'}k ) B -> A : (p, p') An attack: A -> I : ({s, p}k, {p', s'}k ) // intruder intercepts I -> B : ({p', s'}k, {s, p}k ) // intruder swaps ciphers B -> A : (s', s) // B publishes secrets The problem here is that B misinterprets the format Attacks that rely on these mechanisms are called type flaw attacks.

TRANSCRIPT

Verification of Security Protocols Chapter 3: Secrecy and Secrecy Types Plan for Today We will learn how to specify secrecy against external and internal attackers in the spi-calculus model. We will learn how types can ensure secrecy against external attackers. An External Attack on Secrecy A generates secrets s, s' and publics p, p' A -> B : ({s, p}k, {p', s'}k ) B -> A : (p, p') An attack: A -> I : ({s, p}k, {p', s'}k ) // intruder intercepts I -> B : ({p', s'}k, {s, p}k ) // intruder swaps ciphers B -> A : (s', s) // B publishes secrets The problem here is that B misinterprets the format Attacks that rely on these mechanisms are called type flaw attacks. Fixing the protocols (1) A -> B : ({s, p}k, {p', s'}k ) B -> A : (p, p') First possibility: fixed message format Require that all messages encrypted by the same key have the same type. A -> B : ({s, p}k, {s', p'}k ) B -> A : (p, p') Disadvantage: Each key can only be used for a fixed type of messages. Fixing the protocols (2) A -> B : ({s, p}k, {p', s'}k ) B -> A : (p, p') Second possibility: type tags Tag each plaintext with a label that identifies the type of the plaintext.. A -> B : ({secpub,s, p}k, {pubsec,p', s'}k ) B -> A : (p, p') Agents must always check if received messages carry the expected tags. Synonyms: tags, type tags, dynamic types External Threat Model In the previous example, the intruder is not a regular participant of the protocol. Often it makes sense to assume that all regular protocol participants are honest. This assumption is called an external threat model Internal Threat Model. Sometimes we want to grant the possibility that some regular protocol participants are compromised. Of course, an honest participant who communicates with a compromised participant cannot expect any security. However, it is desirable that secure communication between honest participants cannot be breached by compromised participants. If we assume that, in addition to external attackers, there are compromised protocol participants, we talk of an internal threat model. A Vulnerability to Internal Attack kas is a shared symmetric key of A and server S kbs is a shared symmetric key of B and server S 1. A -> B : A // I want to send you a secret 2. B -> A : N // Here is a nonce challenge 3. A -> B : {s,N}kas 4. B -> S : {A, {s,N}kas}kbs 5. S -> B : {s,N}kbs Now B expects that s is a secret that he shares with A Even if A is honest, Bs expectation is unjustified in an internal threat model-> A Vulnerability to Internal Attack 1. I(A) -> B : A 1. I -> B : I 2. B -> I(A) : NA 2. B -> I : NI 3. I(A) -> B : G // some arbitrary G 3. I -> B : {s,NA}kis // NA instead of NI 4. B -> S : {A,G}kbs // S aborts this run 4. B -> S : {I, {s,NA}kis}kbs 5/5. S -> B : {s,NA}kbs // B thinks this is from A I is a compromised participant, playing (also) A S sends the last message as part of the primed session, but B accepts it as part of the unprimed session. Fixing the Protocol 1. A -> B : A // I want to send you a secret 2. B -> A : N // Here is a nonce challenge 3. A -> B : {s,N}kas 4. B -> S : {A, {s,N}kas}kbs 5. S -> B : {s,N}kbs Fix: include agent identity S should include As name in the last message. 5. S -> B : {s,A,N}kbs B should check on receipt if A is the name he expects. Spi-calculus: Assertions In order to specify security goals, we will insert assertions into processes: A ::= syntax class of assertions Syntactically, assertions can appear anywhere where processes are allowed: P ::= | A Assertions have no effect on the operational semantics of processes. They are inert processes. Synonyms: assertions, claims, expectations Spi-calculus: Opponent Processes We model opponents as arbitrary spi-calculus processes... ... except that it does not make sense that opponent processes contain assertions. Definition (Opponent Processes). An opponent process is a closed process that does not contain assertions. Synonyms: opponent, attacker, intruder, adversary Secrecy Assertions Assertions. A ::= secret(M) (M is secret) | For example: A -> B : s PA == new s; (secret(s) | out net s; stop) PB == inp net x; stop P == !PA | !PB The secrecy assertion in this example is obviously violated. Safe for Secrecy A process Q is called an error state iff it has the following form: Q = new n1,,nj; (secret(M) | out c M; Q | Q) where c n1,,nj. (nb: new n1, , nj ;P is short for new n1; ; new nj ;P) Recall that free names represent public data. So an error state is when a secret is sent to a public channel. A closed process P is safe for secrecy iff P ->* Q implies that Q is not an error state. Example Rem: error state Q = new n1,,nj; (secret(M) | out c M; Q | Q) where c n1,,nj. Recall the example A -> B : s PA == new s; (secret(s) | out net s; stop) PB == inp net x; stop P == !PA | !PB This protocol is not safe for secrecy: P PA | P new s; (secret(s) | out net s; stop | P) Robust Safe for Secrecy Is the notion of safe for secrecy enough for our purposes? why not? It does not consider the intruder. Definition (Robust Safety for Secrecy). A closed process P is robustly safe for secrecy iff for all opponent processes O the parallel composition P | O is safe for secrecy. Example A -> B : ({s, p}k, {p, s}k ) B -> A : (p, p) The formalization in SPI PA == new s, s, p, p; (secret(s) | secret(s) | out net ({(s,p)}k,{(p,s)}k); inp net x; if x = (p,p) then stop) PB ==inp net pair; split pair is (x,y), decrypt x is {z}k; split z is (s,p); decrypt y is {w}k; split w is (p,s); out net (p,p); stop P ==new k ;(!PA | !PB) Example (2) A -> B : ({s, p}k, {p, s}k ) B -> A : (p, p) The attack A -> O : ({s, p}k, {p', s'}k ) // opponent intercepts O -> B : ({p', s'}k, {s, p}k ) // opponent swaps ciphers B -> A : (s', s) // B publishes secrets the opponent (has to publish the secrets) O == inp net pair ; split pair is (x,y) ; out net (y,x); inp net pair; split pair is (s, s) ; (out net s ; | out net s ;) demonstrating the flaw P | O ->* new k, s, p, p, s; secret(s) | secret(s) | out net s; | out net s; | External vs Internal Threats Internal threats are modeled by publishing the secrets of one of the agents. This agent could, for instance, represent: a compromised user that cooperates with external attackers a compromised machine that has been captured by external attackers We call this agent the spy. Of course, honest agents do not know who the spy is. We could also model several spies within the same system, but theoretical results show that this does not make a difference for the security properties we care about: Attacks launched by multiple spies can already be launched by a single spy. Modelling Internal Threats A -> B : {s}k We model a system with two agents and a spy: Sender(a, b, k) = new s; out net {s}k ; Receiver(a, b, k) = inp net x; decrypt x is {y}k ; secret(y) Compromised(k, k') = out net k; | out net k'; P = new K_A_B; new K_A_Spy ; new K_Spy_B; Compromised(K_A_Spy,K_Spy_B) !Sender(A,B,KA_B) | !Sender(A, Spy,K_A_Spy ) | !Receiver(A,B,KA_B) | !Receiver(Spy,B,K_Spy_B) Bs secrecy expectation is obviously violated in Receiver(Spy,B,K_Spy_B). But a reasonable B would not expect the input received by this agent to remain secret (he is talking to the intruder!). We are more interested in finding out if Receiver(A,B,KA,B) actually receives a secret, but to this end we need to insert the secrecy assertion into Receiver(A,B,KA,B). But how? Conditional Assertions Assertions. A ::= | if M N then A (A provided M N) | We add a logical reduction rule to the operational semantics: if M N then A -> A provided M N This rule is logical in that it only applies to assertions. The other rules of the operational semantics are not affected Modelling Internal Threats A -> B : {s}k Now we can be more precise on Bs expectations wrt the secrecy of the messages: Sender(a, b, k) = new s; out net {s}k ; Receiver(a, b, k) = inp net x; decrypt x is {y}k ; if a Spy then secret(y) Compromised(k, k') = out net k; | out net k'; Proving Robust Safety But how do we prove robust safety? To prove robust safety we have to consider all possible attackers that our model permits. Proving robust safety naively is tedious. Type systems for secrecy. These formalize a few basic rules that are easy to check. Adherence to the typing rules guarantees robust safety in an external threat model. Basic Types Types. T,U,V ::= Public | Secret | Un |... Public. Data that may be published. Secret. Data that must be kept secret. Un. Data received from untrusted channels. Untrusted channels (net) have type Un Idea: subtyping to control data flow Subtyping between basic types: Public