university of twente the netherlands centre for telematics and information technology design,...

University of TwenteThe Netherlands

Centre forTelematics andInformationTechnology

Design, Analysis and Verification of Design, Analysis and Verification of Security ProtocolsSecurity Protocols

Ricardo [email protected]

Slides by Sandro Etalle and Ricardo Corin



Day 2Day 2

Using CoProVe



Preliminaries: Prolog’s notationPreliminaries: Prolog’s notation variables: begin with uppercase or with _

• Na,Nb,A,B, _a are variables• a,na,nb,b are non-variable terms

variable are terms Complex terms can be built using predicate

(function) symbols:• pk(b) is a non-variable term (pk is a function symbol)• pk(B) • Nb*pk(B) is the same as *(Nb,pk(B)): * is an infix-

operator.• send(Nb*pk(B))



Protocol Verification RoadmapProtocol Verification Roadmap1. Pick a protocol and identify different roles2. Specify protocol roles’ templates3. Prepare a session using 24. Add a security check to the session5. Verify it6. If attack, (try to) patch the protocol and go

back to 17. If no attack, go back to 3



The whole process for The whole process for Needham-Schroeder Needham-Schroeder

A->B : [A,Na]*pk(B)B->A : [Na,Nb]*pk(A)A->B : [Nb]*pk(B)

Notation• [t1,t2]: pairing (these are lists in PROLOG)• msg*k: asymmetric encryption

Conventions• Na, Nb: nonces• A, B: Agents (Alice and Bob)• pk(A): public key of A



Step 1: identify Roles Step 1: identify Roles

A->B : [A,Na]*pk(B)

B->A : [Na,Nb]*pk(A)

A->B : [Nb]*pk(B)

Here we have 2 ROLES• one INITIATOR (A)• one RESPONDER (B)

A role is specified as a sequence of EVENTS



EventsEvents events are actions, two kind:

• send(t)• recv(t)• t is a term (a message)

the crucial part of a role is a list of his actions:

[recv([A,B]),

send([A,Na]*pk(B)),

recv([Na,Nb]*pk(A)),

send(Nb*pk(B))]

[t1,…,tn]: is a list in Prolog



Step 2: Specifying a RoleStep 2: Specifying a Role Fixed (abstract) notation:

name(Variables) = [Actions].

E.g.initiator(A,B,Na,Nb) = [ send([A,Na]*pk(B)),

recv([Na,Nb]*pk(A)),

send(Nb*pk(B))].

The tool notation is different! • compiler notation vs abstract notation (this one)



The ResponderThe Responder How does the responder look like? Just exchange “send” and “recv”

responder(A,B,Na,Nb) = [ recv([A,Na]*pk(B)),

send([Na,Nb]*pk(A)), recv(Nb*pk(B))]).

Any name is good (not only “responder”) Notice ALL THESE VARIABLES!

• names & nonces are not fixed• roles are parametric



Protocol Verification RoadmapProtocol Verification Roadmap1. Pick a protocol and identify different roles2. Specify protocol roles’ templates3. Prepare a session using 24. Add a security check to the session5. Verify it6. If attack, (try to) patch the protocol and go

back to 17. If no attack, go back to 3



Step 3: System ScenariosStep 3: System Scenarios Protocol roles provide ‘templates’ Set up a session=finite scenario for verification

• choose roles participating in the session• instantiate the variables of the roles

Instantiation: used for:• Say who is playing which role• Introduce fresh nonces



System Scenarios cont’dSystem Scenarios cont’d

A->B : [A,Na]*pk(B)

B->A : [Na,Nb]*pk(A)

A->B : [Nb]*pk(B)

A possible scenario:• s1 = {initiator(a,B,na,Nb), responder(A,b,Na,nb)}• one INITIATOR A played by agent a• one RESPONDER B played by agent b

Remember: Uppercase is Var, Lowercase is constant



Variables & non-variablesVariables & non-variables

Consider the scenario• {initiator(a,B,na,Nb), responder(A,b,Na,nb)}

Variables indicate parameters that may assume any value (their value is not known at the start).• For instance, the initiator here does not know in

advance the name of the responder.

Fresh nonces = new terms (ground terms that don’t occur elsewhere ).



More System Scenarios for NSMore System Scenarios for NS

