160 likes | 286 Views
Delay Aware, Reconfigurable Security for Embedded Systems. Tammara Massey 1. Foad Dabiri 1. Philip Brisk 2. Majid Sarrafzadeh 1. 1. 2. Outline. ECG Application Security in BANs Related Work Dynamic Security System (DYNASEC) Conclusion. 1/15. Body-Area Network Application.
E N D
Delay Aware, Reconfigurable Security for Embedded Systems Tammara Massey1 Foad Dabiri1 Philip Brisk2 Majid Sarrafzadeh1 1 2
Outline • ECG Application • Security in BANs • Related Work • Dynamic Security System (DYNASEC) • Conclusion 1/15
Body-Area Network Application • Electrocardiogram (ECG) Sensor • Large bandwidth requirement • Parallel transmission of many waveforms • Environmental interferences • Patient movement • Respond to anomalies • Activate drug delivery mechanism • Based on SQRS Algorithm [Pino et al., ’05] • ECG waveforms • May misclassify features due to noise • Addressed via moving threshold with independent values • Extra noise classification removed to reduce code size 2/15
Security in Body-Area Networks • Health Insurance Portability and Accountability Act (USA) • “… ensure integrity and confidentiality of information” • “… protect against reasonably anticipated threats or hazards to the security of integrity of the information” • Security-Processing Gap [Ravi et al., ’03] • Exacerbated for body area networks • Limited Memory • Battery lifetime • Bandwidth 3/15
Related Work • TinyPK [Watro et al., ’04] • Authentication and key exchange via RSA encryption • TinySec [Karlof et al., ’04] • Link-layer security for wireless sensor networks • Authentication, Skipjack/RC5 encryption • Elliptic curve cryptography on motes [Malan et al., ’04] • DYNASEC: adds reconfigurable element to security 4/15
Dynamic Security System (DYNASEC) • Normal operation • High security all around • Anomaly detected • Hard real-time requirements • Reconfiguration to meet the deadline • Dynamically change security levels • Throttle packet size 5/15
DYNASEC System Design • Sensor Operating System (SOS) [Han et al., ’05] • Message Integrity Code (MIC) • Encryption (is optional) • Skipjack, RC5 implemented in SOS kernel • Memory requirements • Original – 17% of Mica2 mote memory • Modified – 39% of Mica2 mote memory • Encryption algorithms have large data segments 6/15
Four Security Levels • L0 – No Security • L1 – MIC Authentication + No Encryption • L2 – MIC Authentication + Skipjack Encryption • L3 – MIC Authentication + RC5 Encryption • RC5 is faster and stronger than Skipjack • Pre-computed key schedule consumes 2.6% of Mica2 mote memory 7/15
Security Cost Packet size (bytes) 8/15
Dynamic Security Allocation • Network organized as a directed ayclic graph (DAG) • Sink is a centralized node with more processing power than other nodes • In response to anomaly redistribute security levels • Integer Budgeting Problem on a DAG • Model as Linear Program • Solve LP (CPLEX) on centralized node • Relax to nearest integer solution • If no solution is available • Reduce the packet size and try again 9/15
Budgeting Problem Formulation • Given: Hard-timing constraint for communication • Maximize: Aggregate security of all motes in the DAG • Subject to the following constraints • Exactly one security algorithm assigned to each mote • Each source-to-sink path satisfies the timing constraint • For each link: • The flow of packets sent into each link does not exceed the link capacity • For each internal mote: • The flow of outgoing packets is equal to the flow of incoming packets 10/15
Pragmatic Issues • Propagation time from centralized node to other nodes is non-negligible • Only run the algorithm if there is at least a 15% change in link quality • Can re-use the old solution for repeated anomalies • If there is a change… • Nodes make temporary local decisions for the best routing path… • Link quality used to choose next hop • Modifies security level • Lower if it cannot achieve desired throughput • Higher if it exceeds desired throughput • Until the centralized node propagates its solution 11/15
Experimental Setup • Randomly generated network • Simulation on Avrora [Titzer et al., ’05] • 10 nodes or less (for now) • Runtime of LP solver doesn’t scale • 3 Types of Links • Well-connected • 20% of packets dropped • Lossy • 50% of packets dropped • Very lossy • 80% of packets dropped 12/15
Evaluation • Small Network (10 nodes or less) • Reasonable for today’s body area networks • LP converges in approximately 1.5 ms, on average • Does not include time to propagate solution to the nodes in the network • Establishes feasibility of the approach • Will not scale for larger network • Must solve budgeting problem in distributed fashion 13/15
Conclusion (1/2) • Security-Processing Gap • Exacerbated for BANs • Limited memory • New cryptographic algorithms are needed • Smaller code/data segments • Approximately 11% of mote memory, per algorithm, could be improved • Configurability • Allow the user to select a tradeoff between runtime and cipher quality 14/15
Conclusion (2/2) • Anomalies Hard real-time constraints • DYNASEC reconfigures security levels in response • Security allocation is a budgeting problem • Solved using LP-relaxation on centralized node • Future work: solve the problem in distributed fashion on the motes • Increase emphasis on throttling packet size 15/15