A Maude-PVS tool for Strand Spaces Status Report

1. A Maude-PVS tool for Strand SpacesStatus Report Carolyn Talcott SRI International Protocol Exchange September 2004

2. Vision A formally based, formally verified tool for design and analysis of strand space protocol specifications. Idea -- use formal mappings between PVS and Maude in order to provide the best of both worlds for a wide range of formal modeling and analysis problems. Strand Spaces informally Strand Spaces in PVS Strand Spaces in Maude

3. Building Blocks • Maude • a language and environment based on rewriting logic • Executable specifications • Reflection • IOP+Imaude • A platform for message based interaction of tools • Tools wrapped as actors • File and socket managers builtin • Graphics2d actor for programmable interactive visualization • PVS • a proof system based on Higher-Order logic • Functions and relations are first class entities • Flexible type system and powerful decision procedures

4. References • Maude: http://maude.cs.uiuc.edu • IOP+IMaude: http://mcs.une.edu.au/~iop • PVS: http://pvs.csl.sri.com • Strands: [winner] Strand Spaces: Proving security protocols correct. F. Javier Thayer, Jonathan C. Herzog, and Joshua D. Guttman. [auth] Protocol design via the authentication tests. Joshua D. Guttman. [shapes] The Shapes of Bundles. Shaddin F. Doghmi, Joshua D. Guttman, and F. Javier Thayer

5. Plan I(first version mostly done) • Maude representation of protocol specifications based on Strand Spaces • Data structures -- terms, strands, bundles • Operational semantics -- configurations, rules • Mapping computations <-> bundles • Tool • Visualization of bundles • Input of specifications

6. Plan II (to do) • Analysis -- specification of • Concepts related to shapes and tests • Guarantees • Algorithms for checking guarantees • (Meta) verification • Formal mapping Maude <-> PVS (adequate subsets) • Informal proof of mapping correctness • Specification and verification of algorithm correctness

7. This Talk • Maude specification of protocol specifications • Data structures • Operational semantics • Visualization of bundles

8. Perspective: Strands and Actors Bundles correspond closely to the event diagram model of actor computation. What has not been spelled out is the computation, i.e. generation of bundles. • Actors are computational entities with identity, state, and behavior • Computational events are message receives • Response to a message receive -- send msg, modify state, create • An event diagram is a partial order on events generated by • the arrival order for each actor (a linear order) • the activation order, the receive activating a msg send is before the receive of that msg. Event diagrams for actor systems whose behavior is given by a strand space protocol specification are bundles.

9. Strand Data Structures • Message terms, patterns, substitutions, and matching • The initial model of an equational specification • Roles -- signed pattern lists, formalize definitions such as: Init[A,B,N,M,K] = … • Strand Identifiers • Strands -- strand id and signed mterm list • Protocol Specification is a set of Roles • Determines a Strand Space and a set of Bundles • Some data has extra information used for bookkeeping and understanding of computations

10. MTermP KeyP NonceP NameP TextP MTerm MTermV KeyV NonceV NameV TextV Key Nonce Name Text Message Terms, Patterns, Substitutions Terms and patterns generated from atoms and variables by tmP ^ tmP’ : MTermP {| tmP |} kP : MTermP sk(nP,nP’) : KeyP pk(nP) : KeyP Substitutions: Map variables to patterns of the same type Match(tmp,tm) = {true,subst} if tmp[subst] == tm

11. Roles • Signed Terms have one of the forms: • +(nP,tmP), -(tmP) where nP : NameP, tmP : MTermP • A role has the form • role(rname,pname,pars,stl) Where rname is the role name, pname : NameV, the player, pars : Vlist, parameters to instantiate, stl : SignedTermList It is well-formed if every variable occurring in a signed term is bound either by (pname,pars) or by a previous receive.

12. Role example yahalom-init = role("init", n("A"), (n("B"), n("S"), o("Na")), (+(n("B"),(n("A") ^ o("Na"))); -(({|n("B") ^ (k("K") ^ (o("Na") ^ o("Nb")))|} sk(n("S"),n("A"))) ^ m("M") ); +(n("B"),(m("M") ^ {|o("Nb")|}k("K"))))) . n(“A”) : NameV, o(“Na”) : NonceV , k(“K”) : KeyV ….

