Home · docs · provider attestation

Provider attestation

Every production provider registration is backed by a chain that proves the physical Apple device and Secure Enclave key are genuine, binds the prompt-encryption key to that device, and rejects stale or mismatched registration frames. An APNs app-targeted nonce challenge is live and elevates admitted genuine apps to code_attested.

Unfamiliar terms (Secure Enclave, MDA, X.509)? See the glossary.

The five layers

Answer: Umbra attestation stacks six checks: a non-exportable Secure Enclave signing key, managed-device identity, Apple MDA X.509 chain validation, five-minute signed-blob freshness, binding of the prompt encryption key to that signed blob, and an APNs app-targeted nonce challenge for running-code identity.

On a real Mac

Answer: Production providers run the signed Umbra Provider.app, which creates or reloads a profile-bound Secure Enclave P-256 key, signs the attestation blob, and lets the coordinator match that key against fresh MDM evidence.

The production path is the Swift binary inside Umbra Provider.app. It calls, in-process:

// Generate the SE keypair (non-exportable, hardware-backed)
let priv = SecKeyCreateRandomKey([
  kSecAttrKeyType: kSecAttrKeyTypeECSECPrimeRandom,
  kSecAttrKeySizeInBits: 256,
  kSecAttrTokenID: kSecAttrTokenIDSecureEnclave,
], &error) as! SecKey

// Submit the signed blob and prompt-encryption key in the WebSocket register frame
try await coordinator.register(
  attestation: attestation,           // blob + DER signature
  sePublicKey: priv.publicKeyDER(),
  encryptionKey: x25519.publicKey
)

From a shell:

# First review https://tryumbra.dev/download/ and its system-change disclosure.
curl -fsSL https://tryumbra.dev/install.sh | sh
# The first install starts guided setup automatically.
umbra status

The public DMG is Developer ID-signed, notarized by Apple, and published with a separate SHA-256 sidecar. The download page documents every local change and the complete removal flow before installation.

Development mode

Developers can still run local/synthetic tests from the private repo, but those paths are explicitly insecure and must not receive public prompts or accrue payable earnings.

The registration freshness protocol

provider                              coordinator
  |                                       |
  |  SE_Sign(canonical({                   |
  |    publicKey: se_pub,                  |
  |    encryptionPublicKey: x25519_pub,    |
  |    serialNumber,                       |
  |    timestamp                           |
  |  }))                                  |
  |                                       |
  |  WebSocket first frame: register       |
  |  { blob, signature, x25519_pub }        |
  |                                       |
  |  verify: signature, 5-min timestamp,   |
  |          MDM/MDA evidence, serial,     |
  |          freshness + X25519 binding    |
  |                                       |
  |  <- registered ok or register_error    |

If the signature is invalid, the timestamp is stale, MDM evidence is missing, or the prompt-encryption key does not match the signed blob, the coordinator rejects the registration and closes the socket.

Coordinator verification (Go)

Answer: The Go verifier checks the SE signature, five-minute freshness, coordinator-held MDM/MDA evidence, serial binding, and the signed X25519 prompt key. Any failure rejects registration.

The full verifier is in coordinator/internal/verifier/ and the MDM binding code is in coordinator/internal/mdmtrust/:

1. Verify the Secure Enclave signature over the canonical JSON blob.
2. Load fresh MDM evidence for the same device and provider key hash.
3. Verify the Apple Enterprise Attestation chain and freshness nonce in that evidence.
4. Cross-check serial, freshness binding, and the signed X25519 prompt-encryption key.

All checks fail-closed. Test vectors live in coordinator/internal/verifier/, coordinator/internal/mdmtrust/, and provider/Tests/UmbraProviderTests/.