OJO ¿NORMA DEROGADA?

With the integration of security into the Scopes Framework, the major concern was to preserve the distributed and modular capabilities of the framework. Therefore the integration focused on the scopes manager module and the application interface. This way it is possible to use all provided security measures independently from scenario specific modules like membership conditions or the routing. Keeping the interface to the routing modules eases the integration and supports the usability of scopes, as existing routing algorithms don’t have to be adapted and new algorithms just have to include the existing interface.

The changes to the task interface are also limited. The task registration was extended to supply the needed cryptographic keys for CP-ABE. An additional parameter was added to the scope creation to supply the access policy for the newly created scope. With these minor changes a task can utilize the full security functionalities of scopes.

The scopes manager module was subject to extensive changes. Besides the straightfor- ward interface changes described above, the management structures were extended to include management data for the encryption, namely CP-ABE keys, scope keys and sta- tus information. The data transmission was enhanced by an encryption and decryption mechanism. It ensures that, if a valid scope key is present, the sent data is encrypted using the available AES encryption in counter mode (AES-CTR) [30], which is obviously also used for decryption. Most changes were done in the scope creation and refresh mechanisms, as here the access control to a scope, scope key exchange and key re- fresh system are integrated. More details on the implementation are provided in section 4.3.2.1.

Performance is discussed in section 4.3, but some precautions for good performance can be taken in advance by introducing the following design decisions, especially as the computation of CP-ABE encryption and decryption is a major issue. To keep the compu- tational overhead to a minimum we trade it off for storage space. Since for each scope refresh the same encrypted scope key is disseminated (unless the key is refreshed) we store the decrypted scope keys in memory to save further computation costs. Addition- ally, the dynamic scope definition part is saved in plain text to simplify the repeated evaluation of the dynamic properties.

The following subsections will detail the newly added bootstrapping phase and the extended creation, maintenance and deletion phases.

3.4.1 Bootstrapping Phase

Bootstrapping is performed before the sensor node is deployed. In our scenario this would be before the container is shipped, e.g., while it is loaded with goods, informa- tion is updated on the node. First, the master key MK and the public parameters PK are generated at the trusted authority, if not already present. Then, a secret key SK is gen-

act SecScope Creation SecScope Enhancement SecScope Enhancement Scope creation request Drop message Add and j oin new

scope

Add new scope Reset scope timer Delete scope

«datastore» ScopesTable

(from SecScopes Manager Module)

«datastore» SubscriberTable

(from SecScopes Manager Module)

For the checks data from these tables is used.

Process Security

Process Security

[else] [Superscope known]

[Member of superscope]

[New scope: creation]

[Target task registered]

[Membership check passed] [Scope has dynamic properties]

[else]

[else] [Scope nested in superscope]

[Scope known: refresh]

[else]

[else]

[else]

[else]

[Membership check passed]

Figure 3.3: Scope Creation Workflow – Security Enhancements

erated for the container node with suitable properties. Here we would have properties like company or containerType or types of sensors that are available. The SK and PK are then stored on the node, ready for deployment. If the SK has to be installed on a node in an untrusted environment this may be achieved using ECDH [8] to establish a common key to encrypt the transmission.

This phase enables the establishment of a secure system in a trusted environment be- fore the network is deployed. After initializing security it is now possible to establish secure connections and apply the access-control mechanisms. As multiple tasks with different sets of properties are possible in a WSN, each task may get its own secure/pub- lic key pair. This is also important to support multiple trusted authorities, but occupies more resources. Through the task registration at the Scopes Framework the SK and PK are made available.

3.4.2 Creation Phase

The scope creation procedure remains mostly unchanged, see figure 3.3, but the SCR message is altered. Before, it was mainly the binary representation of the scope defini- tion, with some additional fields. Now there are two parts. First there is the encrypted scope key (encrypted with the specified access policy) for the symmetric encryption. And second, the dynamic portion of the scope definition and the additional fields encrypted with the scope key. The access policy reflects the static properties specified in the scope definition extended by static placeholders for the dynamic properties. This ensures that only nodes that can extract the scope key can access the full scope definition and so join the scope.

