Skip to main content

Security analysis

The security analysis is structured around assertions which start small and build up into a high-level security model.

Axioms​

The analysis relies on certain axioms which are assumed to be true:

  • TEEs are secure
  • Cryptography used in the KMS is secure
  • Threshold Network and TACo is secure
  • The Scallop protocol is secure and provides authentication of the key of the other side

Analysis of the Scallop protocol itself is out of scope for this analysis.

Assertion 1: The seeds and derived public keys generated by the creator enclave are verifiable.​

The seed is encrypted, combined with derived public keys, signed by a secp256k1 key and exported along with a signature. The creator enclave also runs an attestation service which includes the corresponding public key in attestations. Verifying the attestation verifies the public key which in turn can be used to verify the signature on the encrypted seed + derived keys payload.

Assertion 2: The seeds can be made decryptable only by KMS root servers.​

The seed is encrypted against a DKG key from Threshold Network which allows conditions to be attached to it. While the creator enclave does not hardcode any conditions, it accepts the condition as an initialization parameter which is part of the attestation and is verifiable. Production deployments of the KMS set the decryption condition to being verified on the KmsRoot contract. The KmsRoot contract implements attestation verification and only allows KMS root servers running specific versions of the code to get verified. The contracts do allow privileged users (e.g. governance processes) to add new KmsRoot versions to account for updates in the future, hence it is worth calling out as an assumption.

Assumption: The KmsRoot contract only allows verification of valid and secure KMS root servers.​

Note that it is certainly possible to generate insecure seeds from the creator by setting insecure conditions. Hence, it is important to go through the seed verification process to verify that the seed was encrypted using a secure condition.

Assertion 3: Encrypted seeds can be verified to have been securely generated.​

Start with a version of the creator enclave that allows interaction only through a well defined endpoint which will only export seeds after encryption and signing with an enclave generated key. It's now possible to work backwards through the verification process. Given an encrypted seed and an attestation, first verify that the attestation is valid and has PCRs matching the expected creator enclave measurements. Verify that the user data contains a secure decryption condition requiring verification through a KmsRoot contract. Extract the public key from the attestation and use it to verify the signature on the encrypted seed.

This guarantees that the seed is as secure as the creator enclave, the KmsRoot contract and any enclaves which are allowed by the KmsRoot contract.

Assertion 4: The root server serves only valid enclaves with secrets.​

The root server only exposes the key derivation endpoints behind a Scallop enabled listener. It requires the requestor to provide valid attestations for the connection to be established successfully.

Assertion 5: Applications can protect their secrets from being issued to others.​

The Scallop protocol authenticates the public key of the requestor as part of connection establishment, and effectively proves that the requestor controls the corresponding private key. The root server also expects authentication in the form of a remote attestation which contains the aforementioned public key. Verifying the attestation lets the root server authenticate the measurements of the requestor enclave and issue secrets meant for it and not other applications. The image variant directly uses the measurements to derive keys, while the contract variant uses the measurements to verify against a contract and then derive keys.

The attestation requirement also effectively gives the application control over who is allowed to successfully establish Scallop connections backed by their attestations. Well designed applications can ensure that only the application enclave is allowed access to the key and can obtain secrets.

Note that it is possible for poorly designed application enclaves to compromise the secrets by not properly restricting who has access to either the Scallop key or the attestation generation process to ensure attestations are not generated for secrets outside the enclave. This however is not much different from enclaves compromising secrets after derivation by poorly designed code which exposes the secrets. Good enclave design is always critical to security.

A critical part of the protections is also the transport layer security provided by Scallop. It protects the communication channels from eavesdropping or MITM by a malicious observer.

Assertion 6: Applications can authenticate the secrets they receive.​

It is important for applications to ensure that the secrets they receive are obtained through a secure key derivation procedure. The Scallop protocol lets the application authenticate the x25519 public key of the root server against a known public key derived from a specific seed. This ensures they are communicating with a valid KMS root server which has a specific expected root seed.

Note that obtaining the known public key is not inherently a part of the derivation process. Developers and users are expected to obtain the known public key off-band through the seed verification process and hardcode it on the derive server, thereby binding authentication and key derivation in that enclave to that seed.

Summary​

A well designed application needs to

  • provision the KMS derive server with a secure public key verified off-band
  • protect the secrets and/or the attestation generation process appropriately
  • (for the contract variant) provision the KMS derive server with the correct chain id and contract address
  • (for the contract variant) protect the image id approval processes on the verifier contract appropriately

Given these, the derive server and the rest of the KMS system are designed to securely issue persistent keys to the applications.

The only component not in control of the application is the approval processes of the KmsRoot contract. This was considered an acceptable tradeoff in the interest of keeping Nautilus up to date with security updates.

It is somewhat mitigated by ensuring all critical operations are placed behind a timelock, to give applications advance notice and give them time to inspect any changes. Of course, Nautilus is fully open source, so if applications find any level of control over the approval process unacceptable or would like to implement their own processes, they can always deploy their own copy of Nautilus.