Skip to main content

Key Management Systems

A key management system primarily deals with the generation and distribution of cryptographic keys to applications. For example, an application might need database credentials in order to access the database. A natural question is then how is the credential generated and managed? Not only does it need to be secure, it needs to be robust enough to dynamically handle application servers spinning up and shutting down or crashing.

The traditional way of solving this is by using a separate key management system that holds credentials and hands them out to applications, usually after authentication. Examples include AWS KMS, Hashicorp Vault, etc.

In the Oyster context, there are additional considerations. While traditional KMS systems provide security through authentication, they do not attempt to secure credentials from the host. This however is an important feature provided by Oyster enclaves where even the host cannot inspect enclave secrets. Therefore, any KMS solution for Oyster has to be enclave aware and ensure all the enclave guarantees are maintained.

Further, since Oyster enclaves cannot persist secrets by themselves during restarts, the KMS serves as a critical component providing secrets that can persist across restarts and opens up new design possibilities.

Key Derivation​

Before looking into how Oyster provides these guarantees, it is important to understand the closely related concept of key derivation. Key derivation is the process of deriving random seeds starting from another random seed (the root) and a known salt (usually the derivation path), by applying deterministic one-way cryptographic operations providing the following properties:

  1. The root seed cannot be obtained from the derived seed.
  2. The derived seed always can be obtained as a function of only the root seed and the derivation path.
  3. Different derivation paths result in different derived seeds.
  4. Derived seeds of one or more paths cannot be used to derive the seed of another unrelated path.

These properties effectively combine to provide a way to securely derive keys for different applications from a single root seed while still maintaining the security properties of independently generated keys. This allows a KMS system to store only the root seed and simply derive the application credentials at runtime when an application asks for it, making it require constant size storage to manage potentially infinite application keys. Note that key derivation can be applied recursively! The application can in turn derive different keys for different use cases.

In the Web3 space, a very common example is HD wallets, where a practically infinite number of wallets are derived from a small starting mnemonic.

Sketching out a KMS​

Designed with key derivation at its core, a KMS for Oyster might look like the following:

  • A given enclave image identified by the PCRs and maybe some user data (to support apps with same enclave code but different runtime config) can be used to define an "application".
  • A KMS server running on Oyster can hold a root seed and provide key derivation services to enclaves.
  • The KMS server needs to authenticate enclaves asking for derivation to obtain PCRs and user data.
  • The PCRs and user data should be part of the derivation path, to ensure different applications get different keys.
  • Communication around secrets should happen over a secure channel to prevent MITM attacks.
  • The root seed should be well persisted so the entire KMS system can be rebooted from scratch if needed.
  • The root seed should only ever exist in plaintext form inside very specific enclaves that properly secure it and exist only in ciphertext anywhere else.

Nautilus​

Nautilus, Oyster's KMS, implements a secure KMS through careful design of several interlocking components.

Threshold network​

Threshold network is a network of nodes that allows encryption of data against a distributed key held by nodes of an MPC network. Decryption conditions can be attached to the encrypted data to ensure it can be decrypted only by requesters meeting specific requirements.

KMSRoot contract​

The KMSRoot contract manages a list of KMS root servers. Servers can only be verified on the contract through attestation verification against a list of approved enclave images.

KMS creator​

The KMS creator is responsible for securely generating the root seed. After generation, the seed is encrypted against a distributed key on Threshold Network with decryption conditions attached to allow decryption only by enclaves verified in a KMSRoot contract, i.e. KMS root servers. The creator runs in an enclave and only exports the key after encryption.

Once generated, the encrypted seed can be stored indefinitely and fed into KMS root servers long after the creator is dead.

KMS root server​

The KMS root server provides key derivation services to application enclaves. It runs in an enclave and uses the Scallop protocol to authenticate the application enclaves and securely derive keys based on PCRs and initialization parameters. The root server is loaded with an encrypted seed which it can decrypt after verification in the KMSRoot contract.

KMS derive server​

The KMS derive server runs inside application enclaves and derives keys from the root servers. It uses Scallop to authenticate the KMS root server, both PCRs as well as the encrypted seed the root server was loaded with. It then provides key derivation services for other applications running in the enclave.

Learn more​

Check out the technical reference for Nautilus to learn more in depth about the gory details and how it works: