1 / 14

Team Automata for Security Analysis of Multicast/Broadcast Communication

Team Automata for Security Analysis of Multicast/Broadcast Communication. Maurice ter Beek, Gabriele Lenzini, Marinella Petrocchi Istituto di Scienza e Tecnologia dell’Informazione Istituto di Informatica e Telematica CNR - Pisa - Italy WISP 2003

garan
Download Presentation

Team Automata for Security Analysis of Multicast/Broadcast Communication

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. Team Automata for Security Analysis of Multicast/Broadcast Communication Maurice ter Beek, Gabriele Lenzini, Marinella Petrocchi Istituto di Scienza e Tecnologia dell’Informazione Istituto di Informatica e Telematica CNR - Pisa - Italy WISP 2003 1stWorkshop on Issues in Security and Petri nets Eindhoven, 23 June 2003 23 June 2003

  2. Outline • multicast/broadcast technology and EMSS protocol • Team Automata: • informal definition • example showing multicast/broadcast communication • relation to Petri nets • (in paper: instance of EMSS modelled by TA) • formulate GNDC schema for security analysis in terms of TA • conclusions and future work 23 June 2003

  3. Multicast/Broadcast technology Unicast: “sending a message through a point-to-pointconnection” Broadcast: “flooding a message to all the connected recipients using a single local transmit operation” (e.g. ordinary TV) Multicast: “sending a message to a set of designated recipients using a single local transmit operation” (e.g. pay-per-view TV) M/B technology was born with the intent of saving resources (e.g. bandwidth & CPU time) w.r.t. unicast 23 June 2003

  4. Stream signature protocols • send digital streams, i.e. long (potentially infinite) sequences of bits, as packets • guarantee authenticity and integrity • aim at minimizing the computational cost of signing and verifying packets a sender broadcasts a continuous stream to a possibly unbounded number of receivers Features receivers use information retrieved in earlier packets to authenticate later packets (or v.v.) 23 June 2003

  5. Tolerating packet loss • digital streams are usually sent over the User Data Protocol, an unreliable transport protocol • this may cause packet loss, i.e. the stream may be received incomplete by (a part of) the recipients • a stream signature protocol tolerates packet loss if it still allows a recipient to verify all packets that are not lost 23 June 2003

  6. The EMSS family of protocols • Efficient Multi-chained Stream Signature: family of protocols to sign digital streams (Perrig et al., IEEE S&P 2000) • basic idea: a hash of packet Pi is appended to packet Pi-1 (whose hash is in turn appended to packetPi-2 , etc.) • signature packet Psign at the end of the stream • each packet contains multiple hashes of previous packets and the signature packet contains hashes of multiple packets • multiple copies of the signature packet are sent 23 June 2003

  7. Packet PSign Hash(PLAST) Hash(PLAST-1) SIGNATURE The (1,2) deterministic EMSS Packet Pi-1 Packet Pi Packet Pi+1 Mi-1 Hash(Pi-2) Hash(Pi-3) Mi Hash(Pi-1) Hash(Pi-2) Mi+1 Hash(Pi) Hash(Pi-1) . . . Time / Number of packets EMSS achieves (some) robustness against packet loss 23 June 2003

  8. Team Automata • model logical architecture of a design • abstract from concrete data and actions • describe behaviour in terms of: • state-action diagram (automaton) • role of actions (input, output, internal) • synchronizations (simultaneous execution ofactions) • crux: automata composition • (Ellis, GROUP’97 & ter Beek et al., ECSCW’99 –> CSCW 2003) 23 June 2003

  9. S: Ri: a a p p’ qi qi’ a (p,q1,…,qi,…,qn) (p’,q1’,…,qi’,…,qn’) Multicast/broadcast communication in TA broadcast TA |||{S,R1,…,Ri,…,Rn}: 23 June 2003

  10. Team Automata vs. Petri nets • extension of I/O automata (Lynch + Tuttle, 1987) • to visualize potential concurrency in TA: switch to vector TA • VTA related to vector-labelled Petri nets, e.g. translation to Individual Token Net Controllers (Keesmaat et al., 1990): a particular type of state-machine decomposable nets • more details in paper and its references 23 June 2003

  11. TX The insecure communication scenario private send/receive TR TR TS TR public send public receive TIC TP TI eavesdrop inject (Lynch, CSFW’99) 23 June 2003

  12. (P) (P)     C C GeneralizedNon-Deducibility on Compositions   • P  GNDCiff X  : (P || X) \C (P) • A system specification P satisfies GNDC if the behaviour of P, • despite the presence of a hostile environment , • appears to be the same (w.r.t. a behavioural relation ) • as the expected (correct) behaviour of P • (Focardi-Martinelli, FM’99 & Focardi et al., ICALP’00) • D( ) bounded knowledge, communication channels, composition, hiding   (P) C || \  23 June 2003

  13. GNDC schema in terms of TA • Hostile environments: • C = { (Q, (out, inp, int), , I) | inp  C , out  C } • C = { X C | Idout (X)  (D())* } • Idout (X) = {   BT |   (out)*} • Observational behaviour: preserve symbolsext-com • OT= Id (pres (BT)) • com communicating actions • GNDC in terms of TA: hide actions C: unobservable • T  GNDC iff X  C : O OT  C ext–C ext-com  C C C hideC(|||{T,X}) 23 June 2003

  14. Conclusions • TA naturally suited to model multicast/broadcast communication • GNDC schema reformulated in terms of TA Future work • use this new setting for the formal verification of security properties for stream signature protocols 23 June 2003

More Related