Sealed transfer

A VTA hands out several kinds of credential: an Administrator DID, an application’s signing credential, a rotated admin key. Each one has to reach the right recipient over a network the VTA does not fully control:

• REST calls pass through ordinary HTTP infrastructure.
• DIDComm messages are relayed through a mediator, a separate service that routes between DIDs and is not itself the final recipient.

Sealed transfer is the one mechanism every credential-bearing operation in a VTA uses to make that safe.

What it takes to deliver a credential safely

A private key sent as plain JSON in a response body is readable by anything that can see the response: a logging proxy, a compromised mediator relaying the message on your behalf, or an attacker who intercepts the connection. Encrypting the response to the VTA’s own key does not help either, since that only proves the VTA sent it, not that only the intended recipient can read it. Sealed transfer solves both problems at once: the payload is encrypted specifically to the recipient’s key before it leaves the VTA, and the recipient can independently confirm the bundle they received is the exact one the VTA created.

How it works

When you run pnm bootstrap request, Personal Network Manager (PNM) generates an ephemeral Ed25519 keypair on your machine and sends only the public key to the VTA. The VTA derives an X25519 key from that Ed25519 key, then uses HPKE (Hybrid Public Key Encryption) to encrypt the credential to it. Only the private key that stayed on your machine can decrypt the result. The result is wrapped in an ASCII-armored bundle carrying a SHA-256 digest of its contents.

That digest is the second half of the guarantee. It is communicated out-of-band, typically printed to your terminal by whichever command created the bundle, rather than inside the bundle itself. When you run pnm bootstrap open --expect-digest <digest>, PNM refuses to proceed unless the bundle’s own digest matches what you were told to expect. This is what stops a bundle-substitution attack. Encryption alone proves confidentiality. Only the digest check proves the bundle you opened is the one the VTA created for you, not one an attacker swapped in during delivery.

A third property, carried alongside the encryption, is who is vouching for the bundle’s origin:

• Most bundles are signed by the VTA’s own key (did-signed, the default).
• A bundle from an Affinidi-hosted VTA’s attested bootstrap instead carries a Nitro attestation quote, so opening it also confirms which enclave measurement produced it.

Either way, the recipient can verify origin without contacting the VTA again.

Where you already use this

Every one of these commands is a sealed-transfer exchange:

• pnm bootstrap request / pnm bootstrap open --expect-digest, to provision a credential, in Sign application payloads without exposing your keys, Give your AI agent persistent memory, Connect a Model Context Protocol (MCP) host to your VTA, and Rotate an application credential.
• pnm vault release, to deliver a secret at runtime, in Retrieve credentials from the VTA vault at runtime and Keep API tokens out of your service config.
• pnm bootstrap connect --expect-pcr0 in Bootstrap PNM against the VTA. This is the one path that anchors on something other than a digest, because bootstrap connect mints its bundle during the call, so no out-of-band digest can exist beforehand. A pinned PCR0 takes its place: the value is known in advance from the configuration page and is checked against the enclave’s attestation quote before the credential installs. Every other path still requires a digest.

Related