act Process Security

Extract CP-ABE cipher text

Store scope keys & key hashes

Select activ e key

Extract dynamic scope properties cipher text

Store dynamic scope properties Scope Creation Request Drop Message «datastore» ScopesTable

(from SecScopes Manager Module)

[Decrypt CP-ABE cipher text]

[Decrypt dynamic scope properties cipher text] [failiure]

[failiure]

Figure 3.4: Security Processing Workflow

3.4.3 Maintenance Phase

The scope refresh messages that are used to keep a scope alive are similarly struc- tured as the SCR, so they undergo the same changes. The simple scope refreshes that don’t contain any payload and just serve the purpose of keeping the scope alive are not changed. Additionally, the processing of an SR is extended by the scope key refresh mechanism. Here the IDs of the scope keys are added with the ciphertexts. This way

act SecScope Creation SecScope Enhancement SecScope Enhancement Scope creation request Drop message Add and j oin new

scope

Add new scope Reset scope timer Delete scope

«datastore» ScopesTable

(from SecScopes Manager Module)

«datastore» SubscriberTable

(from SecScopes Manager Module)

For the checks data from these tables is used.

Process Security

Process Security

[else] [Superscope known]

[Member of superscope]

[New scope: creation]

[Target task registered]

[Membership check passed] [Scope has dynamic properties]

[else]

[else] [Scope nested in superscope]

[Scope known: refresh]

[else]

[else]

[else]

[else]

[Membership check passed]

Figure 3.5: Scope Maintenance Workflow – Security Enhancements

it can be decided in advance if new scope keys are distributed and it is necessary to decrypt them. This is shown in detail in section 4.3.2.1.

3.4.4 Deletion Phase

The deletion of a scope is not allowed to be triggered from outside the scope. There- fore, the root node of the scope to be deleted encrypts the scope id with the scope key. This way all members of the scope can ensure that the deletion was triggered from an authorized node by evaluating the ciphertext. Deleting a scope from a scope member other than the root node is possible, but it does not allow a proper deletion of the scope, as only member nodes are reached that are children of the deleting node. The root node will refresh the scope that was deleted in the next cycle and reestablishes the scope. With the current architecture this cannot be efficiently prevented as every secret that the scope root may send to the scope members has to be known by the member.

act SecScope Data Send SecScope Enhancement Application message Forward to routing Drop message «datastore» ScopesTable

(from SecScopes Manager Module)

«datastore» SubscriberTable

(from SecScopes Manager Module)

Encrypt payload [else] [else] [else] [scope status is member] [scope known] [task registered] (a) Sending.

act SecScope Data Receiv e

SecScope Enhancement Scope data message Deliver to application Drop Message «datastore» ScopesTable

(from SecScopes Manager Module)

«datastore»

SubscriberTable

(from SecScopes Manager Module)

Decrypt payload

[else] [Task registered]

[else]

[else] [Scope known] [Member of scope]

[Creator of scope] [Message to root node] [else] [Message to members] (b) Receiving.

Figure 3.6: Scope Data Exchange Workflow – Security Enhancements

act SecScope Deletion SecScope Enhancement Scope deletion request Drop Message Decrypt Payload «datastore» ScopesTable

(from SecScopes Manager Module)

Delete Scope

[else] [Message from

root node]

[Superscope known] [Scope known] [Scope nested in Superscope]

[else]

[else]

[else]

[Plain text verified]

[else]

Figure 3.7: Scope Deletion Workflow – Security Enhancements

4 Evaluation

Contents

4.1 Testbed . . . 51 4.2 Scopes Framework . . . 53

4.2.1 SOS Operating System . . . 53

4.2.2 Contiki . . . 65