Architectural Overview
The party roles, the protocols and the network layer are described in Key Concepts and Architecture - Key Concepts. What follows is what changes when the cloud nodes run inside a TEE.
The deployment
Mobile holds one of the three keyshares and is the party that initiates every protocol. Requests are signed with a device key held in the phone's own secure enclave, and the Auth Service checks that device before a protocol is allowed to run.
Cloud Node 1 is the phone's only contact point. Its enclave runs the Trio node and the Auth Service, and it takes part in every protocol: key generation, signing and recovery.
Cloud Node 2 is a backup. It takes part in key generation and recovery, never signs, and the app never talks to it directly.
The Auth Service shares the enclave with node 1, so no attestation is required between them. This cookbook deploys our reference implementation, which authenticates users against Auth0: the app presents an Auth0 access token, and the Auth Service validates it against Auth0's JWKS before any protocol is permitted to run. It is intended as a starting point, and can be replaced with your own authentication service.
KMS holds the key that protects the keyshares, with a policy that grants decryption only to an enclave presenting a valid attestation document. Even with root on the parent instance, an operator cannot decrypt a keyshare.
This cookbook keeps everything in a single AWS account for simplicity. In production the KMS key belongs in a separate account, so whoever administers the cloud nodes cannot change the policy that constrains them.
Why the enclave changes things
Two properties follow from running the node inside a TEE, and they are the reason for most of the setup work later:
Keyshares are useless outside the enclave. They sit in S3 encrypted with a key that KMS releases only against a matching attestation document, so backups, snapshots and a compromised host all yield ciphertext.
The enclave has no network. It reaches Auth0, KMS, S3 and Secrets Manager over vsock through proxies on the parent instance, with TLS terminating inside the enclave. The parent moves bytes it cannot read. This is why the deployment configures a proxy per outbound destination.
Terms used in this cookbook
MPC, keyshares, key generation and signing are defined in Key Concepts. These are the AWS Nitro terms that appear throughout the deployment steps.
Trusted Execution Environment (TEE) — a confidential environment where nobody, including a user with root on the host, can read or alter the workload's memory. Here it is an AWS Nitro Enclave.
Parent instance — the EC2 instance hosting the enclave. It boots the enclave and relays its
traffic, but cannot see inside enclave memory. Each node is an m5.xlarge, with 2 vCPU and 8 GiB of
it given to the enclave.
Enclave image file (.eif) — the bootable image of everything inside the enclave: the Trio node
and, on node 1, the Auth Service.
Golden AMI — the image the cloud nodes launch from, built by Silence and shared with your
account. It carries the .eif, one per node, and the PCR0 of that image is what the KMS key policy
pins for attestation.
Attestation document — proof, signed by AWS and obtainable only from inside a real enclave, that records measurements (PCRs) of the image that booted. KMS checks it before releasing the key. In debug mode, as used here, those measurements are all zeros. See the AWS documentation.
KEK and DEK — keyshares are protected with envelope encryption: a data encryption key (DEK) generated inside the enclave encrypts the keyshare, and a key encryption key (KEK) in KMS encrypts the DEK.
vsock — the only channel between an enclave and its parent, and therefore the path every outbound call takes.