The five security models presented in this chapter are the result of a new methodology to deduce practical models from a general security ontology.
The notion of this approach is –as first step– to reduce the complexity of the model by focusing on specific views on the ontology. The views on the ontology provide a good abstraction and allow to explain security properties. As second step, the specific views were further refined with focus on deduction of requirements and composability in the component model which finally can be integrated as security models in configKIT.
Applying this process and using the security ontology for WSNs we could identify three views:
The Countermeasure-centric View, which assesses the security of a system based on the countermeasures the system possesses.
The Attack-centric View, which assesses the security of a system based on the resis-tance against attacks.
The Vulnerability-centric View, which evaluates the system on the existence of vul-nerabilities needed for the attacks.
Based on these views, five specific practical security models were derived:
• A Quality-based Countermeasure-centric Security Model (QCSM)
• A Feature-based Countermeasure-centric Security Model (FCSM)
• A generic Attack-centric Security Model (GASM)
• An Attack Tree based Attack-centric Security Model (ATASM)
• A generic Vulnerability-centric Security Model (GVSM)
The two models for each the attack and countermeasure view exemplify that the same view can be implemented differently. For countermeasures one model uses explicit features, while QCSM applies qualities. The difference is that users typically can express the required security qualities (as in QCSM) but do not know which security features are needed as it is needed for FCSM. On the other side the assessment logic needs to be significantly more sophisticated if precise qualities should be derived, instead of rather tangible features as for FCSM.
The technically most advanced approach is the vulnerability-centric security model (GVSM). It internally decomposes full attack trees and the vulnerabilities needed for the attacks. Then the feasibility for the exploitation of the vulnerabilities is evaluated based on the composed system. Finally a system is secure if no combination of vulnerabilities can be found that can be exploited for a successful attack in the given scenario.
Even though the five models at the end differ significantly, they still represent the initial security ontology.
In order to evaluate the practical value a thorough evaluation of the implemented models is given in the next chapter.
Chapter 7
Secure In-Network Aggregation as Case Study for configKIT
In-network aggregation (INA), introduced in Section 4.5, is a valuable mechanism to reduce energy consumption in WSNs. However, INA has several security concerns as discussed in that section. The basic problem is that nodes in WSNs cannot necessarily trust their neighbors or the aggregating nodes. That is a particular issue if – as it is the case for INA – the neighboring nodes are assigned with the task to aggregate the sensitive data. Concealed Data Aggregation [GWS05] is a means facilitating data aggregation on nodes that do not necessarily know the content of the data they are computing. The mathematical concepts as well as the benefits and potential drawbacks are complex and not easy to understand.
In this chapter the feasibility of configuring secure INA by means of configKIT and the proposed security models is investigated. Therefore, first, reference data for the six design options of INA are gathered by implementing the approaches in a modular way and simulating the resulting applications. While this integration process is executed manually, the modular implementations with the well-defined interfaces are basis for an automatic integration process later in the design process.
The major focus of this chapter is on the integration and evaluation of secure INA in configKIT. As first step it requires a general integration of the WSN application and the INA components in the configKIT framework. Then the security models presented in the previous chapter are applied to model the security attributes of the INA components.
Configuration test runs provide test results that eventually allow to evaluate the results.
The practical tests demonstrated that the configKIT framework is able to control the configuration the secure INA. The tests further validated that all investigated security models deliver reasonable results.
7.1 Experiment Setup
In this section the general test setup and the considered INA algorithms and their param-eters are defined. The test setup is basically a multi-hop star network topology with one sink. We will use this topology in the simulation later in this chapter to measure the
foot-Figure 7.1: Topology of the simulated test network. Red is the base node, blue are aggregation nodes and green are data-providing sensor nodes.
prints of the INA algorithms in practice. The topology is also the network background for the exemplary user selection process discussed at the end of this chapter.
The test environment simulates 85 nodes:
• 1 sink (base station)
• 4 first level aggregation nodes
• 16 second level aggregation nodes (4 for each first level aggregator)
• 64 actual sensors/data provider (4 for each second level aggregator)
The topology of the network is shown as Figure7.1. For this network an INA application should be deployed. The design options are the INA algorithms discussed in Section4.5 The following description lists the investigated INA approaches and briefly introduces key aspects and chosen parameters, including the origin of the source codes.
No INA an Implementation without In-Network Aggregation for comparison. It does not provide any encryption. The used source code was written by us.
INA without encryption is an In-Network Aggregation without cryptography. The used source code was written by us.
Hop-by-Hop (HbH) is an INA that transmits encrypted data over the radio but de-crypts the data on each aggregation node to perform the aggregation. The used source code was written by us, the applied stream cipher was taken from [KSW04].
CMT is the CMT privacy homomorphism (PH) implementation with (4 bytes) 32 bit data value The used source code is from the original authors of the algorithm [CMT05].
Domingo-Ferrer (DF) is the Domingo-Ferrer PH implementation with the parameters D=2 and M=32768. The used source code is from the authors of [GWS05]
Hybrid CDA (hCDA) is the hybrid implementation with DF (D=2, M=32768) and CMT (16 bit). The combining source code was written by us.
The initial situation can be stated as follows: We have a network and a task and we are looking for the best algorithm that forwards the aggregated values from the sensor nodes to the sink. We are not interested in the precise sensor readings but in an average value, i.e. the sum of the single readings and the number of values.
With respect to the evaluation of the configKIT approach we are interested in the following results:
• Is automatic evaluation possible at all?
• Is security assessment reproducible and reasonable?
• Are the technical parameters reasonable and correct?
• How much overhead is required to describe the model?