Sealed transfer

A VTA deployment hands out several kinds of credential, such as an application’s signing credential or a rotated admin key. Some are created by PNM on an administrator’s machine, others by the VTA itself. Each one has to reach the right recipient over a network neither side fully controls:

• 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 how those provisioning credentials are delivered safely, whichever side created them. The side that creates and seals the credential is the producer.

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 producer, and the recipient can independently confirm the bundle they received is the exact one the producer created.

How it works

When you run pnm bootstrap request on the recipient’s machine, Personal Network Manager (PNM) generates an ephemeral Ed25519 keypair there and writes a request file that holds only the public key. You hand that file to the producer. In the guides on this site, the producer is pnm auth-credential create --recipient on an administrator’s machine: it creates the credential, registers the new DID with the VTA, and seals the credential locally. Only the access control list (ACL) entry for the new DID reaches the VTA.

To seal, the producer derives an X25519 key from the request’s Ed25519 key, then uses HPKE (Hybrid Public Key Encryption) to encrypt the credential to it. Only the private key that stayed on the recipient’s machine can decrypt the result. The result is wrapped in an ASCII-armoured bundle, and the producer computes a SHA-256 digest over the sealed 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 pinned key, which relies on the out-of-band digest to vouch for the bundle. Every bundle pnm auth-credential create produces uses this assertion.
• A signature by the VTA’s own key (did-signed). Checking it needs the VTA’s DID to resolve. This is the default when the VTA provisions an integration.
• A Nitro attestation quote, which the bundle format also allows, so that opening the bundle confirms which enclave measurement produced it.

Where you already use this

pnm bootstrap request and pnm bootstrap open --expect-digest use sealed transfer 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. They expect a digest unless you explicitly opt out with --no-verify-digest.

pnm bootstrap connect, which bootstraps PNM against a VTA in Isolated mode, transfers no key, so it uses no bundle or digest. Isolated mode runs in an AWS Nitro Enclave, a Trusted Execution Environment (TEE), with hardware-rooted attestation, keys and data. The VTA enrols your claim DID and returns an attested acknowledgement, which PNM checks against the PCR0 you pin before it creates your Administrator DID on your machine.

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