Key Management Practice

1. Introduction

This document provides an overview of most cryptographic keys that are used by Sharemind HI. Some of these keys are managed by Cybernetica AS based on the internal key management policy. However, many of the keys are managed by external stakeholders. For each key we cover its cryptographic properties, owner, primary functions, lifetime, protection mechanisms, and give a short technical overview of how the key is used by Sharemind HI and it relates to other keys.

Every Sharemind HI deployment has the following roles that can partially overlap between stakeholders:

  1. Cybernetica AS (Cyber) - the software platform provider.

  2. Coordinator - coordinates between clients and Cybernetica AS. Is responsible for specifying (and possibly implementing) the software. The Coordinator also coordinates the agreement of the analysis that will be run.

  3. Clients - data owners, output consumers and auditors.

  4. Host - the server platform host. A hosting service (e.g. cloud) provider, or any of the project stakeholders that has the capability to host Intel® SGX enabled hardware.

  5. Server - a physical Intel® SGX enabled server hosting the Sharemind HI service. The server is supplied by the host. As Sharemind HI is hosted on a single machine we use the terms Host and Server interchangeably.

Intel is implicitly involved in the processes by offering the hardware platform, supplying Intel® SGX software libraries, providing technological support, and facilitating remote attestation via the Intel® Attestation Service (IAS).

2. Specification of Asymmetric Keys Used in Sharemind HI

Each Sharemind HI deployment requires following keys:

  1. ESK - Enclave Signing Key

  2. RDK - Root Deployment Key

  3. DK - Deployment Key

  4. CK - Client Key

  5. STK - Server TLS Key

  6. PTK - Cybernetica AS IAS Proxy TLS Key

  7. PSK - Cybernetica AS Software Package Signing Key

  8. ICA - Intel Attestation Report Signing CA Certificate

They can be summarized as follows:

Name Algorithm Generated by Signed by/with Primary function Default lifetime Protection mechanism

ESK

RSA 3072

Cyber

Not signed

Enclave signing

N/A

Offline

RDK

EC p256v12

Cyber

Self-signed

Deployment authenticity

10 years

Offline

CK

EC p256v1

Client

DK

Access control

1 year

Not protected

STK

(solution specific)3

Host

External CA

TLS authorization

(solution specific)3

(solution specific)3

PTK

RSA 4096

Cyber

External CA

TLS authorization

2 years

Not protected

PSK

RSA 4096

Cyber

Self-signed

Package signing

1 year

HSM4

ICA

RSA 3072

Intel

Intel CA

Remote attestation

2050

Unknown

Offline1: Offline keys are encrypted at rest.
EC p256v12: We use the curve prime256v1 as this is natively supported by Intel® SGX SDK. A curve with higher security margins will require side-channel hardened external dependency.
3: These values are solution specific and can be chosen according to the requirements of the solution. HSM4: Hardware Security Module

Keys generated by Cybernetica AS are managed based on the Cybernetica internal Key Management Policy document.

Private components of key pairs are never exchanged between participants. Public keys are sent for certificate signing requests (DK, CK, STK, PTK) and public key registration.

Sharemind HI takes a conservative policy on key compromise. If a key is suspected to be compromised a new key must be generated and all associated procedures (depending on the kind of compromised key) must be followed (such as certification and re-configuration). All relevant parties must be notified on key compromise and the compromised key must not remain in use.

2.1. Enclave Signing Key

The Enclave Signing Key (ESK) is used by Cybernetica AS to sign enclaves. Intel has allowlisted the ESK of Cybernetica for use in remote attestation when using EPID attestation on legacy systems. The ESK is verified during enclave remote attestation and can also be used by other parties to verify authenticity of enclaves.

For safeguarding the ESK we follow both the Cybernetica AS Key Management Policy and additional guidelines set by Intel (Safeguarding the Enclave Signing Key).

Test enclaves are signed with a distinct RSA key pair which is not registered with Intel service.

The client configuration contains the hash of the public component of the ESK(s).

2.2. Root Deployment Key

The Root Deployment Key (RDK) is self-signed by Cybernetica AS.

The public component of this key is embedded in the enclave binary. It is used by the enclave to verify that the Section 2.3 is signed with the RDK.

2.3. Deployment Key

A Deployment Key (DK) is generated by the Coordinator for each unique Sharemind HI deployment. The key is signed with the RDK (by Cybernetica AS) to create the corresponding public certificate. The enclave verifies that the deployment certificate is signed with the RDK.

The DK certificate is used as an intermediate certificate so that Cybernetica AS could delegate the signing of client keys to the Coordinator.

Cybernetica AS follows internal Key Management Policy when issuing certificates.

The certificate is configured via the Server.DeploymentRootCertificateFile option in the server configuration file.

2.4. Client Key

A Client Key (CK) is a key generated by the end user. The CK is signed with the DK (by the coordinator) and is used for access control, authorization (TLS and signatures), and key agreement during remote attestation (see below).

With default configuration the TLS server verifies that the CK certificate has been signed with the DK. This check can be disabled for web-based Sharemind HI applications where we use a gRPC gateway to communicate with the Client web-browser. In that case mutual authentication can be on the proxy side.

Regardless, the enclave also verifies that the CK has been signed with the DK.

All messages sent by the client to the server are signed with the corresponding CK and the server verifies these signatures. Nearly all audit log entries are direct messages from the client and are hence signed.

During remote attestation the CK is used to negotiate a session key between the client and the enclave. The key agreement process is based on elliptic-curve Diffie-Hellman, details of which are beyond the scope of this document. The negotiated key is not accessible to the host.

The client configuration contains the private key and certificate.

2.5. Server TLS Key (STK)

