1 / 22

A FAULT-TREE REPRESENTATION OF NPATRL SECURITY REQUIREMENTS

This paper proposes a formal language, NPATRL, for specifying crypto protocol requirements that is expressive, accurate, and easy to read and write. It presents a fault-tree representation of NPATRL requirements and provides a translation from NPATRL to precedence trees.

kmunday
Download Presentation

A FAULT-TREE REPRESENTATION OF NPATRL SECURITY REQUIREMENTS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 20375 meadows@itd.nrl.navy.mil iliano@itd.nrl.navy.mil http://chacs.nrl.navy.mil

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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"

  7. 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)

  8. 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, _)

  9. HOW UGLY CAN REQUIREMENTS GET? learns(intruder,(),(Knew),_) & gcks_createkey(G,()(Knew,Kold),N) => ( learns(intruder,(),(K’),_) & gcks_createkey(G,(),(K’,K’’),_) & (gcks_createkey(G,(),(Knew,Kold),_)) OR (gcks_sendkey(G, member(A,dishonest),(PGA,Knew,I),_)) OR (gcks_createkey(G,Group,(Knew,Kold),N)) & (gcks_sendkey(G,member(A,dishonest),(PGA,K’,I),_)) & not ( (gcks_expel(G,member(A,dishonest),(I),_))) OR (gcks_losekey(G,(), (Knew),_) OR ( (gcks_sendkey(G,(member(B,honest)),(PGB, Knew),_)) & (gcks_losepairwisekey(GCKS,(),(PGB),_)))

  10. 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

  11. 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?

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

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

  14. Not Gate Or Gate E Event Event Event And Gate 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 R == E == E F == E E F1 F2 F1 F2

  15. Not Gate Or Gate Event Event Event And Gate TRANSLATION { } FROM NPATRL TO PRECEDENCE TREES

  16. 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 • KGM = pairwise key • K, Knew,Kold = group keys • Relevant events • member_acceptkey(M,G,(KGM,K),N) • gcks_losepairwisekey(G,M,[KGM),N) • gcks_createkey(G,(),(Knew Kold ),N) • member_requestkey(M,G,(),N)

  17. RECENCY FRESHNESS Member should accept the most recent key generated before its request member_acceptkey(M,G,(KGM,Kold),N) => gcks_losepairwisekey(G,(),(M,KGM),_) or not( (member_requestkey(M,G,(),N) and gcks_createkey(G,(),(Knew,Kold),_)))

  18. SEQUENTIAL FRESHNESS If member accepts key, should not have previously accepted a later key member_acceptlkey(M,G,(KGM,Kold),N) => gcks_losepairwisekey(G,(),(M,KGM),_) or not( member_acceptlkey(M,G,(KGM,Knew),_) & (gcks_createkey(G,(),(Knew,K’),_) & gcks_createkey(G,(),(Kold,K’’),_)))

  19. Gcks_losepairwisekey (G,(),(M,KGM),_) Gcks_losepairwisekey (G,(),(M, KGM,),_) Member_acceptkey (M,G,(KGM,,Knew),_) Member_requestkey (M,G,(),N) Member_acceptkey (M,G,(KGM,Kold,N) Member_acceptkey (M,G,(KGM,Kold,N) Gcks_createkey (G,(),(Knew, Kold),_) Gcks_createkey (G,(),(Kold,K’’),_) Gcks_createkey (G,(),(Knew,K’),_) PRECEDENCE TREE VERSIONS

  20. BACK TO UGLY REQUIREMENT learns(intruder,(),(Knew),_) & gcks_createkey(G,()(Knew,Kold),N) => ( learns(intruder,(),(K’),_) & gcks_createkey(G,(),(K’,K’’),_) & (gcks_createkey(G,(),(Knew,Kold),_)) OR (gcks_sendkey(G, member(A,dishonest),(PGA,Knew,I),_)) OR (gcks_createkey(G,Group,(Knew,Kold),N)) & (gcks_sendkey(G,member(A,dishonest),(PGA,K’,I),_)) & not ( (gcks_expel(G,member(A,dishonest),(I),_))) OR (gcks_losekey(G,(), (Knew),_) OR ( (gcks_sendkey(G,(member(B,honest)),(PGB, Knew),_)) & (gcks_losepairwisekey(GCKS,(),(PGB),_)))

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

  22. 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

More Related