One Picture is Worth a Thousand Words Couple Dozen Connectives - - PowerPoint PPT Presentation

▶
one picture is worth a thousand words couple dozen
SMART_READER_LITE
LIVE PREVIEW

One Picture is Worth a Thousand Words Couple Dozen Connectives - - PowerPoint PPT Presentation

Feb 16, 2024 33 likes •254 views

Work in progress Work in progress One Picture is Worth a Thousand Words Couple Dozen Connectives Iliano Cervesato iliano@itd.nrl.navy.mil ITT Industries, inc @ NRL Washington, DC http://theory.stanford.edu/~iliano Joint work with Cathy

slide-1
SLIDE 1

One Picture is Worth a Thousand Words

Iliano Cervesato

iliano@itd.nrl.navy.mil

ITT Industries, inc @ NRL Washington, DC

http://theory.stanford.edu/~iliano

ONR IPCS meeting September 23-25, 2003

Joint work with Cathy Meadows

Harpers Ferry, WV

Couple Dozen Connectives

Work in progress Work in progress

slide-2
SLIDE 2

Fault Tree Representation of Security Requirements 1

How this work came about

Analysis of GDOI group protocol

  • Requirements expressed in NPATRL
  • Novel group properties
  • Medium size specifications

– Dozen operators

  • Lots of fine-tuning
  • Difficult to read and share specs.
  • Informal use of fault trees
  • Intuitive visualization medium
  • Became favored language
  • Formal relation with NPATRL
slide-3
SLIDE 3

Fault Tree Representation of Security Requirements 2

Security Requirements

Describe what a protocol should do

  • Verified by
  • Model checking
  • Mathematical proof
  • Pattern-matching (in some cases)
  • Expressed
  • Informally
  • Semi-formally
  • Formal language
  • Adequate for toy protocols

BUT, do not scale to real protocols

slide-4
SLIDE 4

Fault Tree Representation of Security Requirements 3

Example: Kerberos 5

[CSFW’02]

  • Semi-formal
  • But very precise
  • Bulky and unintuitive
  • Requires several readings to grasp
slide-5
SLIDE 5

Fault Tree Representation of Security Requirements 4

Example: GDOI

[CCS’01]

  • Formal
  • NPATRL protocol spec. language
  • Ok for a computer
  • Bulky and unintuitive for humans
  • About 20 operators
slide-6
SLIDE 6

Fault Tree Representation of Security Requirements 5

Example: Authentication

  • Informal
  • Made precise as CSP expressions
  • Simple, but …
  • …

many very similar definitions

[Lowe, CSFW’97]

slide-7
SLIDE 7

Fault Tree Representation of Security Requirements 6

The Problem

  • Desired properties are difficult to
  • Phrase & get right
  • Explain & understand
  • Modify & keep right
  • Examples
  • Endless back and forth on GDOI
  • Are specs. right now?
  • K5 properties read over and over
slide-8
SLIDE 8

Fault Tree Representation of Security Requirements 7

Dealing with Textual Complexity

  • HCI response: graphical presentation
  • Our approach: Dependence Trees
  • Re-interpretation of fault trees
  • 2D representation of NPATRL
  • Intuitive for medium size specs.
slide-9
SLIDE 9

Fault Tree Representation of Security Requirements 8

Example: Kerberos 5

  • Excises the gist
  • f the theorem
  • Highlights

dependencies

  • Fairly intuitive
  • …

in a minute …

slide-10
SLIDE 10

Fault Tree Representation of Security Requirements 9

Example: GDOI

  • Isomorphic to NPATRL specifications
  • Much more intuitive
  • …

in a minute …

slide-11
SLIDE 11

Fault Tree Representation of Security Requirements 10

Example: Authentication

  • Formalize definitions
  • Easy to compare …
  • … and remember …
slide-12
SLIDE 12

Fault Tree Representation of Security Requirements 11

Rest of this Talk

  • Logic for protocol specs
  • NPATRL Logic
  • NRL Protocol Analyzer fragment
  • Model checking
  • Precedence trees
  • Fault trees
  • NPATRL semantics
  • Analysis of an example
  • Future Work
slide-13
SLIDE 13

Fault Tree Representation of Security Requirements 12