• {initiator(a,b,na,nb), responder(a,b,na,nb)}– the ‘honest’ scenario (but unrealistic)

• {initiator(a,B,na,Nb), responder(A,b,Na,nb)}– may not communicate with each other

• {initiator(a,b,na,nb), responder(A,B,Na,Nb)}– a may also play the responder role

• {initiator(a,b,na,nb), responder(c,d,nc,nd)}– no communication!



Protocol Verification RoadmapProtocol Verification Roadmap1. Pick a protocol and identify different roles

2. Specify protocol roles’ templates

3. Prepare a session using 2

4. Add a security check to the session

5. Verify it

6. If attack, patch the protocol and go to 1

7. If no attack, go to 3

Before moving on, let’s see a bit of theory...



The network modelThe network model

Network/Intruder

ScenarioAgent

Role RoleRole

RoleRole

•Network - intruder: Dolev-Yao.

send(t)recv(t)



Constraint StoreConstraint Store knowledge (K)

• the intruder’s knowledge: the set of intercepted messages

constraint store:

{msg_1:K_1, …, msg_n:K_n}

• msg_1, … , msg_n: messages (terms)• K_1, …, K_n: knowledges (set of messages)

Is satisfiable: each msg_i is generable using K_i.



Overview of the Verification Overview of the Verification AlgorithmAlgorithm

A step of the verification algorithm:• choose an event e from a role of S• Two cases:

• e = send(t)– t is added to the intruder’s knowledge

• e = recv(t)– add constraint t:K to the constraint store– if constraint store is solvable, proceed– otherwise, stop



The Origination assumptionThe Origination assumption Roles are ‘parametric’, i.e. may contain variables

We have to avoid sending out uninstantiated variables (only the intruder may do so).

We must satisfy the origination assumption:• Any variable should appear for the first time in a recv

event• So, we add events of the form recv(X), where appropriate



What’s a security check?What’s a security check?1. Pick a protocol and identify different roles

2. Specify protocol roles’ templates

3. Prepare a session using 2

4. Add a security check to the session

We consider two security goals:

Confidentiality and Authentication



Finding Secrecy flawsFinding Secrecy flaws What is a secrecy flaw? To check if na remains secret, one just has

to add to the scenario the singleton role [recv(na)]

na remains secret <=> the intruder cannot output it!

in practice we define a special role• secrecy(X) = [recv(X)].



Finding Authentication FlawsFinding Authentication Flaws More complex than checking secrecy. What is an authentication flaw?

• Various definitions.• Basically: an input event recv(t) without

corresponding preceding output event send(t).• Can be checked by e.g., running the responder

without a corresponding initiator role.• We are working on it.



From abstract notation to From abstract notation to implementation notationimplementation notation

Abstract notationrole_name(Var1,…,VarN) = [Events].

Concrete notationrole_name(Var1,...,VarN,[Events]).

Abstract Notation initiator(A,B,Na,Nb) = [ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Implementation Notationinitiator(A,B,Na,Nb,[ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).



The full specification of NS (Step 2)The full specification of NS (Step 2)

% Initiator role initiator(A,B,Na,Nb,[ send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Responder roleresponder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B)) ]).

% Standard secrecy-checking role secrecy(X,[recv(X)]).



The notation of Scenarios (Step 3+4)The notation of Scenarios (Step 3+4)scenario([

[name_1,Var_1],

...,

[name_n,Var_n]

]

) :-

role_1(...,Var_1),

...

role_n(...,Var_n).



For InstanceFor Instance

What do we achieve with this scenario?

scenario([ [alice,Init1], [bob,Resp1], [sec,Secr1] ] ) :-

initiator(a,B,na,Nb,Init1), responder(a,b,Na,nb,Resp1), secrecy(nb, Secr1).



Last Details (1):Last Details (1):Initial intruder knowledge & Initial intruder knowledge &

has_to_finishhas_to_finish

% Set up the initial intruder knowledge

initial_intruder_knowledge([a,b,e]).

% specify which roles we want to force to% finish (only sec in this example)

has_to_finish([sec]).



Specification of NS with O.A.Specification of NS with O.A.

% Initiator role initiator(A,B,Na,Nb,[ recv([A,B]), send([A,Na]*pk(B)), recv([Na,Nb]*pk(A)), send(Nb*pk(B)) ]).

