Building Security into Embedded Systems: Validating Theoretical Designs using Experimental Platforms

1. Building Security into Embedded Systems:Validating Theoretical Designs using Experimental Platforms Yuan Xue Institute for Software Integrated Systems Vanderbilt University A joint work with Matthew Eby, Janos Mathe, Jan Werner, Taojun Wu, Gabor Karsai, Sandeep Neema, Janos Sztipanovits, Akos Ledeczi

2. Outline • Introduction • Challenge • Approach • Two Projects • Experiment Platform for Model-based Secure Embedded System Design • Application-Driven Testbed for Wireless Sensor Network Security Analysis and Design

3. Introduction • Embedded systems • Low end: cellphones, PDAs, sensors, smartcards • High end: routers, home appliances • They are • Interactive with physical world • Pervasive in our daily life • Essential for national critical infrastructure • Currently embedded systems are migrating • From proprietary solutions to open standard • From standalone systems to networked environments Increasing concern of security threats in embedded systems

4. Challenge • Security solutions developed in the context of desktop-based operating systems and networks • Cryptography, • Secure network protocol • Etc. • Designing secure embedded systems faces unique challenges • Embedded system design is a systems-software co-design problem needs to meet cross-cutting requirements in terms of performance and physical constraints • Securing embedded systems involves more issues than what are addressed for desktop computing • Resource constraint • Development model and environment Applying existing security mechanisms as the additions of functional features is insufficient to secure embedded systems

5. Approach • Our approach • security consideration as an integral part throughout the design process, • security design to be validated over the software and system platforms. • This talk will present two experimental platforms • Plant control system • Wireless sensor network Secure embedded system design needs to be validated using the experimental platforms

6. Experimental Platform for Model-Based Secure Embedded System Design

7. Overview • Model-based Approach to Embedded System Design • Integrate Security into Model-based Approach • Experiment Platform Architecture • Demonstration System

8. Models facilitate formal analysis, verification, validation and generation of embedded systems Platform Model Functional Models Component Models Componentized Model Model-based Approach Source Files (e.g.: SimuLink, Hand crafted code, etc.) Composition Platform (e.g.: AADL) HW/SW Architecture (Windows, Linux) Deployment Model Generators (Interpreters)

9. Security policy Secure Componentized Model Secure Component Structure Model Deployment Model Platform Model Functional Model Component Model Security extension Security service Integrate Security into Models Source Files (e.g.: SimuLink, Hand crafted code, etc.) Security Extension examples • Role Based Access Control • Secure Links • Fair Exchange Secure Composition Platform (e.g.: AADL security extension) Hardware, OS service (e.g.: Kernel partition) Generators (Interpreters)

10. Advantages • Advantages to integrate security into model-based embedded system development • Introducing security at design level • Verifying required security properties using explicit security models • Consistent and automatic configuration of security services offered by the operating system • Investigating design tradeoffs between performance and security properties

