Hello World in HLPSL. Turning ASCII protocol specifications into HLPSL

Transcription

1 Hello World in HLPSL Turning ASCII protocol specifications into HLPSL

2 Modeling with HLPSL HLPSL is a higher-level protocol specification language we can transform ASCII protocol specifications into HLPSL programs HLPSL is suitable language for modeling industrial protocols with control flow, exceptions, dynamic key chains etc.

3 Objectives Understand or revise informal ASCII notation of security protocols Get acquainted with how such ASCII specifications can be written in HLPSL Appreciate standard coding patterns in HLPSL Learn how HLPSL programs can be analyzed

4 A protocol in ASCII 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) Agent A wants to generate fresh key K1 and share it with agent B,, is concatenation Na is fresh nonce generated by A Nb fresh nonce generated by B Hash is a hash function that A and B share

5 What is a nonce? 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) Nonce is a random piece of data (bit string) Its value should be (probabilistically) impossible to predict prior to its creation So each nonce, when seen in a protocol run, provides a causal link to when and where it was created

6 Intuition of protocol 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) A sends B encryption of Na (which only A knew initially), and only A and B know encryption key K B sends A encryption of Nb (which only B knew initially) fresh key is hash of concatenation of Na and Nb, both A and B can compute this fresh key K1 Then A sends acknowledgement receipt to B, an encryption of Nb with the fresh key

7 Implicit vs Explicit Notation 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) explicit: who sends what to whom, e.g. A sends Na encrypted with key K to B implicit: A generates Na, B generates Nb, A and B share a session key K and hash function Hash, A and B can compute K1 formal analysis needs to make this explicit

8 Agents, sessions, roles Agents take on particular roles in protocols E.g. initiator, responder, trusted authority Agents may have more than one role And protocols may run in multiple versions (called sessions here) in parallel Need ability to model instantiations of sessions and of their protocol roles

9 Role declarations in HLPSL Agents A, B, etc. from ASCII specs turn into named roles in HLPSL, e.g. alice for A In a session, alice may be instantiated with A, B, an attacker or any other agent Here is a code template for agent roles: role r(...) played_by Agt def= local... init... transition... end role % role r enacted by agent Agt % declare local variables % initialize variables if needed % define legal behavior of role r

10 Role alice in HLPSL played_by A: lets A play alice in role body (...): declares typed input parameters local: declares local variables init: local variables may be initialized here transition: declares state transitions of role role alice(...) played_by A def= local... init... transition... end role

11 Input header for alice agents A (for alice), B (for responder) symmetric key K hash function Hash communication channels SND and RCV so alice has a send and a receive channel role alice( A,B : agent, K : symmetric_key, Hash : hash_func, SND,RCV : channel(dy))

12 More on input headers note that input parameters are typed parameters may be shared across roles in headers, e.g. to express a shared key the (dy) for channels is redundant but needs to be stated, HLPSL anticipated different channel types but only has one role alice( A,B : agent, K : symmetric_key, Hash : hash_func, SND,RCV : channel(dy))

13 Local variables for alice 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) declare local all variables that are generated or received, and are not in header: local State : nat, % remembers local protocol state Na,Nb : text, % the two nonces generated K1 : message % the key to be generated % explain later different types for keys and nonces

14 Exercise 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) speculate why code declares nonces to be of type text and not, say, of type nonce speculate why code declares key to be of type message and not, say, of type key Na,Nb : text, % the two nonces generated K1 : message % the key to be generated

15 Initialize variables for 1. A --> B: {Na}_K 2. B --> A: {Nb}_K alice 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) do not initialize variables that will get frehly generated values in the protocol run do not initialize variables from the header so here only initialize state to 0: init State := 0

16 Syntax for transitions technicality: transitions, even first one, need receiving event; use start as initial event syntactic form of transitions is precondition = > postcondition variables may be primed (X ) or unprimed (X), will elaborate on this further below use /\ to denote conjunction of conditions, := for assignment, new() for fresh generation of values for variables

