Overview

Thesis objectives

The purpose of this thesis project is to implement and discuss an alternative distributed PKI that leverages on the Blockchain technology to propose an authentication mechanism free of any trusted intermediary, that can satisfy the requirements imposed by the Internet-of-Things and simplify the provisioning of valid certificates for these particular devices. Public Key Infrastructure (PKI) is the set of hardware, software, entities, policies and procedures defined to ensure the creation of secure communication channels between entities, binding each entity’s attributes to a unique public key: this binding is represented by a certificate issued by the Internet Certification Authorities (CAs). The set of policies and protocols that support the PKI functioning are not well suited for particular scenarios like the Internet-of-Things (IoT). The provisioning of valid certificates for a group of IoT devices can be challenging, and the Blockchain can be used as a distributed tamperproof platform for storing certificates autonomously generated by the IoT devices. Finally, we want measure the impact of our implementation on the performance for the creation of a secure communication channel, in order to provide a comparison between the Blockchain-based approach and the standard one.

Research area

In the last five years, a lot of effort in the research has been spent for understanding the possible benefits brought by the integration of the Internet-of-Things and the Blockchain technology. The Blockchain technology was designed to provide a strong data integrity protection by leveraging on a distributed architecture: however, the access to these benefits is granted only to those devices with sufficient storage and computational capabilities. This requirement can’t be satisfied by constrained�resources devices (like IoT devices) and many proposed solutions delegate to more powerful nodes the task of maintaining a copy of the public distributed ledger (i.e. the Blockchain). Among these solutions, the one proposed by Elisa Bertino, Ankush Singla, Jongho Won and Greg Bollella in a 2018’s paper, was used as a starting point for our implementation. It’s based on the Emercoin NVS (Name Value System) Blockchain, that allows to securely store unique name-value pairs on the ledger: in this case, this feature is used to store the certificate data of a device and bind it to an ID that uniquely identifies the device. The ledger is maintained by a special node called Device Manager (DM) and each IoT device within the network interacts with it for the registration of a certificate on the Blockchain. This interaction is described by a specific protocol designed by the authors of the paper. Finally, when two devices whose certificate has been stored on Emercoin NVS want to estabilish a secure communication channel, the certificate verification is performed by comparing the received certificate with the information stored on the Blockchain: if they match, the communication is secure.

Personal contribution

My personal contribution is mainly related to the extension of the original solution for addressing an important security concern that affects the original design. When an IoT device interacts with the Device Manager for the registration of its own certificate on the Blockchain, the aforementioned protocol doesn’t provide any security measure for preventing a potential identity theft. The IoT device autonomously generates its own certificate and it can potentially claim an identity different from its own one. To address this issue, a binding between the claimed identity and some hardware characteristic is necessary, in order to propose a valid challenge-response mechanism for the identity verification. TPM 2.0 technology was a good candidate for solving this security concern. A TPM (Trusted Platform Module) chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper-resistant, and malicious software is unable to tamper with the security functions of the TPM. Every chip is provisioned with a special cryptographic key (Endorsement Key) and its certificate by the chip manufacturer: these elements uniquely identifies a TPM chip, and the Trusted Computing Group (a consortium of various technology companies, responsible for the development of the TPM technology and the definition of detailed guidelines for developing TPM-based applications) has defined a specification that provides a detailed procedure for the identifying a device by using its TPM chip’s Endorsement Key. This procedure has been practically implemented as an extension of the original certificate registration protocol: the Device Manager tracks the binding between each IoT device of the network (model name and serial number) and the corresponding Endorsement Key certificate: during the certificate registration protocol, the IoT device must prove the possession of the private Endorsement Key to be successfully identified. In case of success, the device registration protocol can normally proceed, following the original design’s steps.

Results

The purpose of the tests that have been conducted was first to compare the necessary time to complete a TLS handshake in order to estabilish a secure connection for the two PKI approaches (“standard” and distributed). Additionally, the tests aim at providing a general impression of the necessary time for the entire certificate registration process using the proposed system, also considering the presence of the TPM-related operations that surely require a certain amount of additional time. The measured TLS handshake time using the Blockchain-based approach was greater than the standard handshake time: this is reasonable because for every handshake the extraction of the certificate information associated with a device is performed on a large set of data (the entire Blockchain); Furthermore, the performance difference is slighly emphatized because the experiments using the standard approach were conducted on a test environment, that can’t accurately replicate a normal use-case scenario. Despite of this, the used approach simplify a lot the certificate provisioning for IoT, additionally offering a great availability and protection for data integrity.

User's manual

Preliminary steps

The application is split into two modules: one for IoT devices and one for the Device Manager. The IoT device module must be compiled to be executed and for both the modules the library and other secondary dependencies must be installed: the description of these operations is demanded to Developer's manual.

It's important to perform some preliminary operations to successfully use the application. (Note: in this chapter we assume the presence of a TPM 2.0 chip on each device. In case of a software TPM emulator, further details for the configuration will be provided in Developer's manual)

On the device side, the file iot-device/device identity must contain the model name and the serial number of the device separated by a whitespace;

On the side of the Device Manager, for every IoT device within the network, the folder device-manager/devices must contain a subfolder whose name must be equal to the value stored on the file device_identity previously configured on the corresponding device. This subfolders must contain a file called "configuration", containing the following line

status=INIT

and the Endorsement Key (EK) certificate in PEM format. The Endorsement Key certificate can be retrieved from the device by using tpm2-tools for the execution of the following TPM2 command:

