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 interceptsI -> B : ({p', s'}k , {s, p}k ) // intruder swaps ciphersB -> 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}kas4. B -> S : {A, {s,N}kas}kbs5. S -> B : {s,N}kbs

• Now B expects that s is a secret that he shares with A• Even if A is honest, B’s 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}kas4. B -> S : {A, {s,N}kas}kbs5. S -> B : {s,N}kbs

• Fix: include agent identity– S should include A’s 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 exampleA -> 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 ThreatsA -> 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)

– B’s 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 ThreatsA -> B : {s}k

• Now we can be more precise on B’s 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 <: Un– Secret </: Un //meaning: is not a subtype of Un

• Meaning– T <: U “data of type T may flow into channels of type U”– T </: U “data of type T must not flow into channels of type U”

• Example– Assume net : Un.– new p : Public; out net p; ok because Public <: Un– new s : Secret; out net s; not ok because Secret </: Un

Type Environments

• Type environments.– a partial function from the set of variables and names to the

set of types.– Meta-variable E ranges over type environments.

• The purpose of type environments.– E records types for free variables and names.

• The update operation for type environments.– E, x : T == (E − {(x, E(x))} ) U {(x, T)}– E, n : T == (E − {(n, E(n))} ) U {(n, T)}

Typing Judgments

• The type system consists of three relations, which are called typing judgments.

• Subtyping.– T <: U

• Typing Judgment for Messages.– E ⱶ M : T– Read as: “In type environment E, message M has type T.”

• Typing Judgment for Processes.– E ⱶ P : ok – Read as: “In type environment E, process P is well-typed.”

Typing Rules

• Typing judgments are defined by typing rules.– If premise_1 and premise_2 and . . . and premise_n,– then consequence.

• For better readability, we write typing rules in schematic notation:

premise_1 premise_2 · · · premise_nconsequence

• The typing judgments are defined as the least relations that satisfy all typing rules.

Typing Axioms: I/O

E ⱶ L : Un E ⱶ M : Un E ⱶ P : okE ⱶ out L M;P : ok

E ⱶ L : Un E, x : Un ⱶ P : okE ⱶ inp L x;P : ok

• “If L has type Un and M has type Un and P is ok, then out L M;P is ok.”

• An algorithmic reading:– To show that out L M;P : ok,– show that L : Un and M : Un and P : ok.

Typing Axioms: I/O (2)

E ⱶ L : Un E ⱶ M : Un E ⱶ P : okE ⱶ out L M;P : ok

E ⱶ L : Un E, x : Un ⱶ P : okE ⱶ inp L x;P : ok

• Since the only channel we are going to use is the network (which has type Un), these are the only axioms we need for this.

Typing Rule: New

• From now on, generated names must get a type– new n : T ; P– This is like declaring types of variables in typed programming

languages.– Given these type annotations, well-typedness can efficiently be

checked by an automatic typechecker.– Moreover, these type annotations express the intent of the

protocol designer and are, therefore, useful documentation• The rule:

E, n : T ⱶ P : okE ⱶ new n : T;P : ok

Variables, Names, Inactivity

• Axioms for variables and names

E, x : T ⱶ x : T E, n : T ⱶ n : T

• Axiom for inactivity

E ⱶ stop : ok

Subtyping Rules, Subsumption Rule

• Reflexivity and transitivity.T <: U U <: VT <: T T <: V

• Subtyping rule for the public type.

Public <: Un• Subsumption rule.

E ⱶ M : T T <: UE ⱶ M : U

Example

• net : Un ⱶ new p : Public; out net p; stop :ok• This is derivable, so produce the derivation.

Example (worked out)

=========== E ⱶ p:Public Public <:Un

========= ========================== ==========Eⱶ net: Un E ⱶ p:Un E ⱶ stop:ok==========================================================

E ⱶ out net p; stop :ok====================================net : Un ⱶ new p : Public; out net p; stop :ok

E :== net : Un, p : Public

FINISHED

Another Example

net : Un ⱶ new s : Secret; out net s; stop• This judgment is not derivable.

• Exercise: Try to construct a proof tree for that. • You will end up with a proof goal of the form:

net : Un, s : Secret ⱶ s : Un• There are no rules to derive this goal.

Types for symmetric keys

• A type for symmetric keys.T ::= · · · | SymKey(T) | · · ·

• Type of symmetric keys for encrypting data of type T.

• Subtyping rule for symmetric keys.SymKey(T) <: Secret

– Note that SymKey(T) is not a subtype of Un (by absence of a subtyping rule that justifies this).

– Thus, the type system prohibits to send symmetric keys onto untrusted channels.

Typing Rules for Symmetric Crypto

• Typing rules for symmetric crypto.

E ⱶ K : SymKey(T) E ⱶ M : TE ⱶ {M}K : Un

