A fault tree representation of npatrl security requirements
This presentation is the property of its rightful owner.
Sponsored Links
1 / 22

A FAULT-TREE REPRESENTATION OF NPATRL SECURITY REQUIREMENTS PowerPoint PPT Presentation


  • 76 Views
  • Uploaded on
  • Presentation posted in: General

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 [email protected] [email protected] http://chacs.nrl.navy.mil.

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


A fault tree representation of npatrl security requirements

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

[email protected]

[email protected]

http://chacs.nrl.navy.mil


Problem we re addressing

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

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

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

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

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

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

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

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


Insight most requirements are of the same form

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

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

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


Grammar for npatrl subset

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

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


Translation from npatrl to precedence trees

Not

Gate

Or Gate

Event

Event

Event

And

Gate

TRANSLATION { } FROM NPATRL TO PRECEDENCE TREES


Example gdoi protocol

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)


Recency freshness

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


Sequential freshness

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’’),_)))


Precedence tree versions

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


Back to ugly requirement

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


A fault tree representation of npatrl security requirements

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


How we ve used precedence trees

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


  • Login