% Responder roleresponder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,Nb]*pk(A)), recv(Nb*pk(B)) ]).

scenario([[alice,Init1], [bob,Resp1], [sec,Secr1]]) :- initiator(a,B,na,Nb,Init1), responder(a,b,Na,nb,Resp1), secrecy(nb, Secr1).



Last steps before execution…Last steps before execution… Decide whether we want Prolog stop at first

solution it finds, or iterate and show them all.

Click on Verify



The ResultsThe Results For each run, the tool visualizes:

• which events of a role could not be completed (nb: the tools tries to complete each role, but this is sometimes impossible)

• the complete run.



Examples of Results (1) Examples of Results (1) SOLUTION FOUND

State: [[alice,[]],[bob,[recv(nb * pk(b))]],[sec,[]]] . . .

alice finished sec finished!

bob did not finish



Examples of Results (2)Examples of Results (2)SOLUTION FOUND State: [[a,[]],[b,[recv(nb * pk(b))]],[sec,[]]]

Trace: [a,send([a,na] * pk(e))] [b,recv([a,na] * pk(b))] [b,send([na,nb] * pk(a))] [a,recv([na,nb] * pk(a))] [a,send(nb * pk(e))] [sec,recv(nb)]



What if we try another What if we try another scenario?scenario?

scenario([ [alice1,Init1], [alice2,Init2], [bob,Resp1], [sec,Secr1] ] ) :- initiator(a,b,na,Nb,Init1),

initiator(b,A,na,Nb,Init1), responder(a,b,Na,nb,Resp1),

secrecy(nb, Secr1).

•TRY THIS!



Exercise 1: Modify NS as Lowe Exercise 1: Modify NS as Lowe proposedproposed

A->B : [A,Na]*pk(B)

B->A : [Na,Nb,B]*pk(A)

A->B : [Nb]*pk(B)

To do• implement the roles

• Try bigger scenarios, with at least two parallel sessions

• Find Millen’s type flaw attack



Looking for authentication flaws Looking for authentication flaws in Needham-Schroederin Needham-Schroeder

Consider (again) the scenario:

No secrecy check this time. But, if B is not b, and the responder role finishes,

we have an authentication attack!

{initiator(a,B,na,Nb), responder(a,b,Na,nb)}



Looking for authentication flaws in Looking for authentication flaws in Needham-Schroeder cont’dNeedham-Schroeder cont’d

We only have to specify has_to_finish to b:

has_to_finish([b]).

And verify again…



Results: the first reported traceResults: the first reported traceSOLUTION FOUND

State: [[a,[]],[b,[]]]

Trace: [a,send([a,na] * pk(b))]

[b,recv([a,na] * pk(b))]

[b,send([na,nb] * pk(a))]

[a,recv([na,nb] * pk(a))]

[a,send(nb * pk(b))]

[b,recv(nb * pk(b))]

This is a normal run This is a correct trace. To find a flaw we must look for

B not instantiated to b!



Results: the right traceResults: the right traceSOLUTION FOUND

State: [[a,[]],[b,[]]]

Trace: [a,send([a,na] * pk(e))]

[b,recv([a,na] * pk(b))]

[b,send([na,nb] * pk(a))]

[a,recv([na,nb] * pk(a))]

[a,send(nb * pk(e))]

[b,recv(nb * pk(b))]



Another protocol: YahalomAnother protocol: YahalomA->B : A,Na

B->S : [A, Na,Nb]+Kbs

S->A : [B, Kab, Na, Nb]+Kas, [A,Kab]+Kbs

A->B : [A, Kab]+Kbs, [Nb]+Kab [t]+k: symmetric encryption Kxs: shared key between x and s Na, Nb: nonces Goal: establish a secret session key Kab Incorrect (see Clark and Jacob library)



Exercise for homeExercise for home For the yahalom protocol:

• Encode the protocol• Verify the protocol: try many scenarios• Could you find any flaw?• Model leakage of Nb (i.e., B sends Nb in plain at some

point)• Verify again the protocol: could you find any flaw?• Compare this attack to the one described by Clark & Jacob

2. Try the other protocols listed in the online tool. http://130.89.144.15/cgi-bin/show.cgi www.cs.utwente.nl/~corin



Security Protocols & the Security Protocols & the AttacksAttacks