The server requires a private key and a public certificate to establish TLS connections with clients. Certificates from trusted CAs and self-signed certificates are both supported. The Common Name field in the certificate must match the hostname in the server configuration.

The server TLS key can be either an already established key or generated for a particular Sharemind HI deployment. The management of STK is up to the server host.

The private key and certificate are configured as the Server.ServerKeyFile and Server.ServerCertificateFile options in the server configuration file.

3. Other tangentially related asymmetric keys

3.1. Cybernetica AS IAS Proxy TLS Key

Cybernetica AS IAS Proxy TLS Key (PTK) is used to encrypt traffic between clients and the IAS Proxy. The proxy is only involved during remote attestations to proxy the communication between a client and the IAS. The TLS encryption is not strictly required as the SIGMA protocol is designed to be secure over open communication channels.

The proxy URL is configured via Attestation.IAS.ServerURL option in the server configuration file.

3.2. Cybernetica AS APT Package Signing Key

Cybernetica AS APT Package Signing Key (PSK) is used to sign APT packages hosted by Cybernetica AS for Sharemind HI. The package signing key is protected using the same procedures as the enclave signing key, apart from being stored in (and generated by) an OpenPGP smart card. Repository keys need to be updated at least once a year.

Connections to APT repository are protected with TLS using certificates issued to Cybernetica AS by an external CA.

3.3. Attestation Report Signing CA Certificate

The IAS responses are signed by the Intel root certificate. The Sharemind HI client application uses this key to verify that remote attestation responses are in fact produced by Intel.

Cybernetica AS delivers this certificate via client packages, but it is also publicly available from Intel (Attestation Report Root CA Certificate).

The client configuration contains this root certificate.

4. Specification of Symmetric Keys Used in Sharemind HI

Below we describe the few symmetric keys used by the Sharemind HI enclaves:

  1. SK - Session Key

  2. KEK - Key Encryption Key

  3. DEK - Data Encryption Key

  4. REK - Audit log Root Encryption Key

  5. EEK - Audit log Entry Encryption Key

Name Algorithm Generated by Primary function Lifetime

SK

ChaCha20Poly1305-IETF

Key agreement

Session encryption

Enclave lifetime4

KEK

AES-128 GCM

Client, Task Enclave

DEK encryption

<1 year

DEK

BLAKE2B-128 & AES-128 GCM

Client, Task Enclave

Data encryption

<1 year

REK

AES-128

Enclave

Audit log encryption

<1 year

EEK

AES-128 CTR

Enclave

Audit log encryption

Ephemeral

Enclave lifetime4: Client can regenerate the session key at will. The key will be lost whenever enclave is stopped (for example, the host is rebooted)

Various other symmetric keys that are managed by Intel® SGX (Intel SGX Explained) are out of scope for this document.

4.1. Enclave-Client Session Key

A Session Key (SK) is agreed upon between an enclave and a client during remote attestation. On the server side this key is only stored within encrypted SGX enclave memory and is never persisted on disk. Whenever the enclave is stopped the key is lost and the client must again remotely attest the enclave to establish a new session.

The Session Key is used to encrypt further communications between the client and the enclave, using the libsodium library. The encrypted communication is transported over a secure TLS channel.

Clients can store the SK in any suitable storage medium (the file location is configurable). Cybernetica AS does not offer a protection mechanism for this key.

4.2. Key Encryption Key & Data Encryption Key

When a producer uploads data to a Sharemind HI topic, the following steps are automatically taken by the client application:

  1. Queries the core enclave to verify that it has permissions to upload data to that topic.

  2. A Key Encryption Key (KEK) and a Data Encryption Key (DEK) are generated.

  3. The DEK is used to derive the actual keys using libsodium. The resulting key is used to encrypt the data with AES-128- GCM.

  4. The encrypted data is uploaded to the Sharemind HI Server over the mutually authenticated gRPC TLS connection. No Intel® SGX technology, e.g. no enclave, is involved in this process and the encrypted data is directly stored on the server.

  5. The DEK is encrypted using the KEK with AES-128-GCM.

  6. The KEK is sent to the key enclave over a secure channel. The KEK is never accessible to the host and is only readable by the key enclave and the dedicated consumers.

  7. The encrypted DEK is sent to the core enclave over a secure channel.

  8. Discards the KEK and DEK.

The key enclave and core enclave store the keys (KEK and encrypted DEK, respectively) in encrypted memory and persists it on disk. For persisting data on the disk we use the Intel® SGX SDK data sealing interface (Intel Software Guard Extensions Developer Reference for Linux OS). The sealed data is only readable by this particular enclave: it is encrypted with a key derived from the root sealing key (Intel SGX Explained), the specific enclave attributes. If an enclave seals data on one CPU, it will not be able to unseal the same sealed data while running on some other CPU.

4.3. Audit log encryption keys

We have followed Secure Audit Logs to Support Computer Forensics in designing the auditing mechanism.

To offer some protection against overly curious clients audit logs are encrypted using symmetric 128-bit keys generated and stored within the enclave. The log is encrypted using the AES-GCM scheme. Each client action and all other audit log state changes are logged. The log entries are hash-chained together. Thus, the audit log hash uniquely represents the state of this particular enclave deployment.

More precisely, the enclave stores two keys for the audit log: the Root Encryption Key, and the Entry Encryption Key. When a new entry is logged it is encrypted with a key derived from the previous Entry Encryption Key. The old Entry Encryption Key is replaced with the newly derived key (SHA-256). The first log Entry Encryption Key is derived from the Root Encryption Key. The Root Encryption Key is randomly generated on the initial enclave startup.

Auditors can download the Root Encryption Key and, hence decrypt the entire log.