collabs-d3.1 v0.8

D3.1 The COLLABS Level-2 Security Package for

Resilience in Smart Factories: MVP Project number: 871518 Project acronym: COLLABS

Project title: A COmprehensive cyber-intelligence framework for resilient coLLABorative manufacturing Systems

Start date of the project: 1st January, 2020 Duration: 36 months Programme: ICT-08-2019

Deliverable type: Report Deliverable reference number: DS-01-871518/ D3.1 Work package contributing to the deliverable: WP3

Due date: 23rd DEC 2020 – M12 Actual submission date: 23rd December 2020

Responsible organisation: TSG

Editor: Wafa BEN JABALLAH, PhD. Cyrille Martins

Dissemination level: PUBLIC Revision: V0.8

Abstract:

This document provides a clear description of the COLLABS level-2 security components. In particular, it describes fine-grained authorization for constrained environments, relying on distributed ledger technologies for exchanges between different involved mechanisms. We show how COLLABS ledger-based security modules can secure inter-device

Ref. Ares(2020)7901315 - 23/12/2020

The project COLLABS has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 871518.

communications and enhance the trust level in inter-device collaboration, on several aspects of the Smart Factory lifecycle. We describe how COLLABS ensures that all the data collected from connected objects, and all the actions are authorized following an effective security policy. This document also illustrates the main data flows with sequence diagrams, describing and visualizing processes involving each MVP component, as well as mapping of COLLABS level-2 security components to the use case scenarios.

Keywords:

Fine Grained Authorization, Attribute based Access Control, Attribute based Encryption, Attribute based Decryption, Hyperledger Fabric, Public Key Infrastructure, Optiga TPM, Smart Contracts

D3.1 - The COLLABS Level-2 Security Package for Resilience in Smart Factories: MVP.

COLLABS D3.1 Page III

Editor

Wafa BEN JABALLAH,

Cyrille Martins

Contributors (ordered according to beneficiary numbers)

FOUNDATION FOR RESEARCH AND TECHNOLOGY HELLAS, FORTH INFINEON TECHNOLOGIES AG Advanced Laboratory on Embedded Systems SRL, ALES University of Novi Sad Faculty of Sciences, UNSPMF Sphynx Technology Solutions AG, STS Renault SAS, REN Harokopio University, HUA

Document Revisions & Quality Assurance

Internal Reviewers

1. HUA 2. STS

Revisions

Version Date By Overview

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

06/10/2020

04/11/2020

18/11/2020

27/11/2020

01/12/2020

04/12/2020

20/12/2020

23/12/2020

TSG

TSG, IFAG, UNSPMF

ALES, TSG, IFAG, UNSPMF

IFAG, ALES, TSG

TSG, IFAG, REN, ALES

TSG, IFAG, ALES

STS, HUA, TSG

STS, HUA, TSG

ToC

First Round of Inputs

Second Round of Inputs

Third Round of Inputs

Consolidated Version

Review Version

Consolidated Version after first review

Reviewers comments integration

D3.1 - The COLLABS Level-2 Security Package for Resilience in Smart Factories: MVP.

COLLABS D3.1 Page IV

Disclaimer