• Otway-Rees• Secrecy+type-flaw attack

• Kao-chow• replay-attack

• Woo-Lam• authentication+type flaw attack

• NSL (as bonus protocol)• auth+type-flaw attack



Otway-Rees ProtocolOtway-Rees Protocol1. A->B : [M,A,B,[Na,M,A,B]+Kas]

2. B->S : [M,A,B,[Na,M,A,B]+Kas], [Nb,M,A,B]+Kbs

3. S->B : [M, [Na,Kab]+Kas, [Nb,Kab]+Kbs

4. B->A : [M,[Na,Kab]+Kas ]

Aim: key distribution using a trusted server. Kab: short-term key.

• Could be guessed.

Na and Nb serve as challenges.



Attack upon Otway-ReesAttack upon Otway-Reesa.1 A->e(B) : [M,A,B,[Na,M,A,B]+Kas]

a.4 e(B)->A : [M,A,B,[Na,M,A,B]+Kas]

Type flaw attack• A takes [M,A,B] to be the key

The intruder just replies the first message. It is an authentication flaw. It is also a secrecy flaw (the intruder knows the

key, now).



Otway-Rees in the toolOtway-Rees in the tool

initiator(A,B,Na,Nb,M,X,Kas,Kab,[ recv([A,B]), % for origination assumption send([M,A,B,[Na,M,A,B]+Kas]]), recv([M,[Na,Kab]+Kas]), send(X+Kab)]). % another way of checking secrecy

responder(A,B,Na,Nb,M,X,Kas,Kab,[ %NOT RELEVANT recv([M,A,B,[Na,M,A,B]+Kas]), send([[M,A,B,[Na,M,A,B]+Kas], [Nb,M,A,B]+Kbs]), recv([[M,Na,Kab]+Kas, [Nb,Kab]+Kbs]), send([M,[Na,Kab]+Kas]), recv(X+Kab) ]).



Otway-Rees in the tool cont’dOtway-Rees in the tool cont’d

secrecy(N,[recv(N)]).

server(A,B,Na,Nb,M,X,Kas,Kab,[

recv([[M,A,B,[Na,M,A,B]+Kas]]],

[Nb,[M,[A,B]]]+Kbs]),

send([[M,[Na,Kab]]+Kas,

[Nb,Kab]+Kbs])]).



ScenarioScenarioOne initiator is enough.And the secrecy check.We could not check secrecy the “usual” way because Kab is not instantiated anywhere (it is given by the server).

scenario([[sec1,St],[a,Sa1]]) :- initiator(a,b,na,Nb,m,x,kas,Kab,Sa1), secrecy(x, St).

initial_intruder_knowledge([a,b,e]).has_to_finish([sec1]).



The Attack OutputThe Attack Output

Trace: [a,recv([a,b])][a,send([m,[a,[b,[na,[m,[a,b]]] + kas]]])][a,recv([m,[na,[m,[a,b]]] + kas])][a,send(x + [m,[a,b]])][sec1,recv(x)]



Kao-Chow authentication Kao-Chow authentication ProtocolProtocol

1. A->S : [A,B,Na]

2. S->B : [A,B,Na,Kab]+Kas,[A,B,Na,Kab]+Kbs,

3. B->A : [A,B,Na,Kab]+Kas,[Na+Kab,Nb]

4. A->B : Nb+Kab

Assumption: Kab is compromised



Attack upon Kao-ChowAttack upon Kao-Chowa.1 A->S : [A,B,Na] a.2 S->B : [A,B,Na,Kab]+Kas, [A,B,Na,Kab]+Kbs

a.3 B->A : [A,B,Na,Kab]+Kas,[Na+Kab,Nb]

a.4 A->B : Nb+Kab

b.2 e(S)->B : [A,B,Na,Kab]+Kas,[A,B,Na,Kab]+Kbs

b.3 B->e(A) : [A,B,Na,Kab]+Kas, [Na+Kab,Nb’]

b.4 e(A)->B : Nb’+Kab



How it worksHow it works Two sessions. First a normal session is carried out. We assume the intruder “guesses” Kab.

• This is something we have to implement manually.

In a second session, the intruder can impersonate both A and the server S.



