A FAULT-TREE REPRESENTATION OF NPATRL SECURITY REQUIREMENTS Iliano Cervesato, ITT Catherine Meadows Code 5543 Center for High Assurance Computer Systems Naval Research Laboratory Washington, DC

PROBLEM WE’RE ADDRESSING Crypto protocol requirements often harder to get right than the protocols themselves –Many flaws really result of misunderstood requirements What’s needed is formal language for crypto protocol requirements that’s –Expressive –Accurate –Easy to read and write Many languages satisfy the first two requirements –Few if any, satisfy the third

THE NRL PROTOCOL ANALYZER Formal methods tool for verifying security properties of crypto protocols and finding attacks User specifies protocol in terms of communicating state machines communicating by use of a medium controlled by a hostile intruder User verifies protocol by 1. Proving a set of lemmas to limit size of search space 2. Specifying an insecure state 3. Using NPA to search backwards from that state to see if attack can be found

NRL Protocol Analyzer Model Honest Principals modeled as communicating state machines Adversary can intercept, read, alter, and create messages –Does not know secrets (e.g. keys) of honest principals unless They are explicitly compromised It can learn them from a message Dishonest principals part of the adversary Each run of a protocol local to a principal assigned a unique round number – Allows distinguishing of different runs local to a principal

NPA Events Each state transition in an NPA spec may be assigned an event, denoted by event(P, Q, T, L, N) – P: principal doing the transition – Q: list of other parties involved in transition – T: name of the transition rule – L: list of words relevant to transition –N: local round number Events are the building blocks of the NPATRL Language

NPATRL NRL-Protocol-Analyzer-Temporal-Requirements- Language –Pronounced 'N Patrol' Requirements characterized in terms of event statements, of two sorts –Events corresponding to state transitions engaged in by honest principals – learn events indicate acquisition of information by adversary Add usual logical connectives, e.g., , ,  One temporal operator meaning "happens before"

SYNTAX OF NPATRL EVENTS NPATRL event of the form event_name(A,Plist,Wlist,N) Event_name characterizes type of event A name of principal engaging in the event Plist list of names of other principals involved e.g. intended recipient of message Wlist list of other terms relevant to action N local round number Identifies local execution Similar to notion of a strand in strand spaces Example NPATRL event init_acceptkey(A,B,(Key,NonceA,NonceB),N)

