Full Lifecycle Encryption
End-to-end encryption (E2EE) is designed for different forms of messaging, like chat or email. Data is encrypted with the recipients public key and can only be decrypted by the recipients private key. This implies that you know who you are sharing the information with, which is the common scenario of messaging. However, this prevents it from being used in a normal IT system, where someone generates and stores the information somewhere, without knowing who will access it in the future.
HYKER has taken the concept one step further. When we talk about End-to-End we talk about the full lifecycle between the production of data until the consumption of that data. This creates logical endpoints that can be, for instance, a device, but can also be a person, a vehicle, an analytics software, or anything else that produces or consumes data. It’s only in these logical endpoints that data can be accessed in clear text, never at any time or any place in-between.
HYKER Full Lifecycle Encryption (FLE) means end-to-end security for any type of application or communication pattern, effectively removing the need to trust the network, suppliers, cloud providers or anything else in between the production and consumption of data.
The important difference between normal E2EE and HYKER FLE is when you share the encryption key. In almost every other encryption method you start with sharing keys so you know who you encrypt for. With HYKER we share the key at the decryption meaning that new data consumers can be introduced without having to resend or re-encrypt all the data already stored. Dynamic E2EE with full history and granular access control.
Full Lifecycle Encryption with Acces Control Delegation
It is easy to wind up in a binary world when reasoning about end-to-end vs hop-by-hop, especially when considering access control. In systems that are fully hop-by-hop, the central service is in full control. In systems that are fully end-to-end, the end nodes are in full control.
We have talked about why you might not want to give full control to a central server. There are also cases where you don’t want full control in the end nodes either. An example could be an enterprise communication platform where a decentralized security model with elevated control for middle managers could be desired.
The picture below illustrates the differences between centralized, decentralized, and distributed systems.
We solve the binary situation by using delegated access control, making a combination of distributed, decentralized, and centralized trust models possible.
Full lifecycle with delegation of control
Delegated access control is a concept where an end node can voluntarily delegate permission of key sharing to any other node. If an employee delegates the decryption key responsibility to the nearest manager, that manager gains the possibility to let other employees access the data.
Another example is an IoT sensor which should not have any say in who can access the information. That sensor can delegate the access control to the sensor owner or a group of owners.
Full Lifecycle with endpoints that goes offline
Sharing keys at decryption means that the subscriber needs to ask the producer for the key, but what happens if the producer is offline? It might be asleep, out of network access or simply just broken. This would prevent key sharing and make the system less efficient.
You can delegate the control to a management node. This manager would then have the right to allow or say no to a key sharing request. This, without having access to the actual encryption keys.
Full Lifecycle with key delegation as backup
You can also delegate a key as a backup in an Intel SGX secure enclave provided by HYKER service. A key escrow that is inaccessible to anyone centrally, including HYKER. Only a user that can authenticate through the right method can access the key. In essence, it is like an “offline key backup, but in the cloud”.