TWISNetTrustworthy Wireless Industrial Sensor Networks

Trustworthy Security Framework for Trustworthy Security Framework for

Wireless Industrial Sensor Networks

Laura Gheorghe

University Politehnica of Bucharest

TWISNet

Testbed providing the proof-of-

concept that effective security is

ensured in the WSN

The objective of TWISNet is to develop a platform supporting

the integration of sensor networks in a secure, efficient and

www.TWISNet.eu slide 2

Security framework

implementation for home

and industrial use

Produce network protocols,

architectures and middleware

reliable way, considering the strong technical constraints of

sensor networks.

Scenarios

Scenario 1: Sensors attached to a person moving from PAN to PANe.g. gathering of medical data in dangerous environments while moving between buildingsChallenges: privacy, secure authentication; integrity; anonymization

Scenario 2: Sensor networks for supply and demand optimizatione.g. smart meters/smart grid enable two-way communication between the nodes and the energy provider for demand optimizationChallenges: confidentiality-protected data; physical attacks;

secure remote update; integrity; authentication of commands

www.TWISNet.eu slide 3

secure remote update; integrity; authentication of commands

Scenario 3: Sensors networks for monitoring and control of industrial processese.g. sensors used to create and monitor a temporary exclusion zone in an industrial processChallenges: privacy; secure authentication; integrity; anonymization; availability

Scenario 4: Multi-owner sensors networkse.g. a sensor network in a (i.e. chemical) plant interconnects with sensor networks in the surroundingChallenges: traceability of the data; physical attacks

(outside sensors); admission control for screening of external sensors

External sensor

network

Chemical plant

infrastructure

Interconnection

Interconnection

Interconnection

Security Levels

Lvl Confidentiality Cryptography Trust0 No confidentiality None All entities in E2E-path

trusted

1 H2H security Symmetric All hops have to be

�Security level selected according to requirements and resources

� Different services can have different security levels

e.g. key exchange requites level 4 but data transport level 1

www.TWISNet.eu slide 4

1 H2H security Symmetric All hops have to be

trusted (WSN, ML)

2 E2E security from WSN to ML

(ML has access to plain data)

Symmetric Trusted ML

3 E2E security from WSN to EUC Symmetric, not homomorphic,

complex key distribution needed

No complex trust

requirements

4 E2E security from WSN to ML

(ML has access to plain data)

Asymmetric Trusted ML

5 E2E security from WSN to EUC Asymmetric, not homomorphic No complex trust

requirements

6 E2E security from WSN to EUC Asymmetric, homomorphic No complex trust

requirements

� Performs in-network evaluation of data trustworthiness

� Runs on Routing-nodes

� Includes two main building blocks:

� Invalid Packet Detection

� Trust and Reputation Mechanism

� Invalid Packet Detection (IPD):

� Stores a number of packets

� Classifies packets based on spatial or temporal correlation

� Verifies their validity based on the spatial and temporal correlation algorithms

Data Trust Evaluation

� Verifies their validity based on the spatial and temporal correlation algorithms

� Forwards only valid packets

� Generates alerts in case of invalid packets

� Trust and Reputation Mechanism (TRM)

� Includes 3 phases of operation (Learning, Exchange, Updating)

� Experience is adjusted based on the Detection Experience

� Neighbors exchange Experience values

� Reputation is adjusted based on the Direct and Indirect Experience

�Trust is adjusted based on Reputation

�Sends trust values to the Trust Center - used for excluding untrustworthy nodes

Data Trust Evaluation (2)

Data Trust Evaluation (3)

�Server side

�Analyzes data from the nodes

�Computes and analyzes statistical data

�Uptime, number of messages sent/received by a node, average and

median variances of the data, growth rate of the data, estimated battery

power left.

�Alerts an administrator if abnormal behavior is detected

�Via the Event Trigger Agent (ETA)

�Sends message to the sensor-side module if actions need to be taken

Failure and Abnormal Behavior

Detection (FABD)

�Sends message to the sensor-side module if actions need to be taken

�Sensor side

�Sends sample data to the server side FABD for analysis

�Sends the analysis results to the Sensor Failure Management module

Failure and Abnormal Behavior

Detection (FABD) (2)

Ongoing work

Development stage

Failure and Abnormal Behavior

Detection (FABD) (3)

� Alerts on exceeded thresholds

� Prediction of battery state

� Alerts on high average / median variance between reported node values

� Alerts on high growth rate of node data over a fixed period of time

Failure and Abnormal Behavior

Detection (FABD) (4)

�Responsible with monitoring node parameters:

�Allows authorized users to view or modify node configuration

�Through a web interface provided by the Sensor Co-Management

�Provides the mechanism for reading/writing configuration on node

�Authentication and authorization is handled though SCM

�Monitored parameters:

�Stack (PHY, MAC, ...) parameters: channel, scan duration, PAN ID

�Application parameters: update interval, sink location

�Module specific parameters

Software Mechanisms for

Device Reconfiguration

�Module specific parameters

�It has 3 components:

�SMDR-node: collects and updates parameters on the nodes

�SMDR-G: runs on the network gateway and transfers commands and data

between wireless domain (SMDR-node) and wired domain (SMDR-AS)

�SMDR-AS: run on the application server and communicates with SCM database

for updating parameters

�Supply/demand and multi-owner scenarios would benefit especially from remote

reconfiguration as they imply wide area deployment

Software Mechanisms for

Device Reconfiguration (2)�Topology

�Two nodes connected directly to

the gateway

�Running SMDR-node and

SMDR-G

�Test parameters

�Voltage (0x00)

�Temperature (0x01)

�Parent (0x02)

N1

N2

G

�Parent (0x02)

�The SMDR-G sends periodically

parameters to SMDR-AS

�The SMDR-AS stores received

parameters in the SCM database

Software Mechanisms for

Device Reconfiguration (3)

�Debugging output from

SMDR-AS

�Received parameters

are stored in SCM

database

�SCM web interface

�Users with appropriate

permissions can view

collected parameters

�Mediates the communication between the sensor network and the users

�Grants users access to:

�Measurement data

�Node parameters (SMDR)

�Displays data:

�Measurement data

�Parameter values

�Other parameters/statistics from other modules

�Access is granted based on read/write permissions:

Sensor Co-Management

�Access is granted based on read/write permissions:

�A user receives access to a type of sensor data from a group of nodes

�Mediation is done through a database

�Is relevant to the Multi-Owner Scenario

�Owner has access rights to their nodes

�3rd parties can have access depending on policy

�User can have access to only part of the information gathered by some nodes

�Can handle multiple groups of nodes and multiple users

Sensor Co-Management (2)

�Policy specifies:

�Group of sensor nodes

�Type of sensor data

�Supply-demand scenario

Sensor Co-Management (3)

�We designed 4 main industrial scenarios

�We developed a modular security framework

Conclusions

www.TWISNet.eu slide 18

This work is supported by the EC under grant agreement FP7-ICT-258280 TWISNet project.

�We developed a modular security framework

�Most of our modules are in testing phase

�Next step: integrating them into the scenarios