Kao-Chow in the toolKao-Chow in the toolinitiator(A,B,Na,Nb,Kas,Kab,Kbs,[ recv([A,B]), % for origination assumption send([A,[B,Na]]), recv([ [A,[B,[Na,Kab]]]+Kas,[ Na+Kab, Nb ]]), send(Nb+Kab) ]).responder(A,B,Na,Nb,M,Kab,Kbs,[ recv([M, ([A,[B,[Na,Kab]]]+Kbs)]), %M because he cannot decipher it send([M, [ Na+Kab, Nb ]]), recv(Nb+Kab), send(Kab) % we model that the key kab was compromised... ]).



ScenarioScenarioscenario([[a1,Sa1],[a2,Sb1],[a3,Sb2],[s1,Ss1]]) :-initiator(a,b,na,Nb,kas,Kab,Kbs,Sa1),responder(a,b,Na1,nb1,M,Kab1,kbs,Sb1),responder(a,b,Na2,nb2,M2,Kab2,kbs,Sb2),server(a,b,Na3,kas,kab,kbs,Ss1).

initial_intruder_knowledge([a,b,e]).has_to_finish([a2,a3]).

• session consisting of: initiator, two responders, one server.

• any larger session will do.

•If both responders can finish there is certainly an attack.



The Attack OutputThe Attack OutputTrace: [a1,recv([a,b])][a1,send([a,[b,na]])][s1,recv([a,[b,na]])][s1,send([[a,[b,[na,kab]]] + kas,[a,[b,[na,kab]]] + kbs])][a2,recv([_h381,[a,[b,[na,kab]]] + kbs])] % a variable here[a2,send([_h381,[na + kab,nb1]])][a1,recv([[a,[b,[na,kab]]] + kas,[na + kab,nb1]])][a1,send(nb1 + kab)][a2,recv(nb1 + kab)][a2,send(kab)][a3,recv([_h433,[a,[b,[na,kab]]] + kbs])][a3,send([_h433,[na + kab,nb2]])][a3,recv(nb2 + kab)][a3,send(kab)]



Woo-Lam Mutual Woo-Lam Mutual Authentication ProtocolAuthentication Protocol

1. A->B : [A,Na]

2. B->A : [B,Nb]

3. A->B : [A,B,Na,Nb]+Kas

4. B->S : [A,B,Na,Nb]+Kas, [A,B,Na,Nb]+Kbs

5. S->B: [B,Na,Nb,Kab]+Kas,[A,Na,Nb,Kab]+Kbs

6. B->A: [B,Na,Nb,Kab]+Kas, [Na,Nb]+Kab

7. A->B: Nb+Kab



Attack upon Woo-LamAttack upon Woo-Lam

a.1 e(A)->B : [A,B]a.2 B->e(A) : [B,Nb] a.3 e(A)->B : [A,B,B,Nb]+Kesa.4 B->e(S) : [A,B,B,Nb]+Kes, [A,B,B,Nb]+Kbsb.1 e(A)->B : [A,Nb]b.2 B->e(A) : [B,Nb' ] b.3 e(A)->B : [A,B,Nb,Nb' ]+Kesb.4 B->e(S) : [A,B,Nb,Nb' ]+Kes,[A,B,Nb,Nb' ]+Kbsa.5 e(S)->B: [B,B,Nb,Nb' ]+Kes,[A,B,Nb,Nb' ]+Kbsa.6 B->e(A): [B,B,Nb,Nb' ]+Kes,[ B,Nb]+Nb' a.7 e(A)->B: Nb+Nb'



CommentsComments There is one complete session and one

incomplete session. Which agents do we actually have to

implement to find this attack?



One Responder will do:One Responder will do:Woo-Lam in the ToolWoo-Lam in the Tool

responder(A,B,Na,Nb,Kab,Kas,Kbs,[ recv([A,B]), % for origination assumption recv([A,Na]), send([B,Nb]), recv([A,[B,[Na,Nb]]]+Kas), send([([A,[B,[Na,Nb]]]+Kas), ([A,[B,[Na,Nb]]]+Kbs) ]), recv([([B,[Na,[Nb,Kab]]]+Kas), ([A,[Na,[Nb,Kab]]]+Kbs) ]), send([([B,[Na,[Nb,Kab]]]+Kas), ([Na,Nb]+Kab) ]), recv(Nb+Kab) ]).



ScenarioScenarioscenario([[b1,Sb1],[b2,Sb2]]) :- responder(a,b,Na1,nb1,Kab1,Kas,kbs,Sb1), responder(a,b,Na2,nb2,Kab2,Kas,kbs,Sb2).

initial_intruder_knowledge([a,b,e]).has_to_finish([b1]).

The definition of the responder is sufficient, but we need two responders here.If one of the two finishes, there is certainly an attack.RULE: if a role can finish when no corresponding role is defined we are in certainly presence of an authentication problem.



The Attack Output (after 30s!)The Attack Output (after 30s!)Trace: [b1,recv([a,b])][b1,recv([a,b])][b1,send([b,nb1])][b1,recv([a,[b,[b,nb1]]] + _h97)][b1,send([[a,[b,[b,nb1]]] + _h97,[a,[b,[b,nb1]]] + kbs])][b2,recv([a,b])][b2,recv([a,nb1])][b2,send([b,nb2])][b2,recv([a,[b,[nb1,nb2]]] + _h97)][b2,send([[a,[b,[nb1,nb2]]] + _h97,[a,[b,[nb1,nb2]]] + kbs])][b1,recv([[b,[b,[nb1,nb2]]] + _h97,[a,[b,[nb1,nb2]]] + kbs])][b1,send([[b,[b,[nb1,nb2]]] + _h97,[b,nb1] + nb2])][b1,recv(nb1 + nb2)]



ExercisesExercises Explain the attack in the Woo-Lam protocol. Say why it is a type flaw attack. Implement and find the flaw of the Needham-

Schroeder with Conventional keys (see Clark-Jacob Survey).

Implement and find the flaw of the Yahalom protocol (see Clark-Jacob Survey).

Write a small article over how to find security bugs in protocols using the COProVe tool.



Extra: Needham-Schroeder-Extra: Needham-Schroeder-Lowe ProtocolLowe Protocol

1. A->B : [A,Na]*pk(B)

2. B->A : [Na,Nb,B]*pk(A)

3. A->B : Nb*pk(B)

Corrected version of the other one.Still contains an (unrealistic) flaw



Attack upon NSLAttack upon NSLa.1 A->e(B) : [A,Na]*pk(B)

a.1' e(A)->B : [A,e]*pk(B)

a.2 B->e(A) : [e,Nb,B]*pk(A)

b.1 e->A : [e, [Nb,B] ]*pk(A)

b.2 A->e: [[Nb,B], Na' ,A] *pk(e)

Message a.2 is passed as b.1.Notice that a.2 has three fields, while b.1 has two.It is a type flaw attack.Rather unrealistic.



NSL in the toolNSL in the tool

initiator(A,B,Na,Nb,[ recv([A,B]), % for origination assumption send([A,Na]*pk(B)), recv([Na,[Nb,B]]*pk(A)), send(Nb*pk(B)) ]).

responder(A,B,Na,Nb,[ recv([A,Na]*pk(B)), send([Na,[Nb,B]]*pk(A)), recv(Nb*pk(B)) ]).

secrecy(N,[recv(N)]).



ScenarioScenario

scenario([[a1,Sa],[a2,Sb],[a3,Sa2],[b1,Sb2],[sec1,St]]):- initiator(a,b,na,Nb,Sa), responder(a,b,Na,nb,Sb), initiator(A1,B1,na2,Nb2,Sa2), responder(A2,B2,Na2,nb2,Sb2), secrecy(nb,St).

initial_intruder_knowledge([a,b,e]).has_to_finish([sec1]).



NSL outputNSL outputTrace: [a1,recv([a,b])][a1,send([a,na] * pk(b))][a2,recv([a,e] * pk(b))][a2,send([e,[nb,b]] * pk(a))][a3,recv([_h414,e])][a3,send([_h414,na2] * pk(e))][a3,recv([na2,[_h416,e]] * pk(_h414))][a3,send(_h416 * pk(e))][b1,recv([e,[nb,b]] * pk(a))][b1,send([[nb,b],[nb2,a]] * pk(e))][a2,recv(nb * pk(b))][b1,recv(nb2 * pk(a))][sec1,recv(nb)]

university of twente the netherlands centre for telematics and information technology design,...

Documents

pkb slide

netherlands centre

university of twente

responder b

agent b

responders nb

information technology

information technology