tpm2 nvread 0x01c00002 -o RSA EK cert.bin

This command will save the RSA EK certificate in DER format in a file called RSA EK cert.bin. Then, it's possible to convert a DER certificate into a PEM certificate by using the following OpenSSL command:

openssl x509 -inform DER -in RSA EK cert.bin -outform PEM -out ek cert.pem

Finally, the ek_cert.pem file must be moved from the device to the Device Manager inside the corresponding subfolder.

tpm2-tools and openssl can be installed on Debian-based Linux distributions with the following commands:

sudo apt install tpm2-tools
sudo apt install openssl

Device module

The first module must run in background on each IoT device within the network and can be executed after the compilation by running

sudo ./iot-device/cli-build/iot-device

This section of the application does not require any interaction with the final user: the device basically waits until the Device Manager sends a $M_{init}$, $M_{ownr}$ or $M_{updt}$ message. By default, the status (stored in iot-device/cli-build/configuration) of the device is set to INIT: in this condition, the device accepts the incoming $M_{init}$ messages, but when the certificate registration procedure is completed and the status is set to RUNNING , the only accepted messages are $M_{ownr}$ and $M_{updt}$.

Figure 1 reports the example of an execution of the device software module: the application's logs summarize the entire execution flow already discussed in the previous chapters, also providing a step-by-step description of the TCG protocol used for the identification of the IoT devices. In this example, the execution is stopped because on the other side the DM has to confirm the creation of a new Emercoin transaction before sending back the acknowledgement to the device (Figure 2). When the transaction is created and validated by the Emercoin network, the acknowledgment is received and verified by the device: if no errors occur, the device can update its configuration file and finally store (in iot-device/cli-build/keys/master pubkey.pem) the DM's public key for eventual future interactions. It's important to notice that the directory iot-device/cli-build/keys/ won't include the Attestation Key generated during the certificate registration procedure: this key is permanently stored inside the TPM and every cryptographic operation based on it, is interally managed by the application's code.

The following example reports a configuration file for a device.

STATUS RUNNING
ID 9688180d6365a699dfc69cdd43e042c27663a79dd924654d56d0630bc46ab1fb
EXP_DATE 04/11/2022, 15:35

The ID is the unique label associated with the certificate hash value stored on Emercoin NVS. The expiration date is calculated by adding the number of validity days to the current date at the time of the execution of the registration procedure. Practically, Emercoin measures the expiration date in number of blocks (further details in Device Manager module).

Device Manager module

The second module (device-manager/) is for the Device Manager node. The application can be run using Python 3, by executing the command

sudo python3 main.py

when the current working directory is device-manager/. In this case there's an initial interactive command-line interface: here, the user can select the operation to perform on the IoT devices of its network. When the option is selected, the CLI requires to type the IP address of the interested device and eventual additional information (e.g. the number of validity days in case of a certificate registration). Before the final Blockchain transaction is created, the application asks to the user for a final confirmation.

For the certificate registration process, the user must first select the IP address of the device in the network; if the device is reachable, the application asks to the user the expiration time for the certificate that is going to be created. Also in this case, the application provides some event logs, to track the most important steps of the procedures described in the third chapter. If the user confirms the registration of the device on Emercoin NVS, a notification from the Emercoin Wallet should be quickly received.

If the notification has been correctly received, the transaction's data can be consulted in the "Transactions" tab of the Wallet: the transaction will be pending until the validation after the mining process. As long as the transaction is pending, it won't be possible to retrieve any information about it from the Blockchain.

The record on the top of this list represent the newly generated key-pair for our device. The symbol displayed on the left of the date tracks the depth of the block containing our transaction in the chain: when this symbol becomes a green check mark (like the rest of the transactions displayed in the tab), our transaction starts to be considered secure (because 6 blocks have been "mined" after the one containing the transaction). The necessary time to see the green checkmark is $\approx$ 1 hour (1 block validation each 10 minutes).

Moreover, an overview of the current registered name-value pairs is available in the "Manage Names" tab, where it's possibile to check the "expired" flag to display the information associated the expired name-value pairs. The "value" field can't be correctly displayed because during the certificate registration procedure, the hash value of each certificate is stored as a byte value in hex format (some values are not associated with printable characters). The expiration is expressed in number of days before the expiration: under the hood, Emercoin NVS translates the number of days in number of mined blocks starting from the block containing the transaction. This can be done because the blocks mining rate is always the same, so it's possible to map the number of mined blocks to the number of elapsed days. To provide a general unit of measurement, 1 days is approximately corresponding to 175 blocks.

When the certificate registration process is successfully completed, the subfolder corresponding to the configured device should contain the following files:

1. configuration: basically the same configuration file that's been already discussed for the IoT device module;

2. ek_cert.pem : the device's TPM Endorsement Key certificate in PEM format (this must be already included before the execution of the certificate registration process);

3. iak.pem: the device's Attestation Key created during the TCG procedure, in PEM format;

4. local_pubkey.pem : the RSA public key generated by the IoT device for the creation of the self-signed X.509 certificate that is finally stored on the Blockchain;

The other available operations (ownership transfer and certificate update) follow the same execution flow, but the ownership transfer protocol requires an additional preliminary step: the folder must include a file called new_pubkey.pem containing the public key of the next device's owner, in PEM format.

Finally, the revoke operation is equivalent to the creation of a revoke transaction from the Emercoin Wallet. In this case, the application will ask for the name of the <name,value> pair instead of the IP address of the device like for the other operations.