NPATRL

  • Formal language for protocol requirements
  • Simple temporal logic
  • Designed for NRL Protocol Analyzer
  • Simplify input of protocol specs
  • Sequences of events that should not occur
  • Applies beyond NPA
  • Used for many protocols
  • SET, GDOI, …
slide-14
SLIDE 14

Fault Tree Representation of Security Requirements 13

NPATRL Logic

  • Events

initiator_accept_key( A, (B,S), (KAB ,nA ), N)

  • Classical connectives: ∧, ∨, ¬, …
  • “Previously”: #

( )

initiator_accept_key(A, (B,S), (KAB ,nA ), N) 

#

server_sent_key(S, (A,B), (KAB ), _)

name actuator

  • ther agents

terms round

slide-15
SLIDE 15

Fault Tree Representation of Security Requirements 14

NPA Fragment

NPA uses a small fragment of NPATRL

R ::= a  F F ::= E | ¬E | F1 ∧ F2 | F1 ∨ F2 E ::= #a | #(a ∧ F)

  • Efficient model checking

R ::= a  F F ::= E | ¬E | F1 ∧ F2 | F1 ∨ F2 E ::= #a | #(a ∧ F)

slide-16
SLIDE 16

Fault Tree Representation of Security Requirements 15

Fault Trees

  • Safety analysis of system design
  • Root is a failure situation
  • Extended to behavior descriptions
  • Inner nodes are conditions enabling fault
  • Events
  • Combinators

(logical gates)

  • Example
  • A passenger needs a

ticket and a photo ID to board a plane, but should not carry a weapon

canBoard hasTicket carriesWeapon hasID

slide-17
SLIDE 17

Fault Tree Representation of Security Requirements 16

Precedence Trees

  • Fault tree representation of NPATRLNPA
  • Isomorphism

R ::= a  F F ::= E | ¬E | F1 ∧ F2 | F1 ∨ F2 E ::= #a | #(a ∧ F) a

F R

::= a

F E

::= a

F1 F

::= E

E F2 F1 F2

slide-18
SLIDE 18

Fault Tree Representation of Security Requirements 17

“Recency Freshness” in GDOI

member_accept_key(M,G,(KGM ,Kold ),N) 

#

gcks_loseparwisekey(G,(),(M,KGM ),_) ∨ ¬(# ( member_requestkey(M,G,(),N) ∧

#gcks_createkey(G,(),Knew

,Kold ),_)))

if a member accepts a key from the controller in a protocol run, no newer key should have been distributed prior to the mem- ber's request

slide-19
SLIDE 19

Fault Tree Representation of Security Requirements 18

“Sequential Freshness” in GDOI

member_accept_key(M,G,(KGM ,Kold ),_) 

#

gcks_loseparwisekey(G,(),(M,KGM ),_) ∨ ¬(# (member_acceptkey(M,G,(KGM ,Knew ),_) ∧

#(gcks_createkey(G,(),Knew

,K’),_) ∧

#gcks_createkey(G,(),Kold

,K’’),_))))

if a member accepts a key from the group controller in a proto- col run, then it should not have previously accepted a later key

slide-20
SLIDE 20

Fault Tree Representation of Security Requirements 19

Conclusions

  • Explored tree representation of protocol reqs.
  • Promising initial results
  • Complex requirements now intuitive
  • Precedence trees
  • Draw from fault trees research
  • Specialized to NPATRL and NPA
  • NPATRL semantics
  • Better understanding of NPATRL
  • Papers
  • “A Fault-Tree Representation of NPATRL Security

Requirements”, with Cathy Meadows

  • WITS’03
  • TCS (long version, submitted)
slide-21
SLIDE 21

Fault Tree Representation of Security Requirements 20

Future Work – Theory

  • What properties can be expressed?
  • All of safety?
  • Liveness?
  • Graphical equivalence of requirements?
  • Expressive power
  • Recursive trees?
  • More complex quantifier patterns?
  • Graphical gist of theorems
  • Useful classes?
  • Proofs?
slide-22
SLIDE 22

Fault Tree Representation of Security Requirements 21

Future Work – Practice

  • Gain further experience
  • Can they be used for other requirements?
  • Scaling up
  • When are trees so big they are non-intuitive?
  • Existing requirements?
  • Modularity
  • Interaction with fault tree community
  • Broader applications of dependence trees?
  • Tools we can use?
  • NPATRL <-> dependence trees