Upload
dominh
View
223
Download
5
Embed Size (px)
Citation preview
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