Intel SGX for key delegation and recoverability

Intel® Software Guard Extensions (Intel® SGX) is an Intel technology for application developers seeking to protect select code and data from disclosure or modification. Intel® SGX makes such protections possible through the use of secure enclaves. Enclaves are protected areas of execution, somewhat comparable to a sandbox. Application code can be put into an enclave via special instructions and software made available to developers via the Intel® SGX SDK.

The authenticity of the remote enclave can also be attested and trusted by a process called remote attestation. In other words, it enables running very sensitive code processing confidential information in insecure environments no matter where it resides. One example of an application where this could be used is a local key storage that can supply a remote service provider (such as a remote login) with a secret key, without revealing it to other, potentially malicious, processes on the local system.

Data-in-use protection using Intel SGX

Data-in-use protection using Intel® SGX

Hyker is combining this technology with Hyker’s RIKS protocol and BankID (or any other third-party identification service trusted by the client) to create what we call Key Delegates. A key delegate can be used to solve the problem of combining fire-and-forget, end-to-end encryption, and recoverability.

Hyker Key Delegation with Intel SGX

The problem: Imagine a device (Alice) that wants to send an end-to-end encrypted message to a device (Bob) that has not yet been registered (i.e. shared its public keys). This happens, for instance, in a scenario where Alice invites Bob to receive information, but Alice needs to send the information before Bob accepts. Maybe Alice needs to sleep to save batteries or is just a very temporary device.

The solution: When Alice invites Bob to be a receiver the key delegate preregisters Bob in the SGX enclave. Alice can then use this preregistered public identity to send her end-to-end encrypted messages to Bob, and promptly go offline. When Bob later goes online and wants to retrieve and decrypt the messages Alice sent to him, he can ask the key delegate to give him his preregistered identity. Bob verifies that the key delegate is indeed a valid key delegate (over IAS), and the key delegate verifies that Bob is indeed Bob (over BankID) and sends the preregistered identity to Bob. Alice does not need to be online during this process.

This solution is also the key to solve much bigger problems than just a single message to a single recipient. For instance, Alice wants to back up all her data, but she knows all of her devices might all break or be stolen, but she also wouldn’t trust cloud services with her data. Using the key delegate she can now preregister her own back-up identity. If she loses all of her keys, she can simply ask the key delegate to give her back-up identity to her and repeat the process.

This is a vital functionality for a robust distributed security system. Even if all the keys are lost for a specific stored dataset, it would be possible to store a backup key centrally, without any central access to the key and data.