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 mechanism a VTA uses to deliver those provisioning credentials safely.

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 proceeds only if the bundle’s own digest matches what you were told to expect. This is what stops a bundle-substitution attack.

Encryption alone proves confidentiality. The digest check confirms you opened the exact bundle you were told to expect, not one an attacker swapped in during delivery. PNM also accepts an explicit --no-verify-digest opt-out, which prints a warning and skips this check.

A third property, carried alongside the encryption, is who is vouching for the bundle’s origin. Each bundle carries one of three origin assertions:

• A signature by the VTA’s own key (did-signed, the default). Checking it needs the VTA’s DID to resolve.
• A Nitro attestation quote, carried by a bundle from a VTA’s attested first boot inside a Nitro Enclave, such as an Affinidi-hosted VTA, so opening it also confirms which enclave measurement produced it.
• A pinned key, which relies on the out-of-band digest to vouch for the bundle.

Where you already use this

These commands use sealed transfer:

• 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 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 expects a digest unless you explicitly opt out with --no-verify-digest.

pnm vault release delivers a secret at runtime a different way: the VTA encrypts the value to the caller as a DIDComm authcrypt message rather than a sealed-transfer bundle. See Secrets vault and Retrieve credentials from the VTA vault at runtime.

Related