1 / 1

SLEDE: Event-Based Specification of Sensor Network Security Protocols*

SLEDE: Event-Based Specification of Sensor Network Security Protocols*. http://www.cs.iastate.edu/~slede. Solution. Problem. Sensor networks often used in hostile settings New protocols emerging to secure these networks Specifying and verifying these protocols is harder

tirzah
Download Presentation

SLEDE: Event-Based Specification of Sensor Network Security Protocols*

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. SLEDE: Event-Based Specification of Sensor Network Security Protocols* http://www.cs.iastate.edu/~slede Solution Problem • Sensor networks often used in hostile settings • New protocols emerging to secure these networks • Specifying and verifying these protocols is harder • Issues: group-oriented, resource constraint • SLEDE: An event-based specification language • Based on nesC syntax, a dominant programming language for networked systems • A model-based verification technique Event (Light, sound, motion, etc) node Sender { command result_t StdControl.init() { ... } event result_t Timer.fired() { ... call Transmission.broadcastMsg(msg); } } Action taken (Event Handler) Nodes in sensor networks use event-based paradigm Specification followsmessage-driven paradigm Implementation followsevent-based paradigm node Receiver { event result_t Receiving.receiveMsg(msg_t msg){ %if unable to decrypt, signal error signal Error.error(); % deliver message if decrypted call Transmission.deliver(msg); } } • Impedance mismatch leads to verification issues • e.g. missing assumptions • Results in proliferation of informal specifications Contributions • Easier to understand and write • Extensible w.r.t. intruder and channel models • More expressive objectives in terms of user-defined events • In existing specification languages, goals are fixed (e.g. SECRET, PRECEDES in CAPSL [1]) • Example objective: ensure that the data received from a certain node is not sent by an impersonator objective { Sender.Transmission.broadcastMsg(msg) => (Receiver.ReceiveMsg(msg) && Receiver.Transmision.deliver(msg)) || (Receiver.ReceiveMsg(msg) && Receiver.Error.error()) } lib securityLib{ command int hash(Key inputKey, msg_t theMsg) { ... } in SLEDE: Sender.Transmission.broadcastMsg(msg)=> Receiver.Receiving.ReceiveMsg(msg) && ! Receiver.Error.msgFromImpersonator() • Objectives described in terms of commands and events • Event-based communication is emulated using global channels in PROMELA model in CAPSL: can’t be represented [1] J. K. Millen. CAPSL:Common authentication protocol specification language .In NSPW’96Proceedings of the 1996 workshop on New security paradigms, 1996. *This research is supported in part by the National Science Foundation under grant CT-ISG 0627354 Youssef Hanna and Hridesh Rajan Department of Computer Science

More Related