Example NPATRL Requirement If an honest A accepts a key Key for communicating with an honest B, then a server must have generated and sent the key for an honest A and an honest B to use. accept( user(A, honest), user(B, honest), (Key), _ ) =>  send(server, (user(A, honest), user(B,honest),(Key, _)

HOW UGLY CAN REQUIREMENTS GET? learns(intruder,(),(K new ),_) & gcks_createkey(G,()(K new,K old ),N) => ( learns(intruder,(),(K’),_) & gcks_createkey(G,(),(K’,K’’),_) & (gcks_createkey(G,(),(K new,K old ),_)) OR (gcks_sendkey(G, member(A,dishonest),(P GA,K new,I),_)) OR (gcks_createkey(G,Group,(K new,K old ),N)) & (gcks_sendkey(G,member(A,dishonest),(P GA,K’,I),_)) & not ( (gcks_expel(G,member(A,dishonest),(I),_))) OR (gcks_losekey(G,(), (K new ),_) OR ( (gcks_sendkey(G,(member(B,honest)),(P GB, K new ),_)) & (gcks_losepairwisekey(GCKS,(),(P GB ),_)))

INSIGHT: MOST REQUIREMENTS ARE OF THE SAME FORM A final event –Intruder learns a key –Principal accepts a key preceded by sequences of events that should or should not have occurred –Key is compromised –Key is distributed to dishonest principal

SIMILAR TO STRUCTURE OF FAULT TREES Fault tree: a graphical notation used for safety requirements –Root of the tree is a final event or fault –Children of a node the conditions which would contribute to the event or condition represented by that node Why not use fault trees to provide a semantics for a portion of NPATRL?

A FAULT TREE GRAMMAR T == Event T Or Gate And Gate T T 1 T 2 T 1 T 2 Not Gate Line is a simple connector when parent node is a gate Line stands for child implies parent when parent node is an event

GRAMMAR FOR NPATRL SUBSET R ::== a => F F ::== E | not(E) | F1 /\ F2 | F1 \/ F2 E ::== a | (a /\ E)

PRECEDENCE TREES FOR USE WITH NPATRL Edges in R trees stand for implies Edges in F trees are connectors Edges in E trees stand for Event E And Gate Or Gate Not Gate E Event R == E == F == E E F 1 F 2 F 1 F 2

TRANSLATION { } FROM NPATRL TO PRECEDENCE TREES { R } r { F } f { E } e a => F Enot(E)F1\/ F2F1 /\ F2 a (a /\ E) {F} {E} {F 1 } {F 2 } {E} Event Not Gate Or Gate And Gate

EXAMPLE: GDOI PROTOCOL Two types of principals; Group controllers (GCKS) and members Member joins group by initiating handshake protocol –Uses pairwise key shared between it and GCKS –Gets current group key as result of handshake Relevant data: –G = controller name –K GM = pairwise key –K, K new,K old = group keys Relevant events –member_acceptkey(M,G,(K GM,K),N) –gcks_losepairwisekey(G,M,[K GM ),N) –gcks_createkey(G,(),(K new K old ),N) –member_requestkey(M,G,(),N)

RECENCY FRESHNESS Member should accept the most recent key generated before its request member_acceptkey(M,G,(K GM,K old ),N) => gcks_losepairwisekey(G,(),(M,K GM ),_) or not( (member_requestkey(M,G,(),N) and gcks_createkey(G,(),(K new,K old ),_)))

SEQUENTIAL FRESHNESS If member accepts key, should not have previously accepted a later key member_acceptlkey(M,G,(K GM,K old ),N) => gcks_losepairwisekey(G,(),(M,K GM ),_) or not( member_acceptlkey(M,G,(K GM,K new ),_) & (gcks_createkey(G,(),(K new,K’),_) & gcks_createkey(G,(),(K old,K’’),_)))

PRECEDENCE TREE VERSIONS Member_acceptkey (M,G,(K GM,K old,N) Gcks_losepairwisekey (G,(),(M,K GM ),_) Member_requestkey (M,G,(),N) Gcks_createkey (G,(),(K new, K old ),_) Member_acceptkey (M,G,(K GM,K old,N) Gcks_losepairwisekey (G,(),(M, K GM,),_) Member_acceptkey (M,G,(K GM,,Knew),_) Gcks_createkey (G,(),(K new,K’),_) Gcks_createkey (G,(),(K old,K’’),_)

BACK TO UGLY REQUIREMENT learns(intruder,(),(K new ),_) & gcks_createkey(G,()(K new,K old ),N) => ( learns(intruder,(),(K’),_) & gcks_createkey(G,(),(K’,K’’),_) & (gcks_createkey(G,(),(K new,K old ),_)) OR (gcks_sendkey(G, member(A,dishonest),(P GA,K new,I),_)) OR (gcks_createkey(G,Group,(K new,K old ),N)) & (gcks_sendkey(G,member(A,dishonest),(P GA,K’,I),_)) & not ( (gcks_expel(G,member(A,dishonest),(I),_))) OR (gcks_losekey(G,(), (K new ),_) OR ( (gcks_sendkey(G,(member(B,honest)),(P GB, K new ),_)) & (gcks_losepairwisekey(GCKS,(),(P GB ),_)))

Fig. 4 Forward Access Control Without PFS or Backward Access Control or intruder learns key K new K new distributed to dishonest member by G Intruder learns key K’ K new created by GK’ created by G and G uses K GB to send key K new to B Pairwise key K GB between G and B and Intruder steals K K new created By G Dishonest member A joins group with index I Dishonest member A leaves group with index I not and not K new distributed gy G

HOW WE’VE USED PRECEDENCE TREES Used them to specify requirements for Group Domain of Interpretation protocol Helpful not only for readability and writeability, but useful for disambiguation and resolving confusion