Skip to main content

Nautilus KMS

Technical reference for the Nautilus key management system. For a gentler introduction, please refer to the KMS concept:

Goals​

The Nautilus system has the following goals:

  • Provide a KMS that can be used by application enclaves to derive secrets
  • That persist across restarts
  • That lets copies of the same application derive the same secrets
  • While preserving the enclave security guarantees afforded to secrets within application enclaves
    • Secrets are safe from third parties/eavesdroppers
    • Secrets are safe from the host
    • Secrets are safe from other applications

Variants​

Notice that the definition of an "application" is deliberately vague. This is because conceptually, a KMS works the same regardless of how applications are defined. Where it really matters is in security of the secrets. By definition, a given application is able to derive the same secrets from the KMS regardless of who is running it or when. If not careful or restrictive enough, you might end up exposing secrets to untrusted or malicious enclave images and compromise the security of your application.

While you can come up with and implement your own definition of an application that is secure, Nautilus provides two variants that should cover most use cases.

Image variant​

The simpler but more rigid variant. An application is defined by enclave PCRs and user data. This ensures enclave images with different code and/or initialization parameters get different secrets.

Default to this variant unless there is a very specific need for other variants and proper care is being taken during implementation.

Contract variant​

The more powerful but sharp variant. An application is defined by a contract on a specific blockchain. The root server looks for enclave keys verified in the contract to determine whether the enclave is considered the same application or not.

This is extremely flexible and powerful since the contract defines what enclaves are acceptable and can encode arbitrary logic. It primarily enables upgradeable applications where the contract can approve new enclave image versions.

Needless to say, this variant is only as secure as the contract implementing the approval process. Insecure implementations can easily end up compromising the secrets.