E ⱶ M : Un E ⱶ K : SymKey(T) E, x : T ⱶ P : okE ⱶ decrypt M is {x}K ;P : ok

• the rule for encryption allows us to send ciphertexts onto untrusted channels (ciphertexts have type Un).

Tuples types

T ::= · · · | (T1, . . . , Tn) | · · ·• Type of (M1, . . . ,Mn) where Mi : Ti for all i in 1 . . . n.• Subtyping rules for tuples types.

(Un, . . . , Un) <: Un Un <: (Un, . . . , Un)

T1 <: U1 · · · Tn <: Un(T1, . . . , Tn) <: (U1, . . . ,Un)

• The first two rules enable us to communicate tuples of public data over untrusted channels.

Typing rules for tuples

E ⱶ M1 : T1 · · · E ⱶ Mn : TnE ⱶ (M1, . . . ,Mn) : (T1, . . . , Tn)

E ⱶ M : (T1, . . . , Tn) E, x1 : T1, . . . , xn : Tn ⱶ P : okE ⱶ split M is (x1, . . . , xn);P : ok

Typing Rules for Conditionals

E ⱶ M : T E ⱶ N : U E ⱶ P : okE ⱶ if M = N then P : ok

E ⱶ M : T E ⱶ n : U T,U do not have a common subtypeE ⱶ if M = n then P : ok

• If T,U do not have a common subtype, then the condition is always going to fail, so we can allow P to be ok

Additional Process Rules

E ⱶ P : ok E ⱶ Q : okE ⱶ P | Q : ok

E ⱶ P : okE ⱶ !P : ok

E ⱶ M : SecretE ⱶ secret(M) : ok

Running ExampleA -> B : ({s, p}k , {s’, p’}k )B -> A : (p, p’)

• The formalization in SPI, typed– PA == new s: Secret, s’:Secret, p:Public, p’ :Public;

