Hardened Encryption is an ARCADIAN-IoT component that is responsible for securing the data at rest or in transit produced by the devices/persons participating in the platform.
With the component we address/improve the following challenges:
- Simplification of key management: We build the component based on the Attribute Based Encryption (ABE) paradigm that enables encrypting data with fine grained access policies. This means that the users/devices can specify who can access the data they encrypted, where the final receivers can be multiple groups of users or single devices. This approach eliminates the need for a Certificate Authority with a complex distribution protocol, or a central authority that would have access to all the data, hence presenting a risk.
- Adding hardware-based Root of Trust (RoT) information to the encrypted data: When the data is encrypted, it is enhanced with a hardware based signatures that give guaranties that the data originates from the specific device. This implies that any receiver as well as any intermediate entity can verify (even before decrypting the data) that the source of the data is correct with strong hardware based guaranties. This prevents various types of attacks, such as impersonation attacks and is a step towards the zero trust security.
- Decentralized key management: We further address the issue of a central component that would be able to generate keys/certificates to decrypt secured data or impersonate devices, by replacing it with a decentralized service that follows a multi-party computation protocol to generate private keys for the ARCADIAN-IoT devices. This way, even if one of the nodes in the decentralized service is compromised, the protocol remains secure and the attacker gains no advantage.
The Hardened Encryption component provides implementation of ABE schemes to encrypt data on multiple platforms. By using ABE when data is encrypted, a policy needs to be specified. This policy specifies who can decrypt the data, for example, one could specify that the data can be decrypted only by a specific device, the administrator of the system, or the consumer of the data. In particular, the encryptor does not need to obtain public keys/certificates of the receivers to be able to secure the data. This functionality simplifies the traditional approach in which either the encryptor would need to establish a shared key with all the receivers and encrypt for all of them, or an additional trusted authority would be needed to distribute keys to all the participants for each message. Moreover, since the data is encrypted with a policy by the data producer itself, no additional third-party trust assumption is needed.
The simplest approach in (secret) key management in a platform such as ARCADIAN-IoT is to have a central component/server that has or generates all the keys in the system and distributes them to the authorized devices. Such a component presents a huge risk since if it is compromised, the attacker can gain access to all the data in the platform. Hence, we give special attention to mitigating this risk, by decentralizing the key management. In particular, we implement the key management component as a decentralized protocol running on multiple servers/nodes. The approach of decentralization is known also as multi-party computation, in our case the “computation” is the generation and distribution of keys. The decentralized protocol has the benefit that if multiple key management servers become compromised, the attacker cannot obtain any benefit out of it unless all the servers have been breached. In addition, we share public information in the system on a permissioned blockchain to enhance trust in the information, since a blockchain is immutable and again decentralized.
The hardware-based RoT provides an added layer of security since it enables proving the origin of the data (i.e. authenticity of data) by attaching eSIM-based signatures to the encrypted data. This means that the payloads are signed with signatures that can only be generated by a specific hardware. An attacker cannot extract any private key out of a device, that would enable him to impersonate the device. Hence when a receiver obtains encrypted and signed data, it has strong guarantees that the data was truly generated by the specific device and was not altered by any intermediates.
Author: Tilen Marc, XLAB