Access Control

Every secret in Enclave Vaults carries a SecretPolicy that controls who can retrieve it. There are two retrieval paths, each with its own authentication mechanism.

GetSecret Dual-Path Auth

Path 1: OIDC Owner

The secret owner retrieves their own secrets using their OIDC token. No mutual RA-TLS required. The vault checks that the token's sub claim matches the secret's owner_sub.

Path 2: Mutual RA-TLS TEE

A remote TEE retrieves secrets via mutual RA-TLS. The vault:

1. Requires a TLS client certificate (mutual RA-TLS).
2. Extracts the attestation quote from the peer certificate.
3. Verifies the quote via the configured attestation server(s).
4. Checks the measurement against the policy whitelist.
5. Verifies bidirectional challenge-response binding (if a nonce is present).
6. Checks the optional bearer token from the secret manager.
7. Checks required OID claims.

Secret Policy

Each secret carries a policy that is evaluated on every GetSecret request via the RA-TLS path. The OIDC owner path bypasses policy evaluation.

OIDC Roles

Token Delivery

Since Enclave OS Mini uses a frame protocol (not HTTP), the OIDC bearer token is passed inside the JSON envelope as an "auth" field:

{
  "auth": "eyJhbGciOiJSUzI1NiIs...",
  "StoreSecret": {
    "name": "customer-123-dek",
    "secret": "base64url-encoded-bytes",
    "policy": {
      "allowed_mrenclave": ["abcd1234..."],
      "ttl_seconds": 604800
    }
  }
}

The auth layer strips "auth", verifies it via JWKS, and populates OidcClaims in the request context. The vault reads sub for ownership checks and roles for role verification.

Owner Identity

The OIDC sub claim uniquely identifies the secret owner. The OIDC subject is the vault namespace. KV keys use the format secret:{owner_sub}:{name} for namespace isolation between owners.

Secret Manager (Defence-in-Depth)

The secret manager is a separate actor whose role is to issue a bearer token at GetSecret time. This is optional: if a secret's policy has no manager_sub, no bearer token is required.

Remote attestation proves what code is running, but if the attestation infrastructure were compromised (e.g. a firmware bug allowing forged quotes), an attacker could present a fake measurement. Requiring a fresh bearer token from the secret manager means the attacker needs two independent things to retrieve a secret: a valid quote and a token from the manager.

Threat model:

  RA compromised alone            -> blocked (no manager token)
  Manager compromised alone       -> blocked (no valid quote)
  Both compromised                -> secret exposed (defence-in-depth breached)

Security Properties