(secret(s) | secret(s’) | out net ({(s,p)}k,{(s’,p’)}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 (s’,p’); out net (p,p’); stop

– P == new k:SymKey(Secret, Public);(!PA | !PB)

• This protocol is well-typed, i.e., net : Un ⱶ P : ok– This can easily be verified by a typechecker.

Where Does Typing of the Flawed Protocol Fail?

A -> B : ({s, p}k , {p’, s’}k )B -> A : (p, p’)

• An attempt to assign a type to the key k.– For the first ciphertext, k needs type

• SymKey(Secret, Public).

– For the second ciphertext, k needs type • SymKey(Public, Secret).

• But these two types are incompatible. This cannot be resolved.

Type Soundness

• P is well-typed iff n1:Un,…,ni: Un ⱶ P : ok – where n1,..,ni are P’s free names.

• Theorem (Type Soundness).– Well-typed processes are robustly safe for secrecy.

• A method for verifying robust safety of protocol P:– Annotate P’s newly generated names with types.– Check if n1,..,ni : Un ⱶ P : ok, where n1,..,ni are P’s free names.

• The running example from two slides ago is well-typed.

Proving Type Soundness

• We will now sketch how to prove the type soundness theorem.

• If you are interested in proof details, you can find a type soundness proof for a similar type system in [AB'1].

Proving type soundness (1)Proving Safety

• The heart of the soundness proof is:– Theorem (Type Preservation).

• If E ⱶ P : ok and P ->* Q, then E ⱶ Q : ok.

– Lemma (Error States are Ill-typed).• If n1,…,ni : Un ⱶ Q : ok, then Q is not an error state.

• Safety of well-typed processes now easily follows:• Theorem (Safety)– Well-typed processes are safe for secrecy.

• Proof. Suppose P is well-typed and P ! Q. Then Q is well-typed, by the type preservation theorem. Then Q is not an error state, by the previous lemma.

Proving type soundness (2)Proving Robust Safety

• But how do we prove robust safety?• i.e. in presence of the intruder?– we type the intruder!

• Definition (Un-typed Processes).– P is called Un-typed iff every type annotation in P is Un.

• Lemma (Opponent Typability).– Un-typed opponent processes are well-typed.

Proving type soundness (3)Typing the Intruder

• For opponent typability, we need extra rules for when the opponent generates messages or decrypts them with keys he possesses (which are not secret)

E ⱶ M : Un E ⱶ K : UnE ⱶ {M}K : Un

E ⱶ M : Un E ⱶ K : Un E, x : Un ⱶ P : okE ⱶ decrypt M is {x}K ;P : ok

• After adding these rules, proving opponent typability is done by structural induction.

Proving type soundness (3)Error states are not Ill-typed

• Lemma (Error States are Ill-typed).• If n : Un ⱶ Q : ok, then Q is not an error state.

– (boldface = tuples). Proof. By contradiction. Suppose n : Un ⱶ Q : ok and Q is an error state. By definition of error states, Q has the following form:

– Q = new m : T; (secret(M) | out c M;Q’ | Q’’) , where c m– By inspecting the typing rules that can possibly justify the judgment n :

Un ⱶ Q : ok, we see that the following two judgments must be derivable: – n : Un, m : T ⱶ M : Secret and n : Un, m : T ⱶ M : Un. – But this is impossible, by the following– Lemma: “There exist no E, M such that both E ⱶ M : Secret and E ⱶ M :

Un.”

Proving type soundness (4)Type Preservation

• Theorem (Type Preservation).– If E ⱶ P : ok and P ->* Q, then E ⱶ Q : ok.– Proof strategy. We need to show that each of the step reduction rules

preserves typings. As a sample case, consider the I/O rule:• out c M;P | inp c x;Q -> {M/x}Q

– Suppose E ⱶ out c M;P | inp c x;Q : ok. By inspecting the typing rules that can possibly justify this judgment, we see that all of the following must be derivable:• E ⱶ M : Un E ⱶ P : ok E, x : Un ⱶ Q : ok

– By the substitutivity lemma below, E ⱶ {M/x}Q : ok. follows– Lemma (Substitutivity)

• If E ⱶ M : T and E, x : T ⱶ Q : ok, then E ⱶ {M/x}Q : ok.

Proving Type Soundness

– “Error States are Ill-typed”– + Type Preservation (aka Subject Reduction)– + Opponent Typability– => Type Soundness

• This is almost the standard structure for type soundness proofs.

• The extra twist is opponent typability, which is needed to obtain robust safety in the presence of attackers.

Tagging

• A prudent engineering practice for security protocols.– It prevents type flaw attacks.– Senders attach a tag to a message, which identifies the format of

the tagged message.– Receivers check if received messages carry the expected tags.– Synonyms: tags, type tags, dynamic types

• For instance:• A -> B : ({secpub, s, p}k , {pubsec, p', s'}k )• B -> A : (p, p')

– secpub and pubsec are tags that B checks on receipt.– Is this protocol is robustly safe? Yes. We now show why.

Tagging: Syntax

• We could model tagging by simply including additional tag elements in tuples, like in the previous example.

• However, for the type system it is convenient to introduce a syntax constructor for tagging.

• Tagging.– M ::= · · · | L(M) | · · ·– Message M tagged by L.

• Untagging.– P ::= · · · | untag M is L(x); P | · · ·– Match the tag L and bind the tagged message to x.

Tagging: Operational Semantics

• Operational semantics for untagging.untag L(M) is L(x); P -> {M/x}P

• Note that this rule forces you to match the tag in order to remove it.

• The operational semantics of untagging is very similar to the operational semantics of decryption.

• The important difference between symmetric keys and tags is that tags are public.

Types for Tags

• Tag types.T ::= · · · | Tag(T) | Tagged | · · ·

– Tag(T): Type of tags for messages of type T.– Tagged: Type of tagged messages.

• Subtyping for tag types.Tag(T) <: Un

– The subtyping rule models that tags are public.

Typing rules

E ⱶ L : Tag(T) E ⱶ M : TE ⱶ L(M) : Tagged

E ⱶ M : Tagged E ⱶ L : Tag(T) E, x : T ⱶ P : okE ⱶ untag M is L(x); P : ok

• We can extend the type soundness theorem to the extended language with tagging. (To this end, we have to add two more typing rules for opponent typability.)

representing a tagged message

meaning: “this is

tagged the right way”

Our Example• A -> B : ({secpub(s, p)}k , {pubsec(p', s')}k )• B -> A : (p, p')

• As a type-annotated formal narration:– PA =. . . out net ( {secpub(s, p)}k , {pubsec(p', s')}k ) . . .– PB= inp net pair ; split pair is (x, y); decrypt x is {z}k ;

untag z is secpub(z'); split z' is (s, p);decrypt y is {z}k ;untag z is pubsec(z'); split z' is (p', s'); out net (p, p')

– P = new k : SymKey(Tagged); new secpub : Tag(Secret, Public);new pubsec : Tag(Public, Secret);(!out net (secpub, pubsec) | !PA | !PB)

Here it is where we gain something by using tags: the key k now has type SymKey(Tagged), which is simpler than SymKey(Public,Secret) and can be used for both messages

Varia• Next time

– Secrecy types for asymmetric cryptography.– The automatic protocol verifier ProVerif.

• References– Our secrecy assertions are very similar to secrecy claims in the CSP

model, see Chapter 3.2 in [RS01].– The example protocol that is vulnerable to internal attack is a variant

of Woo-Lam’s authentication protocol . The attack is taken from the Clark/Jacob survey [CJ97], Section 6.3.10.

– The secrecy type system is very similar to the one by Abadi/Blanchet [AB01].

– Gordon/Jeffrey’s article [GJ05] contains an extended secrecy type system that deals with internal attackers.

Symbols

• structural congruence• • ⱶ