Skip to main content

Architecture

Components​

Nautilus is composed of the following components:

  1. KMS creator - Responsible for generating encrypted root seeds with appropriate access controls.
  2. KMS creator enclave - Enclave that packages the KMS creator.
  3. KMS creator verifier - Verification utility for encrypted seeds generated by the creator.
  4. KMS derive utils - Utility library that implements key derivations.
  5. KMS root server, image or contract variant - Root server that provides key derivation services to application enclaves.
  6. KMS root server enclave, image or Arbitrum One variant - Enclave that packages the KMS root server.
  7. KmsRoot contract - Contract that verifies and tracks KMS root servers.
  8. KMS derive server - Server that requests derived keys from the root server and provider further key derivation services. It is meant to be part of application enclaves.

It also depends on other components not specific to Nautilus:

  1. Threshold Network - Provides threshold encryption capabilities that lets the creator encrypt root seeds against a distributed key and attach decryptions conditions as needed.
  2. Scallop protocol - Provides authentication and transport layer security for enclave communications to ensure they cannot be MITMed.

Bootstrapping​

The bootstrapping phase of the KMS happens in the following order:

Preparations:

  1. A DKG ceremony is executed on Threshold Network.
  2. The KMS creator enclave is built along with all the dependent components, including the KMS creator.
  3. The KMS root server enclave is built along with all the dependent components, including the KMS root server.
  4. The KMS creator verifier is built.

Root server tracking:

  1. A KMSRoot contract is deployed restricting verification to specific KMS root server enclave images.

Seed generation:

  1. The KMS creator enclave is deployed on Oyster. The initialization parameters specify a decryption condition that uses the KMSRoot contract address, effectively binding all generated seeds to be decryptable only be addresses verified on the KMSRoot contract.
  2. An attestation is obtained and preserved for posterity.
  3. A creator message is generated and preserved. Apart from an encrypted seed, it also contains a secp256k1 and a x25519 public key derived from the seed, which can be used to authenticate root servers with that seed.

Root servers:

  1. The KMS root server enclave is deployed on Oyster. The initialization parameters specify the encrypted root seed.
  2. The root server is verified on the KMSRoot contract, currently through ZK-based attestation verification.
  3. The root server decrypts the encrypted seed and starts up the derivation service.

At the end of the bootstrapping phase, we have a verifiably generated encrypted root seed and KMS root servers ready to provide KMS derivation services to application enclaves.

Secret derivation​

The root servers expose endpoints that application enclaves can use to derive secrets specific to their application. These endpoints are secured by the Scallop protocol which relies on enclave attestations to both secure the connection as well as authenticate measurements on either side. The derive servers aim to authenticate the derived x25519 public key of the root server (see step 8 above). The root server aims to authenticate the image id (PCRs + user data) of the derive server in order to derive the right key (for the image variant) or verify it on a contract (for the contract variant).

Once a Scallop connection is established successfully, the root server provides derivation endpoints over HTTP to derive secrets. Depending on the variant, one or more of the authenticated parameters (PCRs, user data and key) might be mixed into the key derivation path. The derive server in turn provides key derivation endpoints that applications can use to further derive secrets for different purposes.

Public derivation​

The root server also enables derivation of public keys or wallet addresses corresponding to the derive server endpoints. This facility is provided without any authentication requirement and allows developers and users to derive them in advance without ever deploying an application enclave. The responses include a signature in the header that is signed by the derived secp256k1 key (see step 8 above).