13. Strands • Strand identifiers (sort Sid) have the form: • nP . tid where tid : Nat (thread identifier) • A strand has the form: [ sid | stl ] • Example - yahalom init strand [ nc("A") . 0 | (+(nc("B"),(nc("A") ^ oc("Na"))); -(({| nc("B") ^ (kc("K") ^ (oc("Na") ^ c("Nb")))|} sk(nc("S"),nc("A"))) ^ ({| nc("A") ^ kc("K") |}sk(nc("S"),nc("B")))); +(nc("B"),({| nc("A") ^ kc("K")|} sk(nc("S"),nc("B"))) ^ {| oc("Nb") |}kc("K"))) ]

14. Strand Spaces The strand space determined by a set of roles R is the set of strands [n . tid : stl] where for some r = role(rname,pname,pars,stlP) and substitution s with domain including all variables in stlP such that pname[s] = n and stlP[s] = stl Bundles determined by R are finite sets of strands with unique identifiers, together with cross edges (activation order) associating each receive to a unique send such that the combined arrival and activation order is acyclic.

15. Operational Semantics • Main sorts : Player, Msg, Event • A player (actor) has the form: [ sid : rname | ix, stl ] • ix is the index of the next step in the the players role • stl is the remaining steps of the role being played • The initial state of a player in role(rname,pname,pars,stlP) has the form [ n . tid : rname | 1, stlP[s] ] where domain s is (pname,pars) and pname[s] = n. • A message in transit has the form: to(n, sid,ix,tm) • (sid,ix) identifies the strand sending node • n is the intended receiver, used for understanding • An event has one of the forms: • snd(sid,ix,n,tm) -- send by principal sid at step ix • rcv(sid’,ix’,sid,ix,tm) -- receive by principal sid’ at step ix’

16. Operational Semantics • A configuration has the form: conf(players,msgs,evl) • Players is the current state of the role players, unique ids • msgs is the set of messages in transit • evl is a list recording the events leading to the current state, represents the computation. • Rules rl[send]: conf([n0 . tid : rname | ix, (+(n1,tm); stl)] pls, msgs, evl) => conf([n0 . tid : rname | s ix, stl] pls, msgs to(n1,tm,(n0 . tid),ix), (evl ; snd((n0 . tid),ix,n1,tm))) . crl[receive]: conf([n0 . tid : rname | ix, (-(tmp); stl)] pls, to(n2,tm,(n1 . tid'), ix') msgs, evl) => conf([n0 . tid : rname | s ix, stl[sb]] pls, msgs, (evl ; rcv((n0 . tid),ix,(n1 . tid'),ix',tm))) if {true,sb} := match(tmp,tm) .

17. Computation - Bundle Correspondence 1. If c0 is an initial conf over R and c0 => conf(players,msgs,evl), then evl uniquely determines a bundle over R • for each player, sid, the strand for sid is given by the subsequence of events with player sid • the edges are given by the receive events 2. If B is a bundle over R, then there is an inital conf c0 over R and a comoputation c0 => conf(players,msgs,evl) where B is the bundle determined by evl.

18. Visualization Starting with an event list, draw the bundle diagram. For each player / strand there is a column of nodes connected by double down arrows. For each edge there is a cross arrow between the source and target nodes, labeled by the message The hard part is determining spacing of nodes in the columns so that cross arrows are horizontal, when possible. Rather than cluttering the arrows with complicated message terms, simple names are used and defined in a text area below the diagram.

19. Yahalom Demo(from Shapes paper) A -> B : A ^ Na B -> S : B ^ {| A ^ Na ^ Nb |}Kb S -> A : {| B ^ K ^ Na ^ Nb |}Ka ^ {| A ^ K |}Kb A -> B : {| A ^ K |}Kb ^ {| Nb |}K

20. Ottway Reese Demo(from Winner paper) A -> B : M A B {...}K(A,S) B -> S : M A B {...}K(A,S) {Nb M A B}K(B,S) S -> B : M {Na K}K(A,S) {Nb K}K(B,S) B -> A : M {Na K}K(A,S)