Security model
A self-hosted VTA is only as trustworthy as the machine you run it on: whoever controls that host can, in principle, read its memory. An Affinidi-hosted VTA removes that dependency. It runs inside a Trusted Execution Environment (TEE), a hardware-isolated environment that keeps key material confidential even from the host it runs on. It also lets you verify independently that the software holding your keys is the exact, audited build you expect. This is the same custody guarantee the VTI specification requires: a VTA performs key operations on a caller’s behalf rather than exporting the key for the caller to use.
Trusted Execution Environment (TEE)
An Affinidi-hosted VTA runs inside an AWS Nitro Enclave. A Nitro Enclave is a hardware-isolated compute environment with no persistent storage, no interactive access, and no network interface of its own: the only way in or out is a narrow, defined channel to its parent instance. Key material generated or held inside the enclave cannot be read by a compromised host machine, because there is no operational path to it, not just a policy against using one.
This gives you three concrete benefits over a conventional hosted service:
The master seed is encrypted at rest under a Key Management Service (KMS) policy that only releases it to an enclave with the correct attestation. Key material exists in plaintext only inside the enclave’s own memory, unreadable even to Affinidi as the operator.
The software running inside the enclave is cryptographically measured at boot, so you don’t have to trust Affinidi’s description of what it runs. Check the measurement yourself before you connect. See PCR0 pinning below.
Affinidi-hosted TEEs share the same enclave image across tenants, so PCR0 alone can’t tell two tenants’ enclaves apart. Each tenant’s KMS policy also checks the calling parent instance’s Identity and Access Management (IAM) role, so only that tenant’s own fleet can unlock its key. A leaked sealed blob stays unreadable to any other tenant’s enclave.
Affinidi Portal provisions every Affinidi-hosted VTA this way.
PCR0 pinning
A Platform Configuration Register (PCR) is a cryptographic measurement the enclave produces at boot, covering the exact software image it is running. PCR0 measures the enclave image itself (the built software); PCR8 measures the signing certificate used to sign that image. Together they let you confirm, cryptographically, that the enclave you are about to trust is running the exact build you expect, not a substituted or tampered one.
Pinning means telling Personal Network Manager (PNM) the PCR0 value you expect before it connects. When you run the bootstrap command, PNM receives the enclave’s live attestation quote, compares its measurement against the value you pinned, and only proceeds if they match exactly. This is a hardened Trust On First Use (TOFU) model. In plain TOFU a client records whatever identity answers first; here the first connection is additionally checked against the value you pinned, so an enclave you did not expect is refused rather than recorded as trusted.
Without pinning, hardware isolation alone still stops the host from reading memory. What it cannot tell you is whether the software inside the enclave is the audited build, or some other image presenting the same interface. Pinning is what turns “isolated” into “verified.”
See Bootstrap PNM against the VTA for the pinning step itself, including where to find your VTA’s PCR0 value and the exact command to run.
What the enclave guarantees
- Fail-closed on mismatch. If the measured software does not match the PCR0 value you pinned, the VTA refuses the connection rather than continuing with a weaker guarantee. A mismatch always stops the bootstrap outright.
- Anti-rollback protection. An external, tamper-resistant counter blocks an attacker from restoring an older backup to roll the enclave back to a previously compromised build. This protects against a rolled-back storage or backup image; it does not protect against a fully compromised parent host with root access.
Trust boundary
A private key is never exported as a side effect of an operation, whether hosted or self-hosted: the VTA performs the operation and returns only its result. Key material leaves only when you explicitly request it, through sealed transfer, encrypted to the recipient’s key rather than transmitted in plaintext.
On an Affinidi-hosted VTA, this extends to Affinidi itself: the master seed is generated inside the enclave and its plaintext is not exposed to Affinidi or to you as the operator. See Master seed for what this means across an enclave restart and the one scenario where an encrypted backup does matter.
Limits
A TEE and PCR0 pinning close specific gaps. Three limits worth knowing:
- Anti-rollback does not cover a compromised host. The tamper-resistant counter blocks restoring an older backup or storage image to roll the enclave back to a previously compromised build, but it does not protect against a fully compromised parent host with root access. See What the enclave guarantees above.
- Fully withdrawing a DID’s access takes two steps, not one. Deleting an access control list (ACL) entry stops new sessions right away, and a JWT the DID is already holding remains valid until it expires, per the session lifetime every access token has. Revoking the DID’s sessions as well closes that window on its next call. See Ending existing sessions immediately.
- Vault secrets are not included in an encrypted backup. Keep a separate copy of any secrets your services depend on. See Back up and restore VTA state.
Related
Glad to hear it! Please tell us how we can improve more.
Sorry to hear that. Please tell us how we can improve.
Thank you for sharing your feedback so we can improve your experience.