IHP Im Technologiepark Frankfurt (Oder) Germany IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved A Middleware Approach to Configure Security in WSN Peter Langendörfer Steffen Peter, Krzysztof Piotrowski, Renato Nunes, and Augusto Casaca

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Outline Background & Motivation Middleware Compiler Middleware Architecture Conclusions

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Background & Motivation

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Background: Application Scenarios

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Transport Network MAC Sensor OS Apps complete jamming, selective/partly jamming, eavesdropping, replay attacks invasive attacks, semi- invasive attacks, non- invasive attacks exploiting backdoors, buffer overflows, remote node programming, direct programming, denial of service attacks sensed data injection, access sensed data, service disruption, etc. routing loop, black hole grey holes, wormhole, injecting, network partitioning, etc tamper with sensor, falsified sensor reading 1.UbiSec&Sens Contribution of Security solutions for… - Middleware Security - Sensor measurements - Transport, Network, MAC eavesdropping, man-in-the- middle, replay, spoofing send erroneous data, inject wrong control packets, send changed data, duplicate data, eavesdrop HWRF Middleware Background: WSN Security Tomography

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Background: Security the Centre of Gravity key pre- distribution security reliability & routing & in-network processing authentication “re-recognition” concealed data aggregation secure routing routing & aggregator node election secure distributed data storage data plausibility discrepancy query reliable transport transport WSN access secure aggregator node election Secure DCU WP1 – Networking WP2 – Network Security WP3 - Middleware & Middleware Security

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Compiler

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Compiler Concept Tailor made security architecture for WSN applications Result could be part of a more general middleware Result can be specific for a certain application Determination of the configuration Offline (before deployment) Online (after deployment)

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Module interdependencies Secure & robust data storage Resilient data aggregation alg_1 Resilient data aggregation alg_2 CDA_alg1 CDA_alg2 CDA_alg3 Complex services Sec. routing_1 Sec. MAC_1 Sec. routing_2 Sec. MAC_2 Protocols Sec. random generator Sec. localization AES ECC RSA DESTEA Basic services Transport_prot_2 implicit dependencies explicit dependencies

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved UbiSec&Sens Project Overview concealed data aggreg. sec. distr. data storage plausible and resiliant Efficient impl. of crypto means. Key pre- distribution secure routing synchronous/ asynchronous UbiSec&Sens Toolbox strong security Homeland Vehicular Agriculture weak security Application areas Middleware Basic & complex services Selection and config. of security means Query language API DCU

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Tool Box development phase Application development phase Development Phases Application Requirements SensorNode Description configTOOL USS Toolbox Influences selection Selection of components legend USS Module Description Application deployment phase Tailor made Software configuration

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Providing customized security architectures Sec. random generator Sec. localization AES ECC RSA DES TEA Sec. rout_1 Sec. MAC_1 Sec. routing_2 Sec. MAC_2 Sec. robust data storage Resilient data aggregation alg_1 Resilient data aggregation alg_2 CDA_alg1 CDA_alg2 CDA_alg3 Application Sensor node HW OS AES ECC Sec. routing_1 Sec. MAC_1 Resilient data aggregation alg_1 CDA_alg2 Sec. robust data storage Secure local. Req. Configuration and Management Module 1.Req. vs features of modules 2.Interoperability of modules 3.Security of combination Tailor made security architecture Application

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Compiler Operation Compiler Input Required functions: Functionality needed by the application Available modules: dependencies, interface description, security parameters, code size, etc.. Compiler Operation 1.Construct all module selections that fulfil the application requirement (functional) 2.Select module configuration based on constraints such as code size of modules, supported key length etc. 3.Final Evaluation: selection of best alternative: apply additional parameters like energy consumption, total code size, performance, security implications

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Selection of Modules ECC Sec. rout_1 Sec. MAC_1 CDA_alg2 Sec. robust data storage Secure local. ECC Sec. routing Sec. MAC CDA Sec. robust data storage Secure local. Alg_1 Alg_2 Alg_3 Public key crypt. RSA Alg_1 Alg_2 Alg_1 Alg_2 Application constraints Hardware constraints Performance constraints M iddleware compiler Available security modules selected security modules

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Simple Example: Authentication

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Example Application needs ‘Asymmetric Cryptography’  Possible configurations: 1.ECEG with hardware ECC and classic pseudo RNG 2.ECEG with hardware ECC and cipher stream RNG 3.ECEG with software ECC and classic pseudo RNG 4.ECEG with software ECC and cipher stream RNG -RSA? Real RNG? No implementation

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Module Description XML description Every module is an entity Attributes: -Implementation Is 1 if it is an implementation, 0 if it is an interface - Optional tag says which module is the parent of the entity. Entity inherits the interfaces from parents ECEG is ‘Asymmetric Cryptography’ ECC Software is (an implementation of) ECC - Optional list of and tags ECEG requires ECC - Additional attributes Code size, security degree, energy consumption

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Module Description– Example Asymmetric Cryptography ECC RNG Asymmetric Cryptography ECC ECC co-processor ECC

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Architecture

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Architecture Set up is role dependent: sensor node vs. configuration center Application dependent services Basic services Complex services Abstraction layer Communication interface Memory Management Interface Middleware Core: Dynamic code update module State management module Message interpreter Core is unique on all sensor nodes

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Architecture Currently Deployed Complex Services (Task 3.2; WP1; WP2) MessageIF (T. 3.4) DCU (T3.5) Configuration center Currently Deployed Complex Services Currently Deployed Basic Services Node&Network State Management MessageIF DCU Hardware&OS Abstraction Layer OS Hardware Sensor node Currently Deployed Complex Services MessageIF Application Logic DCU Currently Deployed Basic Services

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Core DCU Reconfiguration of sensor nodes during their lifetime Provides functionality for secure code update (AA Stuff) Potential triggers newly detected vulnerabilities of security modules or simple reconfiguration due to deployment of new applications. State Management Module (SMM) Monitoring of the sensor node and maintaining its state Triggering code updates e.g. in case of expiration of timers detection of malicious actions.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Core Message Interpreter local intelligence to decide handling of incoming messages e.g. answering vs. forwarding middleware scheduler which passes incoming data to the corresponding modules.

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved External triggers for online reconfiguration Collecting data processing data Sending data Sensor readings Min # data Processing done sending done M2: normal operation Extreme strange data Extreme strange network behaviour Analysing abnormal behaviour M3: Management additional code needed Attack running DCU Counter measures no influence on other nodes M1: Network set-up Set-up finished Request new configuration influence on other nodes

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Middleware Architecture: online configuration Currently Deployed Complex Services (Task 3.2; WP1; WP2) MessageIF (T. 3.4) DCU (T3.5) Configuration center Currently Deployed Complex Services Currently Deployed Basic Services (T3.1) Node&Network State Management MessageIF DCU Hardware&OS Abstraction Layer OS Hardware Sensor node Currently Deployed Complex Services MessageIF Application Logic DCU Currently Deployed Basic Services configKIT USS Toolbox Rep. WSN Config MAP WP1; WP2; WP3; New config needed

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved Conclusions Summary Midleware Compiler New concept towards “simple” security architectures for WSN Middleware Architecture Support of on the fly patches of security configuration Current state XML “languages” for description purposes nearly finalized GUI for description of modules, sensor nodes & requirements partly done Next steps Finalization of selection algorithms Investigation of assessment functions for complete configuration Implementation of algorithms

IHP Im Technologiepark Frankfurt (Oder) Germany © All rights reserved THANK YOU for your attention Questions?