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