Skip to main content
Identity Instrument is an enclave-backed service (TEE in AWS Nitro Enclaves) responsible for authenticating users via email OTP or an OIDC-compatible identity provider (Google, Apple). It binds a device-generated Auth Key to the authenticated user, and uses an Identity Signer to sign session attestations. Applications never handle IdP client secrets directly; the Identity Instrument mediates the exchange and issues the final signature.

​
Cryptographic attestation

Identity Instrument is deployed from an EIF (Enclave Image File) published as a public GitHub release. An EIF is built deterministically from the codebase, and a set of measurements are derived from all the code included in the build. A build at a specific commit always produces the same measurements. These measurements are attested by the AWS Nitro system in a document called a cryptographic attestation, signed by the AWS PKI. It can be validated by anyone. The attestation is included in every request to AWS KMS, which verifies its validity. Trusted Third Parties set up the KMS keys with policies that only allow access if the correct EIF is deployed, identified by its measurements. Every response from Identity Instrument contains the attestation in the HTTP header X-Attestation-Document. This makes the service publicly verifiable.

​
Authentication modes

​
OTP (email)

The OTP mode sends a randomly generated code directly to the user’s email address. That destination becomes the identity with which the Auth Key is associated.

​
OAuth with PKCE (Google, Apple)

The OAuth AuthCode + PKCE mode retrieves the user profile from an external Identity Provider. By using PKCE, the client is never able to exchange the authorization code, even if it holds the Client Secret. A random Code Verifier is generated and stored securely inside the enclave.

​
Encryption pool

Identity Instrument encrypts its data using AES-256-CBC with private keys selected randomly from a global cipher key pool. Each cipher key is split into 3 parts using Shamir’s Secret Sharing, requiring a minimum of 2 parts to decrypt. Each part is encrypted using a different remote AWS KMS encryption key. Two of the KMS keys are owned and controlled by separate Trusted Third Parties, organizations unaffiliated with Sequence. The third KMS is owned by Sequence. This means each signer private key is secured by a 2-of-3 remote key setup where no single entity has access to the data. Losing one Trusted Third Party does not compromise the system, provided the other two are still active.

​
Security properties

  • Applications never receive IdP client secrets. Only the enclave performs the OAuth exchange.
  • PKCE prevents code interception during OAuth redirects.
  • Enclave attestation lets ecosystems verify they are talking to the correct service binary.
  • Key rotations and config migrations are supported without downtime via pool generations.

​
References