Shane Bracher
Upcoming SlideShare
Loading in...5
×
 

Shane Bracher

on

  • 263 views

 

Statistics

Views

Total Views
263
Views on SlideShare
263
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Shane Bracher Shane Bracher Presentation Transcript

    • Enabling Security Testing from Specification to Code Shane Bracher and Padmanabhan Krishnan Fifth International Conference on Integrated Formal Methods (IFM 2005) 29 November – 2 December 2005 Eindhoven, The Netherlands
    • Problem Statement
      • Formal models:
        • Usually created for verifying key properties.
        • The more abstract, the easier to verify.
        • But for testing , they are too far removed from the implementation.
      • Possible testing approaches:
        • Exhaustive testing – all possible behaviour.
        • Bounded exhaustive testing – all possible behaviour to a certain depth.
        • Fault injection testing – reaction under faulty environments.
        • Model based testing – aims to reduce the testing effort.
    • Objective
      • We have a formal model of a protocol.
      • We want to use this model to derive test sequences.
      • In particular, we are interested in testing the security properties.
      • How can we use model based techniques to automatically generate test sequences for testing the security properties of protocols?
      • Test sequences generated from:
        • the formal model are too abstract. (too far from the implementation)
        • the implementation are too concrete. (not reusable)
    • Methodology
      • Translate the “high-level” formal specification into an intermediary model:
        • less abstract
        • closer to an implementation
      • Now we can generate test sequences from the intermediary model (which was derived from the formal model).
      • For testing the security properties:
        • The security goals are already stated in the high-level model.
        • We can specify these goals within the intermediary model as annotations .
    • “Bridging the gap” High Level Protocol Specification Language (HLPSL) Bandera Intermediate Representation (BIR) Bogor Model Checking Framework
    • Case Study
      • Internet Open Trading Protocol (IOTP)
      • Objectives of case study:
        • Verify the ability to translate a high-level model into an intermediary model.
        • Using annotations, determine the possibility of deriving test sequences from the intermediary model.
    • Internet Open Trading Protocol Merchant (M) Payment Processor (P) Delivery Agent (D) Offer BrandList, Offer Select, Offer Pay, Offer, Sig_M(Pay) Offer, Pay, Merchant, Sig_C(Pay) Receipt, Sig_P(Pay, Receipt, Offer) Sig_P(Pay, Receipt, Offer), Pay, Receipt, Offer Data, Sig_D(Data) Customer (C)
    • Intermediary Model
      • record (|Customer|) extends (|Role|) {
      • (|Agent|) /|Customer.C| ; /* All agents */
      • (|PublicKey|) /|Customer.Kc| ; /* All keys */
      • (|Channel|) /|Customer.SND_CM| ; /* All channels */
      • /* snipped */
      • loc loc1: live { [|brandlist|] , [|offer|] , [|select|] }
      • when [|this|] . /|Customer.RCV_CM| .read do invisible {
      • [|brandlist|] := ( (|BrandList|) ) [|this|] . /|Customer.RCV_CM| . /|Channel.payload| [ 0 ];
      • [|offer|] := ( (|Offer|) ) [|this|] . /|Customer.RCV_CM| . /|Channel.payload| [ 1 ];
      • [|this|] . /|Customer.RCV_CM| .read := false ;
      • [|select|] := new (|Select|) ;
      • [|this|] . /|Customer.SND_CM| . /|Channel.payload| [ 0 ] := [|select|] ;
      • [|this|] . /|Customer.SND_CM| . /|Channel.payload| [ 1 ] := [|offer|] ;
      • [|this|] . /|Customer.SND_CM| .read := true ;
      • }
      • goto loc2;
    • Deriving Test Sequences
      • Security properties tested:
        • Authentication – Customer authenticates Merchant on Pay.
        • Secrecy – Pay is to remain secret from the Delivery Agent (hypothetical).
      • Sessions:
        • Authentic Customer – Authentic Merchant
        • Authentic Customer – Intruder acting as Merchant
        • Intruder acting as Customer – Authentic Merchant
      • Test sequences produced as counter examples.
        • But to get a counter example, we need a violation to occur.
        • Solution: negate the security goals.
    • Results
      • Concurrent sessions:
        • 480 test sequences returned.
        • Reason: violation found in large number of interleavings.
        • Too many for the Bogor Counter Example Environment to display.
      • Therefore, it was necessary to identify a sufficiently simple interleaving in order for a test sequence trace to be returned.
    • Conclusion
      • Demonstrated the practicability of using an intermediary model for automatically deriving test sequences for testing the security properties of protocols.
      • The derived test sequences are both suitable and reusable for testers to apply to a working protocol implementation.
    • Thank you for your attention.
      • Shane Bracher [email_address]
      • Padmanabhan Krishnan [email_address]
      • Centre for Software Assurance School of Information Technology, Bond University Gold Coast, Queensland, 4229, AUSTRALIA
      • www.sand.bond.edu.au