The information in this document is provided “as is”, and no guarantee or warranty is given that the information is fit for any particular purpose. The content of this document reflects only the author`s view – the European Commission is not responsible for any use that may be made of the information it contains. The users use the information at their sole risk and liability.

D3.1 - The COLLABS Level-2 Security Package for Resilience in Smart Factories: MVP

COLLABS D3.1 Page V

Executive Summary This deliverable provides an overview of the main level-2 security components in COLLABS. In particular, COLLABS offers fine-grained authorization for constrained devices, distributed ledger technologies supported by public key infrastructures. It relies on distributed ledger mechanisms for data exchange between different actors in the system. To do that, we leverage Attribute based Encryption (ABE), where encryption and decryption keys are based upon entities’ attributes. Using this technique, we show how devices can protect the data they produce by encrypting in ABE using given attributes. A client that wants to consume such data will have to request an authorization service for an ABE decryption key.

Furthermore, the deliverable details how the smart contracts will be involved for data exchanges among the system entities using HyperLedger Fabric, the IoT Certification Authority, and the public key infrastructure, while also leveraging the Optiga TPM as a hardware security module.

We provide for each component its description, the pre-conditions, the post-conditions, including the list of its interaction components. We describe the MVP components as well as the planned ones for the next releases. Furthermore, we provide the security requirements that need to be covered. This document presents also the processes involving security components for the MVP as well as the mapping of the level-2 security components to the COLLABS use cases.


COLLABS D3.1 Page VI

List of Abbreviations

Abbreviation Translation

MVP Minimium Viable Product

ABE Attribute Based Encryption

IoT Internet of Things

CA Certification Authority

FGA Fine Grained Authorization

ABAC Attribute-Based Access Control

ECSO European Cyber Security Organisation

PDP Policy Decision Point

CP-ABE Ciphertext-Policy Attribute Based Encryption

KP-ABE Key-Policy Attribute Based Encryption

CSR Commun Security Requirement

IAM Identity Access Management

PEPs Policy Enforcement Points

PKI Public Key Infrastructure

TRNG True Random Number Generator

HSM Hardware Security Module

TTP Trusted Third Party

MRO Maintenance, Repair, and Overhaul


COLLABS D3.1 Page VII

Contents List of Abbreviations ............................................................................. VI

1. Introduction .................................................................................... 12

2. Level-2 Security Components for Resilience in Smart Factories .................. 13

2.1. Architecture ................................................................................. 13

2.2. Protocol Execution ......................................................................... 15

3. Security Component Description .......................................................... 17

3.1. Comprehensive Access Control ........................................................... 18

3.1.1. Overview ....................................................................................................... 18

3.1.2. Fine-Grained Authorization encryption module ........................................................ 19

3.1.2.1. Functional Description ............................................................................. 19 3.1.2.2. Component Identity Form ......................................................................... 19

3.1.3. Fine-Grained Authorization decryption module ........................................................ 20


3.1.4. Message Broker (centralized) .............................................................................. 21


3.1.5. Post-MVP Components ....................................................................................... 22

3.1.5.1. Fine-Grained Authorization server............................................................... 22 3.1.5.1.1. Functional Description ........................................................................... 22 3.1.5.1.2. Component Identity Form ....................................................................... 22

3.1.6. Requirements ................................................................................................. 23

3.2. Blockchains and Inter-Ledgers ........................................................... 26

3.2.1. Overview ....................................................................................................... 26

3.2.2 Hyperledger fabric ............................................................................................ 27


3.2.3. IoT CA........................................................................................................... 29



COLLABS D3.1 Page VIII

3.2.4. Hash Message Broker......................................................................................... 30


3.2.5. Blockchain-based supply chain management system .................................................. 31

3.2.5.1. Functional Description .......................................................................... 31 3.2.5.2. Component Identity Form ...................................................................... 32

3.2.6. Post-MVP Components ....................................................................................... 34

3.2.6.1. ABE key provider .................................................................................... 34 3.2.6.1.1. Functional Description ........................................................................... 34 3.2.6.1.2. Component Identity Form ....................................................................... 34

3.2.6.2. Policies Server ...................................................................................... 34 3.2.6.2.1. Functional Description ........................................................................... 35 3.2.6.2.2. Component Identity Form ....................................................................... 35

3.2.6.3. Revocation list ...................................................................................... 35 3.2.6.3.1. Functional Description ........................................................................... 35 3.2.6.3.2. Component Identity Form ....................................................................... 35

3.2.7. Requirements................................................................................................ 36

3.3. Public Key Infrastructures ................................................................ 37

3.3.1. Overview ....................................................................................................... 37

3.3.2. Optiga TPM .................................................................................................... 38


3.3.3. Requirements ................................................................................................. 39

3.4. Confidential Data Discovery .............................................................. 41

4. Processes involving Level-2 Security Components .................................... 43

4.1. Fine-grained access control over sensors’ data ....................................... 43

4.1.1. Authorization configuration by the sensors’ owner ................................................... 43

4.1.2. Data protection with authorization by a sensor ........................................................ 44

4.1.3. Authorized data access by a client ........................................................................ 45

4.1.4. Blockchain based supply chain management system ................................................... 46

4.1.5. Blockchain Public Key Infrastructure (IFAG) ............................................................ 47

4.2. Mapping COLLABS Level-2 security components ...................................... 48

4.2.1. ALES use case ................................................................................................. 48


COLLABS D3.1 Page IX

4.2.2. REN use case................................................................................................... 49

4.2.3. PCL Use Case .................................................................................................. 50

5. Summary and Conclusion .................................................................... 52

Bibliography ....................................................................................... 53


COLLABS D3.1 of 53

List of Figures Figure 1: Blockchain based Fine Grained Authorization System ................................................ 14

Figure 2: Fine-grained authorization using attribute-based encryption ...................................... 19

Figure 3: Diagram of Hyperledger Fabric from ..................................................................... 28

Figure 4: Supply chain to blockchain mapping ..................................................................... 32

Figure 5: Confidential data discovery - internal structure ...................................................... 41

Figure 6: Sequence diagram of authorization configuration .................................................... 44

Figure 7: Sequence diagram of a sensor's data protection ....................................................... 45

Figure 8: Sequence diagram of data access by a client ........................................................... 46

Figure 9: Sequence diagram of blockchain iterations ............................................................. 47

Figure 10: Sequence diagram of the ABE decryption key management. ....................................... 47

Figure 11: Data transfer sequence diagram involving Blockchain PKI and Message Broker ................ 48

List of Tables Table 1: Component Description ...................................................................................... 17

Table 2: Component Description for the ABE Encryption Module .............................................. 19

Table 3: Component Description for the FGA Decryption Module .............................................. 20

Table 4: Component Description for the Message Broker ........................................................ 21

Table 5: Component Description for the Fine-Grained Authorization Server ................................ 22

Table 6: Security Requirements - Comprehensive Access Control .............................................. 23

Table 7: FGA Encryption & Decryption Modules Software Requirements ..................................... 25

Table 8: Component Description for the HyperLedger Fabric ................................................... 28

Table 9: Component Description for the IoT CA ................................................................... 29

Table 10: Component Description for the Hash Message Broker ................................................ 30

Table 11 Component Description for the Blockchain-based supplychain management system ............ 32

Table 12: Component Description for the ABE Key Provider .................................................... 34


COLLABS D3.1 of 53

Table 13: Component Description for the Policies Server ........................................................ 35

Table 14: Component Description for the Revocation List ....................................................... 35

Table 15: Security Requirements - Blockchains and Interledgers ............................................... 36

Table 16: Hyperledger Fabric Modules Software Requirements ................................................ 37

Table 17: Component Description for the Hardware Security Component .................................... 38

Table 18: Security Requirements for the Hardware Security Component..................................... 39

Table 19: Optiga TPM Modules Software Requirements .......................................................... 40

Table 20: Mapping COLLABS Level-2 security components to ALES Use Case ................................. 48

Table 21: Mapping COLLABS Level-2 security components to REN Use Case .................................. 49

Table 22: Mapping COLLABS Level-2 security components to PCL Use Case .................................. 50


COLLABS D3.1 of 53

1. Introduction

In recent years we have witnessed an increase in identity theft, security breaches and data loss [1]. Unauthorized access and intentional breach have become one of the major threats, typically due to the improper implementation of access control systems [1], [2]. Access control systems help perform authentication and authorization [2], and in COLLABS we adopt a decentralized access control scheme to ensure that all the data produced within the smart factory, collected from connected objects, and all the actions performed on the connected objects comply with access rights granted by the active security policy. In particular, we leverage attribute-based access control, that is a logical access control model that is distinguishable because it controls access to objects by evaluating rules against the attributes of the entities (subject and object) and the environment relevant to a request [3]. Furthermore, our system is based on a ledger-based Public Key Infrastructure (PKI) to guarantee that communication channels are secured with respect to authenticity, confidentiality, and integrity. The usage of secure distributed blockchains enhances the availability of the security components, provides traceability and non-repudiation, thus protecting the smart factory assets [1].

Considering the above, the goal of this deliverable is to detail the main security components of level-2 in COLLABS. It describes the main components for the MVP as well as an overview of the planned components for the next releases of the relevant deliverables (i.e., D3.2 and D3.3) which will be developed and integrated in COLLABS to provide resilience in smart factory. Said Level-2 security components in COLLABS provide a fine-grained authorization mechanism based on attribute based encryption, blockchain mechanisms and public key infrastructures.

This deliverable is part of Work Package 3 (namely, “Resilience in Smart Factories”). Work Package 3 consists of four tasks that examine and discuss the comprehensive access control (Task 3.1), the alternatives to use private blockchains (Task 3.2), and offer authentication and identification mechanisms through Task 3.3, while Task 3.4 provides mechanisms to monitor and verify sensitive information. WP3 technical specifications and architecture will be continuously updated in the next releases for D3.2 “The COLLABS Level-2 Security Package for Resilience in Smart Factories: 1st complete version”, and D3.3 “The COLLABS Level-2 Security Package for Resilience in Smart Factories: Final Version”. This architecture will follow the technical and business achievements of the project and will built on top of the latest version of Reference Architectures proposed by ECSO (RAMI4.0 and IIRA) for Industry 4.0.

This document is organised as follows. The second Chapter of this document provides a high level description about the main security components of the level-2 security mechanisms of COLLABS, as well as an example of execution to achieve fine grained authorization based on distributed ledgers. The third Chapter provides a description of security components in terms of functionality, pre-conditions, post-conditions, and interaction component list. We also provide the security requirements that should be covered with respect to COLLABS requirements provided in the deliverable “D1.2: Positioning of COLLABS”. Furthermore, we give a brief overview of planned Post MVP components. The fourth chapter summarizes the main data flows involving each MVP component described in the previous chapter.Finally, we provide our concluding remarks in Chapter five.


COLLABS D3.1 of 53

2. Level-2 Security Components for Resilience in Smart Factories

COLLABS defines multiple-levels of security mechanism, consisting of three security levels:

• The first level consists of hardware-enabled and device-level security mechanisms • The second level includes security-enabling functionalities based on distributed ledger

technologies. • The third level of security corresponds to applying system-wide machine learning-based

techniques to provide contextual awareness and deliver cognitive security-enabling mechanisms.

The scope of this document is to describe the level-2 security mechanisms. In particular, level-2 corresponds to information exchange between the devices within the boundaries of the smart factory. Therefore, in this deliverable we describe how in COLLABS:

• ledger-based security modules can secure inter-device communications and enhance the trust level in inter-device collaboration, on several aspects of the Smart Factory lifecycle;

• comprehensive and decentralized access control is used to protect the Smart Factory assets, relying on a fine-grained authorization module and ensuring that all the data collected from connected objects, and all the actions are authorized following an effective security policy;

• public key infrastructures (PKI) is used for identification and authentication purposes; • data sensitivity can either be manually identified by design, or automatically using machine

learning algorithms through confidential data discovery.

In the following subsections, we provide a clear picture about the main components as well as an example of system interactions.

2.1. Architecture

The proposed system architecture is depicted in Error! Reference source not found.. It consists of entities that communicate with the smart contracts to govern the access control of the encrypted data stored on an Interplanetary File System (IPFS) [4]. Such entities include the sensor owner, the client, the sensors devices, the message broker (IPFS) and hash message broker, and smart contracts.


COLLABS D3.1 of 53

Figure 1: Blockchain based Fine Grained Authorization System

Our system includes the following elements in order to provide a fine-grained authorization system based on attribute-based encryption [5].

1) Sensors owner: It represents the owner and responsible of the architecture. 2) Client(s): It refers to readers of the data stored in the system. Every client has a unique

address used to interact with the blockchain. 3) Policy: Group of attribute combinations necessary to decrypt a particular message. 4) Sensors: Our assumptions are as follows.

ü Every sensor has an attached policy, which has to be satisfied to decrypt the sent messages of this sensor.

ü Various sensors can have the same policy. ü Every sensor has an address to interact with the blockchain.

5) Smart contract: Smart contracts are programs that are executed and hosted in the blockchain

[2]. All the operations and stored data in these programs are public. We consider the smart contract as a root of trust, then the execution is always correct and the stored data cannot be faked. Also, all the interactions with the smart contract are authenticated and recorded in the blockchain.

6) Policies server: This server stores the policies. It is a smart contract, only the sensor owner can modify this smart contract.

7) ABE key provider: It is a smart contract, only the sensor owner and the clients can modify it. This smart contract stores vectors of 4 variables: (address_, E_ABEK_, Pub_, nonce_), where:

ü address_ is the address of the client;


COLLABS D3.1 of 53

ü E_ABEK_ refers to the encryption of Attribute based Encryption (ABE) key of the client , encrypted with Pub_; where Pub_ is the public key of the client linked to its private key (Priv_);

ü nonce_ is the number of version of the ABE key;

8) IoT CA: It is a smart contract that acts as a Certificate Authority (CA) of the sensors.

9) Message broker: It is an Interplanetary File System (IPFS). It refers to a Peer-to-Peer (P2P) decentralized database that holds the data, and stores every encrypted message linked to its hash.

10) Hash message broker: It stores the metadata of every message sent by the sensors. There are 4 variables to store for each message: (hash_, address_, t_,nonce_). hash_ is the hash of the message sent by the sensor; address_ is the address of the sensor that sent the message ; t_ is the time when the metadata was uploaded to the blockchain; and nonce_ is the number of the version of the ABE key that was used to encrypt the data.

11) Revocation list: This list stores the necessary information to revoke the client access to the data. This necessary information depends on the ABE algorithm used.

2.2. Protocol Execution

In the following, we illustrate an example of interactions among the system entities. The global protocol that leverages all level-2 security components follows the following steps as depicted in Error! Reference source not found..

• Step 0: The sensor owner updates the policies server and the ABE key provider loading all the client addresses. In particular, the client stores its public key (Pub_) linked to its address (address_) in the ABE key provider. Also, the sensor owner reads the public key, validates it and stores the ABE key in the ABE key provider encrypted with the client public key Pub_.

• Step 1: The sensor reads its policy_ from the Policies server and encrypts its message. • Step 2: The sensor sends the hash of the message to the Hash Message Broker signed and sends

the encrypted message and the hash to the Message Broker (IPFS). Then, the Hash Message Broker and the IPFS verify the identity of the sensor using the IoT CA in order to accept or to deny the storing.

• Step 3: The client connects with the Hash Message Broker and provides the address of the sensor to read. Then, the client reads the metadata, checks if he has the correct Attribute based encryption key version, and then downloads the hash of that message.

• Step 4: Using the hash, the client downloads the corresponding encrypted message from the IPFS.

• Step 5: The client receives from the ABE Key provider the encrypted key E_ABEK and decrypts it using its public key Pub_ getting then ABEK_. The client tries to decrypt the message coming from the IPFS using the key ABEK_. It will succeed to decrypt it if the attributes of the client are compatible with its policy_. If it succeeds, the client checks the veracity of the message comparing it with the hash_.

Our decentralized fine grained authorization framework using blockchain technology system provides integrity and traceability. The distributed ledger of the blockchain-based solution acts as an immutable evidence for all the transactions recorded on it. It provides traceability features for access control related events. This system assures all participating entities that the data stored on it cannot be


COLLABS D3.1 of 53

modified or tampered with, thereby enforcing trust. Our blockchain-based solution maintains a chain of hashes, wherein each block uses the hash of the previous block. Therefore, altering one bit in a block leads to invalidating all the blocks that follow it.

For the MVP, we focus on the encryption process at the sensor level in order to produce encrypted data, the decryption process at the client side in order to protect the access to the data, the message broker, the hash message broker, and the IoT CA. More details about the components are depicted in the following section.


COLLABS D3.1 of 53

3. Security Component Description

In this chapter, we state the security components for the level-2 in COLLABS. For each component, we will follow a description form. Moreover, we provide security requirements perceived by these components. In particular, for each COLLABS component, we provide its description, including the following information fields with their list of interaction components:

• Component Name: name of the level-2 COLLABS component;

• Functionality: description of the main component features;

• Pre-conditions: refers to the conditions that must be satisfied before interacting with the component.

• Post-conditions: refers to the conditions that will be satisfied after the component will be providing its functionalities;

• Interaction Component List: List of the interaction components. In particular, we provide the following fields:

o IComponent Name: name of the component with whom the component is interacting

o Input and Output: a short description of input and output data exchanged.

Table 1 below, provides the template to be used for describing the various COLLABS components.

Table 1: Component Description

Component Name << Name of the component >>

Functionality

<< Brief description of your component functionalities >>

Pre-condition

<< Conditions that must be satisfied before interacting with the component >>

Post-condition

<< Conditions that must always be true after interacting with the component >>

Interaction Component List

<<List here the components with which your component interacts >>

IComponent Name Input and Output

<< Name of the interacting component >> (INPUT)

or (OUTPUT)

We also provide the security requirements that need to be covered.


COLLABS D3.1 of 53

3.1. Comprehensive Access Control

3.1.1. Overview

The goal of comprehensive access control is to provide fine-grained authorization for constrained environments, relying on distributed ledger technologies for exchanges between different involved mechanisms.

Attribute-Based Access Control (ABAC)1 is an access control paradigm in which permissions are a combination of subject, resource, action and environment attributes, enabling the definition of very fine-grained access control policies. A traditional ABAC architecture usually requires Policy Enforcement Points (PEPs) closer to the resources to protect. These PEPs rely on a Policy Decision Point (PDP) that has knowledge of the access control policy, with which they maintain a constant connection to respond their authorization decision requests. This PEP/PDP architecture enables great flexibility but is not suitable for constrained environments, due to its requirements in deployment resources and connectivity. Comprehensive access control aims to open constrained environments to ABAC, relying on techniques using Attribute-Based Encryption.

Attribute-Based Encryption (ABE)2 is an asymmetric cryptosystem in which the encryption and decryption keys are based upon attributes. In such a system, the decryption of a ciphertext is possible if and only if the attributes of the decryption key match the attributes of the ciphertext.

There are two different types of ABE schemes:

• Ciphertext-Policy ABE (CP-ABE): The ciphertext is encrypted using an encryption policy, which consists of a logical condition over attributes. The decryption key is derived from an attribute set. The decryption of a ciphertext is feasible if-and-only-if the attribute set used to derive the decryption key satisfies the encryption policy.

• Key-Policy ABE (KP-ABE): The ciphertext is encrypted using an attribute set. The decryption key is derived from a decryption policy, which consists of a logical condition over attributes. The decryption of a ciphertext is feasible if-and-only-if the attribute set used for the encryption satisfies the decryption policy.

1 Guide to Attribute Based Access Control (ABAC) Definition and Considerations https://www.nist.gov/publications/guide-attribute-based-access-control-abac-definition-and-considerations-1 2 Attribute-Based Encryption for Fine-Grained Access Control of Encrypted Data https://eprint.iacr.org/2006/309.pdf


COLLABS D3.1 of 53

Figure 2: Fine-grained authorization using attribute-based encryption

ABE enables to embed ABAC mechanisms in the encryption method. Using this technique, Figure 2 shows how sensors can protect the data they produce by encrypting it in ABE using given attributes, and only need to encrypt it once, no matter how many consumers are going to read this data – which is saving resources. A client that wants to consume such data will have to request an authorization service for an ABE decryption key. This authorization service has knowledge of the access control policy and the client attributes and can then derive an individual decryption key for the client, whose capacities are the strict reflection of the client permissions defined by the access control policy. The client can then get all data from all the sensors, but its decryption key will only be able to decrypt the data it is authorized to read.

3.1.2. Fine-Grained Authorization encryption module

3.1.2.1. Functional Description

The Fine-Grained Authorization (FGA) encryption module allows an IoT device to protect the data it produces in a low-consumption way. It performs an ABE encryption over the produced data, using an ABE master public key and an encryption policy. Encryption policies are provided through the blockchain.

3.1.2.2. Component Identity Form

In Table 2, we describe the component main features, pre-conditions, post-conditions, and the interaction component list.

Table 2: Component Description for the ABE Encryption Module


COLLABS D3.1 of 53

Component Name ABE encryption module

Functionality

The ABE encryption module encrypts a text with a CP-ABE scheme, using the master public key and the encryption policy provided by the blockchain. The FGA encryption module deployment should be compiled and installed directly on the sensor device.

Pre-condition

The deployment target must satisfy the system requirements of OpenABE (https://github.com/zeutro/openabe).

Post-condition

FGA encryption module delivers encrypted data, such as all (and only) clients authorized to read by the encryption policy can decrypt.



ABE Keys smart contract From ABE Keys smart contract: ABE master public key

Attributes & Policies smart contract From Attributes & Policies smart contract: encryption

policy

Message Broker To Message Broker: ABE-encrypted data

3.1.3. Fine-Grained Authorization decryption module


The Fine-Grained Authorization (FGA) decryption module allows a client to read data protected using FGA system. It interconnects with FGA server to get a decryption key and decrypts as many data as it can. It collects data from a message broker, according to notifications from the blockchain.


We provide the component description in Table 3.

Table 3: Component Description for the FGA Decryption Module

Component Name FGA decryption module


COLLABS D3.1 of 53

Functionality

The FGA decryption module decrypts a ciphertext encrypted with a CP-ABE scheme, using a decryption key provided by FGA server through the blockchain. The FGA decryption module deployment can either be compiled and installed on client device, or deployed as a single docker container in client device.

Pre-condition

The deployment target must satisfy the system requirements of OpenABE (https://github.com/zeutro/openabe).

Post-condition

FGA decryption module delivers decrypted data from all (and only) ciphertexts a client is authorized to read by the encryption policy.

Interoperability and Interaction Component List


ABE Keys smart contract From ABE Keys smart contract : individual ABE

decryption key

Message Broker From Message Broker: ABE-encrypted data

3.1.4. Message Broker (centralized)


The Message Broker role is to ensure availability of published data to the requesters. It can be a component managed by a 3rd party or shared between organizations, as no particular trust is required regarding confidentiality of the data.


In Table 4 we provide the main details about the Message Broker component.

Table 4: Component Description for the Message Broker

Component Name Message Broker

Functionality


COLLABS D3.1 of 53

This component gathers data from publishers and provides it to requesters. Requesters can obtain data from data hash.

Pre-condition

The storage space must be sufficient to store all the data.

Post-condition

Message Broker stores the data if it has enough space and associates it with its hash. A requester requesting for the hash of a known data hash will get the associated data.



FGA encryption module From FGA encryption module: ABE-encrypted data to be

stored

FGA decryption module To FGA decryption module: Stored ABE-encrypted data

CA IoT CA IoT à Message Broker: Verify the authenticity of

the data uploaded by IoT devices

3.1.5. Post-MVP Components For Post-MVP, we anticipate the development and deployment of additional components such as the Fine-Grained Authorization server.

3.1.5.1. Fine-Grained Authorization server

3.1.5.1.1. Functional Description

The Fine-Grained Authorization (FGA) server is a solution built around an ABE Key Management Server, allowing a sensor’s owner to setup a fine-grained access control to its sensors data. It is an authorization service that manages authorization attributes, ABAC policies, and ABE keys. It owns the actual ABE master keys for the system and generates ABE decryption keys for clients, using their individual attributes (and actual ABAC policy if applicable). Interactions with ABE encryption and decryption modules are done through the blockchain.

3.1.5.1.2. Component Identity Form

In Table 5 we provide the component identity form for the Fine-Grained Authorization Server.

Table 5: Component Description for the Fine-Grained Authorization Server

Component Name Fine-Grained Authorization Server


COLLABS D3.1 of 53

Functionality

The FGA server generates its own pair of ABE master keys. It publishes master public key through the blockchain for encryption modules.

For each client in the system, FGA server derives, from master private key and client attributes from the blockchain, their individual ABE decryption key. The ABE decryption key is encrypted for each client and published in the blockchain for decryption modules.

Authorization revocation is done by renewing the ABE master keys.

Pre-condition

Clients’ authorization attributes must be pre-defined and accessible from FGA server.

Post-condition

FGA server generates ABE master public keys, such as data encrypted using a ABE master public key can be decrypted only by an ABE decryption key derived from the associated ABE master secret key.

FGA server derives ABE decryption keys, such as data encrypted using an encryption policy can be decrypted only by an ABE decryption key derived from an attributes set satisfying the encryption policy.

Individual ABE decryption keys are encrypted for the client they belong.



PKI smart contract

From PKI smart contract: clients individual encryption keys

To PKI smart contract: ABE master public key, individually encrypted ABE decryption keys

Attributes & Policies smart contract

From Attributes & Policies smart contract: client attributes

To Attributes & Policies smart contract: encryption policies

3.1.6. Requirements We provide the pertinent security requirements for the FGA Encryption, FGA Decryption, Message Broker and the FGA Server in Table 6.

Table 6: Security Requirements - Comprehensive Access Control


COLLABS D3.1 of 53

Requirement ID

Requirement Name

Coverage Technology Mapping

CSR-01 Identification and Authentication

Fully Publication of encrypted data in the system must be signed to ensure source authentication. Access to the data is enforced by the decryption capability, on which only entities with a decryption key that satisfies the encryption policy can decrypt data.

CSR-02 Identification and Authentication

Fully ABE is a state-of-the-art cryptosystem for data protection and authorization enforcement.

CSR-05 Authorization Fully The module enforces access control policy as an encryption policy. It relies on attributes defined by IAM system.

CSR-06 Authorization Fully The module provides attribute-based access control mechanism.

CSR-11 Integrity Fully All the data is stored together with a digest of the data-package making it unmodifiable.

CSR-13 Availability Partial At MVP level, the centralized version of message broker will not enforce this requirement. For further versions, a decentralized Message Broker will protect the system against denial-of-service

CSR-14 Availability Partial At MVP level, the centralized version of message broker will not enforce this requirement. For further versions, a decentralized Message Broker will protect data against loss or unavailability thanks to replication.

CSR-15 Availability Partial At MVP level, there is no particular enforcement of this requirement while the encryption policy is statically defined by device.

For further versions, encryption policies will be dynamically provided through the blockchain, and data persistence will be strengthen thanks to replication such as it will allow online patching and update capabilities. The Fine-Grained Authorization server will be easily updated.

CSR-17 Availability Partial Security mechanisms (such as signature verification) rely on blockchain for inputs, which limits by design the risks of unavailability. Moreover, the required inputs have a very low change frequency, so their


COLLABS D3.1 of 53

hypothetical unavailability should not affect the service availability.

However, it might be theoritically possible that a signature is refused due to a conjuction of a recently renewed authentication key and an unavailability of blockchain PKI.

At MVP level, without revocation mechanism, all security aspects of the message broker are offline and are not subject to unavailability. In the further versions that may include revocation, this requirement should be monitored.

CSR-18 Confidentiality Fully The module provides an end-to-end encryption mechanism that ensures data confidentiality in transit and at rest on intermediate stopovers without right-to-know (such as cloud storage / message broker).

Besides, ABE decryption key are protected in transit and at rest using public key encryption.

CSR-19 Deployment Partial At MVP level, the encryption policy is statically defined by device. For further versions, the module will enforce compliance with provided encryption policies.

The Fine-Grained Authorization Server will provide encryption policies compliant with access control policy and generates ABE decryption key in conformance with IAM attributes.

CSR-21 Deployment Partial At MVP level, the decryption key is statically defined by client. For further releases, the decryption keys will be dynamically generated and provided, allowing dynamic opening access to new tenants in the system, even for already encrypted data.

The Fine-Grained Authorization Server will be able to dynamically open access to new tenants by generating them decryption keys on definition of a mapping of current authorization attributes and new tenant attributes.

In Table 7 we provide the software requirements for the FGA Encryption and Decryption Modules.

Table 7: FGA Encryption & Decryption Modules Software Requirements


COLLABS D3.1 of 53

FGA encryption & decryption module software requirements:Name

Vendor Version Reference

OpenABE Zeutro LLC 1.0.0 https://github.com/zeutro/openabe Git Software Freedom Conservancy 2.29.2 https://git-scm.com/ cURL cURL 7.73.0 https://curl.se/ GoogleTest Google 1.8.0 https://github.com/google/googletest OpenSSL by Zeutro Zeutro LLC 1.1.1-dev-bp https://github.com/zeutro/openssl RELIC -- 0.5.0 https://github.com/relic-toolkit/relic

NodeJS OpenJS Foundation 10.15.3 https://nodejs.org/

3.2. Blockchains and Inter-Ledgers

3.2.1. Overview

Blockchain or distributed ledger is a decentralized, publicly or privately verifiable and peer-to-peer system, which stores data and executes arbitrary logic known as smart contract. It maintains data integrity and consistency of smart contracts execution among nodes through various consensus protocols [4], [5]. It results in a server where the trust of the services provided remains in all the integrating nodes. If we have a big quantity of nodes or we trust in the few integrating nodes, the services provided by the blockchain can be considered as a root of trust.

There are 3 types of blockchain [6]:

- Public blockchain: Everyone can be a node and be part of the blockchain. Since untrusted nodes exist, the presence of several nodes is necessary to consider public blockchain as trusted. The interactions with the blockchain are expensive (16.57 euros store a KB in Ethereum at the

moment this document was written [7] ) and slow (15 seconds – 5 minutes for any interaction in Ethereum).

- Private Blockchain: Various nodes host the blockchain but all these nodes belong to the same organization, the admin. It is a more controlled blockchain, to interact with it you need permission from the admin and it is as trust as the hosted entity. All the interactions with the blockchain are fast and cheap.

- Consortium Blockchain: It is a mix of private blockchain and public blockchain. In order to interact with the blockchain, the user needs a consent from an admin, but there are multiple admins belonging to different organizations. To incorporate a new node, there must exist an agreement between the different admins. There are fewer nodes than in a public blockchain but the nodes are more trusted, so the blockchain is still trusted, does not have to depend on a trusted third party (TTP) like in a private blockchain and it is cheap and fast.

In the use cases defined in deliverable “D1.2: Positioning of COLLABS”, privacy is a fundamental element for the system, so that, the blockchain should be private or consortium. Hyperledger is an effort that develops blockchain networks for different scenarios, and it affords the use of general-purpose programming languages such as Java, Go and Node.js for smart contract design. It also accepts Solidity, one of the most used smart contracts’ programming languages nowadays. Hyperledger is a very


COLLABS D3.1 of 53

recognized organization and it allows the use of private and consortium blockchain. That is why we choose Hyperledger for the implementation of blockchain in this project.

Hyperledger has multiple frameworks such as Hyperledger Borrow, Hyperledger Fabric, Hyperledger Grid, and Hyperledger Sawtooth. All of them are used to build enterprise blockchain for a consortium of organizations and have some differences between them. Hyperledger Fabric is a framework focused on industry use. It has privacy, flexibility, and decentralization, which make it perfect for COLLABS.

In the following, we list the associated MVP components; namely: HyperLedger Fabric, Hash message broker, and IoT CA. We also provide an overview of the components for the Post MVP platform release, which include: ABE key provider, Revocation list, and Policies server.

3.2.2 Hyperledger fabric


Hyperledger Fabric is a framework developed by Hyperledger [8]. One of the key advantages of Hyperledger Fabric is that it allows entities to conduct confidential transactions without passing information through a central authority. This is accomplished through different channels that run within the network.

Its modular architecture achieves a great flexibility allowing components such as consensus and membership services to be plug-and-play together with a division of labor creating different roll nodes within the network.

The components that build an Hyperledger Fabric network are:

- Ledger: It is a tamper-resistant record of all the transactions of the blockchain. Every transaction that is approved by participant agreement (consortium) is added to the ledger. It is denoted by “L” in Figure 3. Error! Reference source not found.

- Channel: A network that connects all the blockchain components that are part of the specific network. Every channel has his own ledger. The different components of the blockchain can interact with the ledger of a channel if and only if are part of the channel. “C” in Figure 3 refers to Channel.

- Peer node: A node that is maintained by one of the organizations of the blockchain. It hosts the copy of the channel ledgers that the organization has access. Peer node is denoted by “P” in Figure 3.

- Smart contract: The smart contract provides a well-defined set of ways by which the ledger of a channel can be asked or updated by a client application. In Figure 3, a smartcontract is denoted by “S”.

- Certification authority: Every organization has his own certification authority that authorize the rest of the component to interact with the blockchain, this refers to “CA” in Figure 3.

- Client application: It is the minimal requirement to interact with the blockchain. It just has a private key and a certificate of its organization. It can interact with the ledger by using the smart contracts of the channels it has access to. “A” in Figure 3 represents the client application.

- Orderer node: These nodes are in charge of add new transactions and data to the blockchain in form of blocks. It is needed one per blockchain, but it is possible to add more. These nodes are denoted in Figure 3 by “0”.


COLLABS D3.1 of 53

- Admins: Every organization has an admin who can change some channel configurations (“CC”) and in some cases the network configuration (“NC”). “R” in Figure 3 represents the Admins.

- Address: To interact with the smartcontract, the Client Applications use their address to identify themselves. The address is the last 160 bits of the result of the sha-3 256 of the IoT device public key.

Figure 3: Diagram of Hyperledger Fabric from3

For more information, we refer the reader to the HLF documentation4.


The component description of HyperLedger Fabric is depicted in Table 8.

Table 8: Component Description for the HyperLedger Fabric

Component Name Hyperledger Fabric

Functionality

Hyperledger Fabric is a framework developed by Hyperledger. It is focused to be deployed in the industry. Private transactions manage to grant many new functionalities to the system. It has a great flexibility, which is a helpful tool to integrate several organizations within the blockchain network, and it is possible to modify the consensus algorithms and the cryptographic algorithms to use the most suitable ones for the system.

Pre-condition

To use Hyperledger fabric it is essential have the network deployed:

3 https://hyperledger-fabric.readthedocs.io/en/release-2.2/network/network.html 4 https://hyperledger-fabric.readthedocs.io/


COLLABS D3.1 of 53

Endorsing peers: These nodes are in charge of store all the transaction done in the blockchain and the smartcontract deployed.

Orderer nodes: These nodes are in charge of store all the transaction done in the blockchain and the smartcontract deployed.

If we want to deploy a consortium network, it is important that each organization in the blockchain has at least one node of each role.

These nodes are provided as docker containers to be deployed in Linux and Windows systems.

Post-condition

When a smart contract is executed, all the orderer nodes will verify this execution. Exactly what is defined in the smart contract will happen, that is why smart contracts are root of trust.



PKI The user that want to interact with the blockchain must be registered in the PKI (input)

ABE Blockchain grant the trust and the needed infrastructure to be able to modify regularly variables of ABE and keep simultaneously trust and availability. (output)

Hardware security module [9]

It is essential in blockchain identify the user that want to interact want the blockchain to authorize or denied them. The hardware security modules (HSM) are a good solution to keep the private keys secret.

3.2.3. IoT CA


The Fine-Grained Authorization server will use smart contract to implement some of their most important functionalities. For the MVP the Hash message broker and the IoT CA smart contracts will be deployed. The IoT CA is a smart contract that stores the addresses of the trusted IoT nodes.


We provide the main details of the IoT CA in Table 9.

Table 9: Component Description for the IoT CA

Component Name IoT CA

Functionality


COLLABS D3.1 of 53

The IoT CA stores a register of all the IoT devices addresses that have privileges to upload data to the system. Only the admin of the smart contract have the privileges to edit theses addresses, and everyone who has access to the channel will be able to ask for the privileges of an IoT device address.

Pre-condition

The admin of the IoT CA has to manage the smart contract adding or removing the IoT devices address privileges.

Post-condition

Only the admin can modify the data stored in the smartcontract.

Everyone who have access to the channel will be able to ask for the privileges of a IoT device address.



Hash Message Broker IoT CA àHash Message Broker: Information about the valid addresses

Message broker IoT CA à Message Broker: Information about the valid

addresses

3.2.4. Hash Message Broker


The hash message broker is a smart contract that stores the metadata of all the messages stored in the message broker. Before accepting a metadata packet, the origin has to be validated by asking the IoT CA.


We provide description details of the Hash message broker in Table 10.

Table 10: Component Description for the Hash Message Broker

Component Name Hash message broker

Functionality

This component stores the metadata of all the messages that are sent and stored in the message broker. Every who has access to the channel can ask for this information.

Pre-condition

The only precondition is that the IoT CA must be already deployed.


COLLABS D3.1 of 53

Post-condition

For who receives the information of these smart contracts, it can be sure that the information is true because it is impossible to modify it, and it is from a valid IoT address approved by the admin of IoT CA.



IoT CA IoT CA àHash Message Broker: Information about the valid addresses

Client Application Hash message brokerà Client application: Send the

metadata of a specific message.

IoT device IoT Device àHash message broker: Send the metadata

of a specific message.

3.2.5. Blockchain-based supply chain management system

A supply chain management system is a functionality used to control the stream of goods, finances and data related to a product, from the acquisition of raw materials to the delivery of the final product at its final customer. Sometimes this system can also include control over Maintenance, Repair, and Overhaul (MRO) operations.

It is common belief that supply chain corresponds to logistic management, however this is just one feature of the entire system. With the increase in digitalization and automation that characterize the current industrial manufacturing environment the supply chain includes not only material tracking but also software interaction, data handling and order fulfilments. The system must integrate interaction from all the parties involved in a product lifecycle such as manufacturers, logistic companies, suppliers and possibly control authorities.

In this scenario, we can see a supply management system as a distributed system that requires collaboration between untrusted parties that work towards a common target. This structure with its requirements is implemented on a blockchain, which is an established design for collaborative use cases in a distributed (and untrusted) environment. The requirements and functionalities of the system are detailed in the following sections.


The proposed design implements a smart contract that manages a supply chain from the raw materials to the final customer. The main stakeholders are:

- Raw material company: provides raw material to the suppliers - Supplier: provides parts to the manufacturer - Manufacturer: given the supplies produces the final product - Customer: order and then receives the final product


COLLABS D3.1 of 53

- Certification authority: independent organization which inspects the product lifecycles and guarantees certain properties

- Distributor: handles logistic aspects

Figure 4: Supply chain to blockchain mapping

In the supply chain abstraction presented in this picture is represented a flow of goods going from raw materials towards the final customer. The system also contains streams of data going back and forth in the supply chain such has contracts details and product compliance data.

In order to handle all the necessary information between the stakeholders three different smart contracts (hence channels) have been designed. This division ensures the respect the least knowledge principle. Moreover between participants of the same channel we also differentiate information access level to guarantee proper access control to data using “private collection”, which is a particular concept from Hyperledger Fabric that isolates parts of the data from the ledger while keeping a zero knowledge proof of their existence on it.

The system is implemented using Hyperledger Fabric and deployed in a distributed environment for demonstration purposes. As future steps, we envision the integration of hardware security modules in the system to strongly link the physical goods with the associated data and the usage of strong authentication system such as trusted platform modules to authenticate the blockchain participants and provide strong non-repudiation guarantees.


We provide the component identity form in Table 11.

Table 11 Component Description for the Blockchain-based supplychain management system

Component Name Blockchain-based supplychain management system

Functionality


COLLABS D3.1 of 53

Smart contract system that handles the lifecycle of a product from ordering to final delivery. It regulates not only the physical exchange of goods (e.g. logistic aspects) but also determines the data collection and linkage providing an auditable and reliable system with non-repudiation guarantees. A proper access control respecting the least knowledge system is enforced to allow untrusted parties to collaborate in a productive fashion.

Pre-condition

In order to deploy this technology we need:

- Hyperledger Fabric cluster up and running - Hyperledger network composed by a proper amount of stakeholders (each of which is

composed by their CA, peers and clients) - All the participants to the smart contract needs to revision its code and approve it before

starting using it

Post-condition

Each time a smart contract is executed its iteration with the ledger gets immutably recorderd (providing a strong mean of auditability).


At first (MVP) we deploy a standalone system which only interacts with the blockchain hosting the smart contracts.

Going forward we envision a possible interconnection with:

- Hardware security modules to enhance data tracking and key security - IAM for network participants fine grained authorization

Component Name Input and Output

PKI system

A system of certification authorities (one for each stakeholder) is going to be deployed to manage the participants to the blockchain system and showcase that each partner manages its own participation

Smart contract

All the interaction with the ledger are governed with a smart contract the formally describes what can and cannot be done by each partner. This scripts will be designed to sustain all the required action in the supply chain

Client Application

Light client application interfacing with the blockchain application by triggering a smart contract execution. This requires minimal performances to run in order to be deployed on low power devices


COLLABS D3.1 of 53

3.2.6. Post-MVP Components

We anticipate the development and deployment of additional components such as the ABE key provider, Policies server, and revocation list.

3.2.6.1. ABE key provider


When the clients want to receive their decryption ABE key, they have to ask the ABE key provider for it, and decrypt it using their private key.


We describe the component identity form in Table 12.

Table 12: Component Description for the ABE Key Provider

Component Name ABE key provider

Functionality

Store the public key of the CA clients and the decryption ABE keys encrypted with the public keys

Pre-condition

The client applications must store a public key paired to a truly secret private key in the smart contract.

The sensor owner must upload the decryption ABE keys encrypted with the client application public keys and keep this smart contract updated.

Post-condition

The client application must be kept secret.



Sensor owner Sensor ownerà ABE key provider: decryption ABE key encrypted.

Client Application ABE key provider à Client application: Send the

decryption ABE key encrypted.

3.2.6.2. Policies Server


COLLABS D3.1 of 53


The IoT nodes have to encrypt their message before send them to the message broker using the ABE Policies. The IoT nodes receive these policies from the Policies Server.


We provide the component identity form for the Policies Server in Table 13.

Table 13: Component Description for the Policies Server

Component Name Policies server

Functionality

Keeps an update list of the IoT devices groups policies.

Pre-condition

The user owner has to keep the list updated.

Post-condition

The IoT devise will ask for its policy before encrypting a message.



Sensor owner Sensor ownerà Policies server: Update the policies and encryption keys.

IoT device Policies server à IoT device: Send the encryption keys

3.2.6.3. Revocation list


In order to integrate direct revocation mechanism in the ABE system, a public revocation list is needed. The sensor owner has to keep an updated list of the revocated user in the revocation list smart contract.


We provide details of the revocation list in Table 14.

Table 14: Component Description for the Revocation List

Component Name Revocation list

Functionality


COLLABS D3.1 of 53

It has a role to store an updated list of the revoked users.

Pre-condition

The ABE system have to accept direct revocation.

Post-condition

The IoT devices should constantly ask the revocation list.



Sensor owner Sensor ownerà Revocation list: Update the revoked users.

IoT device Revocation list à IoT device: The revoked user

information

3.2.7. Requirements

We provide the pertinent security requirements in Table 15.

Table 15: Security Requirements - Blockchains and Interledgers

Requirement ID

Requirement Name Coverage Technology Mapping

CSR-01

Identification

and Authentication

Fully It grants access to authorized member only. Moreover it implements mechanisms (e.g. channels and private data) to provide fine-grained access control

CSR-02

Identification

and Authentication

Fully The system is based on HLF which uses TLS for intra component communication. Moreover each organization uses its own CA to grant access to its member

CSR-04 Authorization Fully The system is structured with channels and private date to strictly enforce least knowledge principle

CSR-05

Authorization

Partial

The system is currently integrated with CAs, however further integration of IAM components and account management can be envisioned

CSR-06 Authorization Partial The system is structured with channels and private date to strictly enforce fine-grained access control. A possible integration of ABE can be envisioned


COLLABS D3.1 of 53

CSR-07 Logging Fully The system is blockchain-based and keeps record of each interaction with the component

CSR-09

Accountability

and non-repudiation

Fully The system is blockchain-based and keeps record of each interaction with the component with strong non-repudiation guarantees

CSR-10 Integrity Fully

All the interactions with the system are validated through the smart contract (which is approved by the participants). In order to change it we need a consensus on the new version

CSR- 11 Integrity Fully The ledger is immutable and the integrity in time is guarantee

CSR-13 Availability Partial

The system shall be protected against system/service degradation (e.g., individual components); e.g., protection against denial-of-service. The service is distributed and provides guarantees against service degradation when participants are unavailable or maliciously acting (majority consensus)

CSR-14

Availability

Partial

Redundant copies of the ledger (data) are stored in a distributed environment availability (on all the peers) ensuring data

In Table 16 we provide the software requirements for the Hyperledger Fabric.

Table 16: Hyperledger Fabric Modules Software Requirements

Hyperledger Fabric module software requirements:Name


Go Google 1.13.x https://github.com/zeutro/openabe

Git Software Freedom Conservancy 2.29.2 https://git-scm.com/

cURL cURL 7.73.0 https://curl.se/

Wget GNU projet 1.20 https://www.gnu.org/software/wget

Docker Docker 17.06.2 https://www.docker.com/get-docker

Python Python Software Foundation 2.7 https://www.python.org/

NodeJS OpenJS Foundation 10.15.3 https://nodejs.org/

3.3. Public Key Infrastructures

3.3.1. Overview


COLLABS D3.1 of 53

For the MVP the main component that will be used for a success PKI implementation will be Hyperledger fabric [8] (component detailed in section Blockchains and Inter-Ledgers), to store the identification of the authorized users. The second main component to be used will be the hardware security component from Infineon, Optiga TPM, to store and manage the private keys of the IoT devices. The private key management is a critical point in cybersecurity. While most of the larger compute devices have a cryptography coprocessor, which generates the private keys using a true random number generator (TRNG), stores them in a physical attacks resistant memory and executes the cryptographic algorithms with side-channel attack resistant circuits, this is not the case of IoT devices. Since said devices do not typically integrate such modules, COLLABS leverages the Optiga family of products i.e., cryptographic coprocessors designed to be used in IoT devices.

3.3.2. Optiga TPM


The Optiga TPM is a hardware security module that follows the standard Trusted Platform Module 2.0 (TPM 2.0) developed by TCG 5. This module supports several cryptographic algorithms, has a TRNG, and secure private key management, disk encryption, and allows measured boot.

This component is used with I2C and is designed to directly plug it in a Raspberry Pi. Thanks to this component, we can consider as root of trust the private keys of the devices that use it.


We provide a detailed description of the hardware security module (Optiga TPM) in Table 17.

Table 17: Component Description for the Hardware Security Component

Component Name Hardware security component

Functionality

The Optiga TPM is a hardware security module that follows the standard Trusted Platform Module 2.0 (TPM 2.0) developed by TCG. This module supports several cryptographic algorithms, has a TRNG, secure private key managing, disk encryption, and allows measured boot.

This component is used with I2C and is designed to directly plug it in a Raspberry Pi. It works together with the IoT devices. Thanks to this component, we can consider as root of trust the private keys of the devices that use it.

Pre-condition

The IoT device has to be able to install the library TPM2 TSS or TPM2 PKCS11 that can be found in https://github.com/tpm2-software/tpm2-tools. Normally device with operative system like windows

or Linux can use it.

Post-condition

5 https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-A-Brief-Introduction.pdf


COLLABS D3.1 of 53

After the realization of a signature, these must be validates be using a PKI.



Hash message broker IoT device à Hash message broker: The IoT device send the metadata of the measures signed by the Hardware

security component

Message broker IoT device à Message broker: The IoT devices send the

encrypted data signed by the Hardware security component to the message broker.

3.3.3. Requirements

The security requirements covered by the Hardware Security component are detailed in Table 18.

Table 18: Security Requirements for the Hardware Security Component

Requirement ID

Requirement Name

Coverage Technical mapping

CSR-01 Identification

and Authentication

Fully It allows the possibility to authenticate an IoT device by using a pair asymmetric key.

CSR-02 Identification

and Authentication

Fully It supports state-of-the-art cryptography and management capabilities for protecting credentials.

CSR-05

Authorization

Fully It is able to create true random keys and storing them in a reliable way. It is a useful “support the management of accounts and access control Policies”.

CSR-10

Logging

Fully The component allows the capability of storing in a reliable way the result of measured boot. It protects against manipulations and allows the capability to check the integrity of the data stored in the device

CSR-11

Accountability

and non-repudiation

Fully The component allows the capability to store in a reliable way the result of measured boot protecting against manipulations and allows the


COLLABS D3.1 of 53

capability to check the integrity of the data stored in the device.

CSR-12

Integrity

Partially The device allows the use of measured boot to check to the integrity of the IoT node and can ensure the integrity of some data stored and all the sent data.

CSR-13

Integrity

Fully The Optiga TPM is a hardware based device. I has a long cycle life and it is unmodifiable, so it cannot be hacked. The only way is a physical manipulation.

CSR-18 Availability

Fully The component can create true random asymmetric keys to encrypt the data, and can encrypt the symmetric key using the private key internally in the Optiga, keeping the private key completely reliable.

CSR-19 Availability

Partially The Optiga TPM can use the standard security policies so it is able to follow the most of them. On the other hand, the Optiga TPM cannot receive updates, because it is a hardware-based device, so that, it can have incompatibilities with some alternatives securities policies. In general this device works with the standard PKI systems like x.509.

CSR-20 Fully The Optiga TPM follows the TPM standard that adds many limitations of its functionality to ensure a correct use of it.

In Table 19, we provide the software requirements for the Optiga TPM.

Table 19: Optiga TPM Modules Software Requirements

Optiga TPM module software requirements:Name


libp11 OpenSC 0.4.11 https://github.com/OpenSC/libp11

tpm2-tss -- 3.0.3 https://github.com/tpm2-software/tpm2-tss

tpm2-abrmd -- 2.3.3 https://github.com/tpm2-software/tpm2-abrmd

tpm2-tools -- 5.0 https://github.com/tpm2-software/tpm2-tools

tpm2-pkcs11 -- 1.5.x https://github.com/tpm2-software/tpm2-pkcs11


COLLABS D3.1 of 53

Openssl OpenSSL Software Foundation 1.1.1 https://www.openssl.org/

3.4. Confidential Data Discovery

The COLLABS project includes development of solutions for discovering all types of confidential data and monitoring and classification of sensitive data. Initial plan of cooperation between partners related to functionalities that cover confidential data discovery solution has been conceived. We illustrate this plan in Error! Reference source not found..

Figure 5: Confidential data discovery - internal structure

We start by forming a dictionary using machine learning and possibly deep learning methods developed under other components. Such a machine generated dictionary is then sent as an input to the GPU-accelerated pattern matching component. GPU accelerated pattern matching component is used for efficient pattern search. The component includes the use of high-performance computing capabilities of graphics processing units to match patterns at high speed. It supports string search and regular expression matching using the NVIDIA CUDA platform [10]. Techniques implemented within this component use predictive models to identify any sensitive or confidential information. Such a setup could be used within the COLLABS framework for confidential data discovery on various datasets including data from sensors, IoT fingerprints, power consumption data, device activity patterns, network traffic data (packet lengths, IP/MAC addresses, timestamps, directions, packet inter-arrival times) and also emails, files, databases, etc. Moreover, we intend to use outputs of this task as input to machine learning algorithms developed within other project components.

This task is still in preparatory phase, functional specification has been decided, but the part that will serve the input to the rest of the described setup is yet to be implemented. It will not be ready for


COLLABS D3.1 of 53

integration or demonstration within the M12 minimum viable product version of the COLLABS framework.


COLLABS D3.1 of 53

4. Processes involving Level-2 Security Components

This chapter illustrates the main data flows with sequence diagrams describing and visualizing processes involving each MVP component.

4.1. Fine-grained access control over sensors’ data

The following diagrams illustrate the use case of a sensors’ owner using COLLABS Level-2 security components to implement a fine-grained access control over its sensors’ data.

4.1.1. Authorization configuration by the sensors’ owner

Error! Reference source not found. shows the authorization configuration by the sensors’ owner. At authorization initialization, the authorization management generates an ABE key pair, generates individual ABE decryption keys, one for each client, using their attributes published in the blockchain, then encrypts it for its owner so only him can get it, and then publishes it in the blockchain. The diagram also describes the configuration of client attributes and sensors’ encryption policies.


COLLABS D3.1 of 53

Figure 6: Sequence diagram of authorization configuration

4.1.2. Data protection with authorization by a sensor


COLLABS D3.1 of 53

Figure 7: Sequence diagram of a sensor's data protection

Error! Reference source not found. shows the application of the authorization by a sensor, to control access to its data. When a sensor needs to transmit data, it starts by gathering the actual ABE encryption key and the encryption policy that applies to it. It then encrypts the data using ABE before publishing it in the message broker and the associated metadata in the hash message broker.

4.1.3. Authorized data access by a client

Error! Reference source not found. shows the access to a protected data by a client. The client starts by getting the metadata of latest published data before getting corresponding encrypted data. At the same time, it requests its individual authorization key to decrypt data with ABE. This key is itself encrypted but using the client’s individual credentials.


COLLABS D3.1 of 53

Figure 8: Sequence diagram of data access by a client

4.1.4. Blockchain based supply chain management system

This component regulates the interaction of four different parties with the distributed ledger. In particular, in Error! Reference source not found. we can see a possible iteration showing how a blockchain can be used to share information that regulates the activities of a supply chain. The main actions are:

- Order part: PW orders a part (hence create a contract record in the ledger), the supplier reads and accepts the contract

- SendPart: the supplier fulfil the contract by sending the part (hence organizes the logistic), the distributor reads the delivery contract and accepts it

- DeliverPart: the distributor actually delivers to PW which accepts the part delivery - AuthorityInspection: a certification authority can inspect a part history in every moment


COLLABS D3.1 of 53

All these interactions are executed and thus stored on the distributed ledger that guarantees traceability and consistency.

Figure 9: Sequence diagram of blockchain iterations

4.1.5. Blockchain Public Key Infrastructure (IFAG)

As can be observed in Error! Reference source not found. and Error! Reference source not found., the blockchain validates the authorship of all the incoming transactions, and the client trusts in this validation, because we consider the blockchain as a root of trust.

It is essential for step 2 of Error! Reference source not found. to use the HSM to be able to ensure that the incoming data come from the device, and that it is not an attacker that steals the private key.


COLLABS D3.1 of 53

Figure 10: Sequence diagram of the ABE decryption key management.

Figure 11: Data transfer sequence diagram involving Blockchain PKI and Message Broker

4.2. Mapping COLLABS Level-2 security components

In this section we provide a mapping between the proposed components and the industrial use cases of COLLABS which are extensively described in D1.2. The FGA encryption and decryption modules, IoT CA, Message broker, and Hash message broker will be deployed in the same scenarios since they are executed simultaneously. For the sake of clarity, we maintain them into one component that is Fine-Grained Authorization.

4.2.1. ALES use case


COLLABS D3.1 of 53

We illustrate the mapping to ALES scenarios in the following Table 20.

Table 20: Mapping COLLABS Level-2 security components to ALES Use Case

Scenario #1

Controlled and secure remote maintenance

Scenario #2

Controlled Share of Compliance

Data

Scenario #3

Trusted compliance data share across the

supply chain

Scenario #4

Analysis of manufacturing

performance at a global scale

Fine-Grained Authori-zation

N/A

Integration for fine-grained

control on data to be

investigated after MVP

Integration for fine-grained

control on data to be investigated

after MVP

Integration for fine-grained control to be


Hyperledger Fabric

Is used as immutable log

for the Workflow Driven Security

Framework component in COLLABS WP2

N/A

Is used to host the entire supply chain

management system

N/A

Optiga TPM

Integration for root of trust of

the WDSF clients to be


Integration for root of trust on

produced data to be investigated

after MVP

Integration for root of trust of the

blockchain applications (on

edge device) to be investigated after

MVP

Integration for root of trust on

produced data to be investigated

after MVP

4.2.2. REN use case

The following Error! Reference source not found. provides the mapping between COLLABS Level-2 security components to RENAULT scenarios.

Table 21: Mapping COLLABS Level-2 security components to REN Use Case


COLLABS D3.1 of 53

Scenario #1 Controlled & secured remote maintenance

Scenario #2 Cloud-based architecture for industrial process

Scenario #3 Assets management, conformity assessment and threat detection

Scenario # 4 Security of connected devices

Fine-Grained Authorization

To be investigated after MVP

Fine-grained access control on data

captured on edge devices and

published on cloud environment to be

investigated in detail. A CA is used to authorize all the participants of the

blockchain.


N/A

Hyperledger Fabric

Immutable traceability of

access & operations.

To investigate in detail

To be investigated after MVP.

Is used to host the entire conformity and assessment management

system.


Optiga TPM



Use of TPM HSM to secure some of the

edge devices.

Root Of Trust & protection of device

private keys + remote Attestation

Use of TPM HSM to secure some of the edge devices.

Root Of Trust & protection of device

private keys

4.2.3. PCL Use Case

For PCL use case, we describe the mapping of COLLABS security components in Error! Reference source not found..

Table 22: Mapping COLLABS Level-2 security components to PCL Use Case


COLLABS D3.1 of 53

Scenario #1 Shop floor threat detection and prevention

Scenario #2 Remote data sharing

Fine-Grained Authorization

N/A N/A

Hyperledger Fabric To be investigated after MVP


Optiga TPM Root Of Trust & protection of device

private keys To be investigated after MVP


COLLABS D3.1 of 53

5. Summary and Conclusion

This deliverable, being the first output of the WP3 tasks, detailed the level-2 security components of COLLABS.

In particular, we presented the fine grained authorization system where we identified three main components to be developed that are the FGA Encryption Module on the sensor level, the FGA Decryption Module on the client/reader side, the FGA server that manages authorization attributes, the Message Broker in order to ensure availability of published data to the requesters. We also showed in this document how the Blockchain has a central role in order to ensure data exchanges between the system components. In particular, we highlighted the use of the Hyperledger Fabric that allows entities to conduct confidential transactions without passing information through a centralised authority. For that, we leverage the use of smart contracts for the IoT CA that has a role to store a register of all the IoT devices addresses. The hash message broker stores the metadata of all the messages that are sent and stored in the message broker. As detailed within this deliverable, the Optiga TPM is used in order to store and manage the private keys of the IoT devices. We further provide a Blockchain based supply chain management system, that is a smart contract system that handles the lifecycle of a product from ordering to final delivery.

Combining the above, this deliverable also documented the main processes involving level-2 security components. In particular, we illustrated the use case of a sensors’ owner using COLLABS Level-2 security component to implement a fine-grained access control over its sensors’ data. We focused on the Authorization configuration, Data protection with authorization by the sensor, authorized data access by a client. We also described possible iterations showing how a blockchain can be used to share information that regulates the activities of a supply chain. Finally, we provided a mapping of the COLLABS Level-2 security components to the ALES, REN and PCL Use Cases.

As the work on further developing and refining the components continues, the components described in this document and their integration will continue to develop. Further developments will be discussed within the deliverables D3.2 and D3.3 within work package 3.


COLLABS D3.1 of 53

Bibliography

[1] B. Tang, H. Kang, J. Fan, Q. Li and R. Sandhu, "IoT Passport: A Blockchain-Based Trust Framework for Collaborative Internet-of-Things," in 24th ACM Symposium on Access Control Models and Technologies, 2019.

[2] V. Hu, D. Ferraiolo, R. Kuhn, A. Friedman, A. Lang, M. Cogdell, A. Schnitzer, K. Sandlin, R. Miller and K. Scarfone, "Guide to Attribute Based Access Controls (ABAC) Definitions and Considerations (Draft)," NIST Special Publication 800-162, 2013.

[3] O. Pinno, A. Gregio and L. De Bona, "ControlChain: Blockchain as a Central Enabler for Access Control Authorizations in the IoT," in IEEE Global Communications Conference GLOBECOM, Singapore, 2017.

[4] "IPFS," [Online]. Available: https://ipfs.io/.

[5] V. Goyal, O. Pandey, A. Sahai and B. Waters, "Attribute-based encryption for fine-grained access control of encrypted data," in CCS, 2006.

[6] A. Singla and E. Bertino, "Blockchain-based PKI solutions for IoT," in IEEE 4th International Conference on Collaboration and Internet Computing (CIC), Philadelphia, PA, 2018.

[7] A. Yakubov, W. Shbair, A. Wallbom, D. Sanda and R. State, "A blockchain based PKI management framework," in IEEE/IFIP Network Operatins and Management Symposium, Taipei, 2018.

[8] Y. Yu, Y. Li, J. Tian and Liu, "Blockchain-based solutions to security and privacy issues in the Internet of Things," IEEE Wireless Communications, pp. 12-18, 2018.

[9] "Eth Gas Station Blog," [Online].

[10] "Hyperledger," [Online]. Available: https://www.hyperledger.org/.

[11] COLLABS, Deliverable "D4.1: The COLLABS Level-1 Security Package for Securely Connected Objects: MVP", submitted, 2020.

[12] P. Vingelmann and F. H. Fitzek, "CUDA, release: 10.2.89," 2020.

collabs-d3.1 v0.8

Documents