17 First transition for alice 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) if in state 0 and start received, state will be 2, generate fresh Na, send its encryption do not initialize variables from the header the 1. below is name of transition (has no computational significance) 1. State = 0 /\ RCV(start) = > State':= 2 /\ Na' := new() /\ SND({Na'}_K)

18 Primes in transition 1. State = 0 /\ RCV(start) = > State':= 2 /\ Na' := new() /\ SND({Na'}_K) no primes in first line, State is current one, and start event behaves like a constant Na primed in post-condition as it is freshly generated there State is primed in post-condition as this defines its value in next state K is not primed anywhere, as it is the key shared through the input header

19 Second alice transition 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) if in state 2 and a nonce encrypted with K is received, update state to 4, generate fresh key as hash of Na and Nb, and send receipt of Nb encrypted with fresh key will discuss witness specification later 2. State = 2 /\ RCV({Nb'}_K) = > State':= 4 /\ K1' := Hash(Na.Nb') /\ SND({Nb'}_K1') /\ witness(a,b,bob_alice_nb,nb')

20 Primes in transition Nb is primed as it is received on RCV Na is not primed as it needs to have the same value as in state 0! K1 is primed as it is freshly generated (from the unprimed Na and the primed Nb) K1 and Nb are also primed when sent on SND A, B, K not primed: input parameters 2. State = 2 /\ RCV({Nb'}_K) = > State':= 4 /\ K1' := Hash(Na.Nb') /\ SND({Nb'}_K1') /\ witness(a,b,bob_alice_nb,nb')

21 Complete alice role role alice( A,B : agent, K : symmetric_key, Hash : hash_func, SND,RCV : channel(dy)) played_by A def= % use. below for concatenation local State : nat, Na,Nb : text, K1 : message init State := 0 transition 1. State = 0 /\ RCV(start) = > State':= 2 /\ Na' := new() /\ SND({Na'}_K) 2. State = 2 /\ RCV({Nb'}_K) = > State':= 4 /\ K1' := Hash(Na.Nb') /\ SND({Nb'}_K1') /\ witness(a,b,bob_alice_nb,nb') end role

22 Complete bob role role bob( A,B : agent, K : symmetric_key, Hash : hash_func, SND,RCV : channel(dy)) % same input as for alice played_by B def= % but B plays responder role local State : nat, Nb,Na : text, K1 : message % same as alice init State := 1 % values local to role, but avoiding reuse % of 0 means attack traces easier to read transition 1. State = 1 /\ RCV({Na'}_K) = > State':= 3 /\ Nb' := new() /\ SND({Nb'}_K) /\ K1':= Hash(Na'.Nb') /\ secret(k1',k1,{a,b}) 2. State = 3 /\ RCV({Nb}_K1) = > State':= 5 /\ request(b,a,bob_alice_nb,nb) end role

23 First transition for bob 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) if in state 1 and encrypted nonce received, state will be 3, generate fresh Nb, send its encryption, generate fresh key as hash of two nonces discuss later secret condition 1. State = 1 /\ RCV({Na'}_K) = > State':= 3 /\ Nb' := new() /\ SND({Nb'}_K) /\ K1':= Hash(Na'.Nb') /\ secret(k1',k1,{a,b})

24 Primes in transition 1. State = 1 /\ RCV({Na'}_K) = > State':= 3 /\ Nb' := new() /\ SND({Nb'}_K) /\ K1':= Hash(Na'.Nb') /\ secret(k1',k1,{a,b}) Na primed as received on RCV Nb generated here so primed, also when sent fresh key K1 primed as generated here, also primed in secret specification k1 in secret is a constant name for this condition, constants are unprimed

25 Second bob transition 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) if in state 3 and own (unprimed!) nonce encrypted with fresh key received, state will be 5 (successful run) discuss later request condition -- corresponds to witness in role alice 2. State = 3 /\ RCV({Nb}_K1) = > State':= 5 /\ request(b,a,bob_alice_nb,nb)

26 Composition of roles 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) Roles define behavior of protocol participants, here A and B and an attacker Sessions define how these roles interact in the protocol let s see next how this works for the protocol above

27 alice and bob in session role session( A,B : agent, K : symmetric_key, Hash : hash_func) % input for entire session def= % four channels, two for each agent, local to session local SA, SB, RA, RB : channel (dy) % A, B, K, and Hash shared across roles % communication channels private to each role composition % /\ means parallel composition here alice(a,b,k,hash,sa,ra) /\ bob (A,B,K,Hash,SB,RB) end role 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb)

28 composition details 1. A --> B: {Na}_K 2. B --> A: {Nb}_K 3. A --> B: {Nb}_K1, where K1=Hash(Na, Nb) A plays alice and B plays bob both roles agree on this, and make use of shared key K and hash function Hash each role has private send and receive channels composition alice(a,b,k,hash,sa,ra) /\ bob (A,B,K,Hash,SB,RB)

29 sessions in environment sessions define how agent parameters interact in a protocol a protocol instance may involve more than one session run in parallel and these sessions may be instantiated with real agents, key, etc. the environment role is used to specify this

30 environment role role environment() def= % declares session scenario const bob_alice_nb, k1 : protocol_id, % names for analyses kab,kai,kib : symmetric_key, % concrete keys a,b : agent, % concrete agents h : hash_func % concrete hash function % specify what the attacker (aka. intruder) knows initially intruder_knowledge = {a,b,h,kai,kib} % specify protocol scenario: how many sessions run in parallel % and in which instantiations composition session(a,b,kab,h) % normal session /\ session(a,i,kai,h) % intruder i impersonates b /\ session(i,b,kib,h) % intruder i impersonates a end role

31 constants in environment, const lists all concrete variables that make up the scenario names for authentication and secrecy properties are declared here, of type protocol_id (for tool internal reasons) const bob_alice_nb, k1 : protocol_id, % names for analyses kab,kai,kib : symmetric_key, % concrete keys a,b : agent, % concrete agents h : hash_func % concrete hash function

32 what intruder knows intruder models protocol attacker HLPSL has reserved variable i for intruder, who receives all network traffic in environment, we declare what intruder knows before protocol runs in environment here, i knows identities of the two agents, the hash function, and keys it shares with a and b in the second (resp.) third session % specify what the attacker knows initially intruder_knowledge = {a,b,h,kai,kib}

33 analysis goals Can check models of protocols for executability (consistency), this is useful But also want to verify declared secrecy and authentication properties Directives for such analyses are grouped in a goal block, for our example this is: goal secrecy_of k1 authentication_on bob_alice_nb end goal

34 secrecy goal in detail goal % analyze this secrecy_of k1 authentication_on bob_alice_nb end goal k1 is name for secrecy property declared in role bob: secret(k1',k1,{a,b}) says that fresh key K1 is known only to agents A and B in this protocol run declared right where key is first created (in role bob) and not in role alice, where it is received!

35 authentication goal witness(a,b,bob_alice_nb,nb') % in role alice request(b,a,bob_alice_nb,nb) % in role bob bob_alice_nb is name for authentication property declared in roles alice and bob request: B accepts value Nb, relies on existence of A and A s agreeing to value Nb Nb should be fresh, not replayed A s existence bound to protocol id for bob_alice_nb

36 authentication goal (2) witness(a,b,bob_alice_nb,nb') % in role alice request(b,a,bob_alice_nb,nb) % in role bob witness statement complements request statement it stipulates two things: A wants to be a peer with agent B in the protocol run with id bob_alice_nb and A wants to agree with B on the value Nb, for the purpose of authentication

37 Running the analyses.hlpsl files end and with a runner environment() all goals are tried but only first attack (so for one goal only) reported if applicable can use different analyses back-ends (more on that later) can, and have to, check executability of.hlpsl model as well (more on that later)

38 Analysis results for our HLPSL model, model checker OMFC found no attacks protocol may be unsafe in other session composition scenarios (like testing) will discuss back-end for unbounded sessions later (like proofs) % avispa ex1.hlpsl % OFMC % Version of 2006/02/13 SUMMARY SAFE DETAILS BOUNDED_NUMBER_OF_SESSIONS...

39 Structure of models role r1(...)... end role role r2(...)... end role... role rn(...)... end role % define participating roles role session(...) % define role interaction in protocol local... % private channels composition r1(...) /\... /\ rn(...) end role role environment() % define execution scenario of protocol def= const... % actual agents, keys, etc. intruder_knowledge = {... } % state what the attacker knows initially composition session(...) /\... /\ session(...) end role % several sessions in parallel goal secrecy_of... % what secrets should hold authentication_on % what correspondences should hold end goal environment() % run the model against all goals

40 Summary looked at a HLPSL model in detail learned general structure of.hlpsl specifications discussed how to encode behavior and (shared) knowledge in HLPSL saw how one can analyze such models for secrecy and authentication