11. An Example based on AADL • AADL (Architectural Analysis and Design Language • SAE Aerospace Standard (AS5506) • provide a standard interface and environment for system designers to model, analyze and generate embedded system code. AADLComponents AADLMetamodel

12. AADL Security Extension Security Extension Metamodel An example security mechanism Role-based Access Control • Objects – subject to access control • Operations – execution of some functions on objects • Permissions – approval to perform operation on RBAC protected object • Roles – job with assigned authority and responsibility • Users – human being, machine, network or agent requesting operation on objects

13. Existing Security Solutions Provided Different Platforms Theoretical Security Concepts (Platform Independent) Mapping between requirements and underlying capabilities ( Ideally requirements are the subset of the capabilities ) Security Capabilities of a Platform Security Requirements of a System Platform Security Service Modeling • Security Service Providers • OS (ex: Linux, LynxOS, WinCE) • HW (ex: Space Partitioning, Memory protection) • Services of different applications • (ex: Web Browser Based Authentication) • Partition in OS Platform Security Service Model -- Abstracts out security properties of the platform that are essential for the design flow Platform Security Models with sufficient detail enable Code Generators to access Platform Specific Security Services

14. AADL Execution Environment Application Software Component Application Software Component Application Software Component Application Software Component Application Software Component Application Software Component AADL Extended AADL API AADL Runtime System AADL Runtime System AADL Runtime System AADL Runtime System API OS Security Extension App App App Real-Time Operating System Real-Time Operating System Embedded Hardware Target Embedded Hardware Target Software Architecture with Security Extension

15. Embedded System Board Embedded System Board Embedded System Board Plant Simulator Data Acquisition Board (DAQ) 10/100BASE-T or 802.11b Experimental Platform Architecture The Plant Simulator acts as the physical environment in which the embedded system would run The Data Acquisition Board interfaces plant simulation with embedded system boards The embedded system boards run distributed control algorithms

16. Implementing Systems on Platform • The experimental platform facilitates “Hardware”-in-the-Loop testing of controllers. • High fidelity plant simulations behave just as the actual physical environment would. • Controllers can run on various operating systems with different security designs. • Code for controllers is generated based on security models for the embedded system

17. Embedded System Board Embedded System Board Embedded System Board Plant Simulator Data Acquisition Board (DAQ) 10/100BASE-T or 802.11b Putting things Together! Reference The process of AADL code generation Automatic Code Generation and Deployment

18. Results • Real-Time Simulation of Three Tank Fluid Transfer System • With I/O register protection only the tank control process has permission to write to I/O channels • Model-Based approach can map desired security properties to underlying platform services such as POSIX capabilities (e.g. CAP_SYS_RAWIO)

19. Application-Driven Testbed for Secure Wireless Sensor Network Design

20. Dirty Bomb Detection & Localization Stadium with Sensors Deployed Automatic Camera Feed Guard moves with an XSM Mote, tracked by RIPS technology Google Earth Illustration of Localization System ~12 Static XSM Motes (positions known )

21. Mote network Nextel/ Internet Internet Architecture Rad detector, mobile phone mote Tracking service and user interface Rad level servlet and camera glue code VGA to NTSC adapter Camera control node (Linux) Jumbotron controller

22. Mote network Nextel/ Internet Internet System Vulnerabilities Sensor network vulnerabilities • Bogus tracking results • Tracking command • Spoofing • Battery consumption • attack Tracking service and user interface Rad detector, mobile phone mote Application/Service Rad level servlet and camera glue code • Packet dropping • Mis-forwarding • ID spoofing • Forging routing • Information • Disclosing/modifying • /replaying tracking results VGA to NTSC adapter Camera control node (Linux) Jumbotron controller Network • MAC DoS • Eavesdropping Traditional network/system vulnerabilities Mac/Link • Denial of Service Attack • Information disclosing/modification/replaying • Address Spoofing • etc.. • Jamming Physical

23. Security Issues in Sensor Networks Mechanisms Security Issues User Authentication Application /Service User ID spoofing Msg Auth Code Release/modify content Encryption forwarding Drop/forward to wrong neighbor Secure Routing routing Forge routing information addressing Source Authentication Address spoofing Network Link Level Encryption Eavesdropping Mac/Link MAC DoS Attach Detection Physical Jamming

24. Peer Authentication Scheme • Objective • Provide efficient, effective, and flexible peer sensor authentication • Basic Idea • Symmetric-key based (SkipJack in TinySec) • Each sensor node has a different set of keys through a pre-key distribution scheme • Multiple MACs are generated for each message from a sensor node • MACs are verified at the receiver sensor using its common keys with the sender

25. Sensors A, B, C, D have different combination of overlapping keys: A: 1, 4 B: 1, 2 C: 2, 3 D: 3, 4 1 A B 4 2 D C 3 A Simple Example Sensor A pretends to be C, appends message authentication code (generated with key 1 & 4) to outgoing messages B I am C C A B You are not C, since you don’t have key 2 You are not C, since you don’t have key 3 D C I know you are not me. D C C

26. Implementation and Results • We implement the peer authentication scheme as a component (MultiMAC) under TinyOS (based on SkipJack in TinySec) • Measurement Results • Computation time: 5.3 ms; • Verification time: < 0.1 ms, 1.3~1.4 ms or 2.5 ms, if receiver has 0, 1 or 2 keys in common with sender. • Demonstration Video • Windows Media

27. Summary • Security is an increasing concern in embedded system design • Using a model-based approach, security can be considered as an integral part through design process • Experiment platforms are critical to validate security designs

28. Thank you very much! Questions?