Container images are not secrets. They travel across registries, get cached on edge nodes, and end up copied into build pipelines across dozens of machines. That was fine when the image was just code — but once a container includes a trained ML model, a database decryption key, or a customer data schema, the image becomes a liability. A stolen OCI artifact is a stolen workload. We've spent a lot of time thinking about what it would take to make that theft worthless even when the storage layer is fully compromised.
What Sealing Actually Means at the Hardware Level
The term "sealing" gets used loosely. In the TPM world it means encrypting data under a key that is bound to PCR values — effectively tying ciphertext to a measured boot state. That's useful, but the trust anchor is still a software-measured configuration, not the physical identity of a specific piece of silicon.
Hardware-rooted sealing is different. The encryption key is derived from a physically unclonable function (PUF) — a circuit structure that generates a value from the random quantum-mechanical variation in the chip's transistors at fabrication time. The PUF response is never stored anywhere; it is reconstructed on demand by an on-chip fuzzy extractor. This means there is no key material to extract from flash, SRAM, or a battery-backed vault. The key is, in a meaningful sense, the chip.
When you seal a container image against a specific Bastionchip ASIC, you encrypt the image's layer data under a key derived from that chip's PUF response combined with a caller-defined policy digest. The ciphertext can only be decrypted by that exact chip — not a clone, not a chip with a different serial number, not a software emulator. If the sealed archive is exfiltrated to another machine, it is permanently opaque.
The Policy Digest: What You're Binding Beyond Identity
Chip identity alone is necessary but not sufficient for most deployment scenarios. You typically want to enforce that the workload runs on a specific chip and only when the host system is in a known good state. The sealing API accepts a caller-defined policy digest — a SHA3-512 hash of any structured data you choose to treat as authorization policy.
Common policy inputs include:
- A hash of the expected confidential VM measurement (TDX MRTD or SEV measurement register)
- An attestation certificate chain fingerprint from the host hypervisor
- A build-time manifest digest of the unsigned container layers
- An environment tag restricting execution to a named deployment tier (production, staging, dr-failover)
At unsealing time, the chip reconstructs the derivation key only if both conditions hold: the PUF response matches (chip identity verified) and the caller can supply the matching policy preimage. This two-factor structure means a stolen sealed image is useless even if the attacker also has physical access to a different Bastionchip chip — chip identity alone does not authorize decryption without the correct policy.
ML Model Weights as First-Class Sealed Artifacts
The use case we hear most often from our design partners isn't container filesystems — it's model weights. A fine-tuned LLM or a specialized inference model can represent months of GPU time and significant intellectual property. Deploying that model to cloud infrastructure today means trusting the cloud provider's isolation guarantees for the weight file.
With sealed workload packaging, the weight file (ONNX, SafeTensors, or any binary blob) is treated identically to a container layer: encrypted under a hardware-derived key, stored as a sealed artifact in the model registry, and decrypted only inside the on-chip enclave before being transferred to the inference accelerator over a protected DMA channel. The inference process has access to plaintext weights; the storage layer and the cloud provider's management plane never do.
This matters for a specific threat model that's increasingly relevant: supply chain forensics requests. Cloud providers in some jurisdictions face legal obligations to produce customer data under court order. A sealed model weight file is technically unproductive for forensic purposes — it cannot be decrypted without the specific chip it was sealed to, and that chip is under the customer's physical or logical control. We are not lawyers and this is not legal advice, but the architectural property is real.
Integration Path: From OCI Registry to Sealed Artifact
The sealing workflow integrates into a standard CI/CD pipeline at the image signing stage. After image build and before registry push, the build pipeline calls the Bastionchip sealing SDK with:
- The image manifest and layer tarballs as the plaintext payload
- The target chip's attestation certificate (obtained from the chip during provisioning)
- The policy digest (computed from your deployment policy definition file)
The SDK encrypts the payload using AES-256-GCM with a key derived from an ephemeral ECDH exchange against the chip's ROM-anchored key. The sealed artifact is a self-describing bundle: the ciphertext, the policy digest, and the attestation metadata needed for the chip to verify it was the intended recipient. This bundle is pushed to the registry like any other artifact and handled by standard OCI-compatible tooling.
At deployment time, the orchestration layer (Kubernetes, a Confidential VM operator, or a bare-metal provisioner) pulls the sealed artifact and forwards it to the chip over the PCIe interface. The chip verifies the attestation chain, reconstructs the PUF-derived key, checks the policy digest against the current system state, and either returns the decrypted layers or returns an authorization failure. The plaintext payload is transferred directly into the confidential VM's protected memory region — it never touches host DRAM in cleartext.
We've validated this flow with three design partners running confidential inference workloads. Average unsealing latency for a 4 GB container image layer set is 340 milliseconds — dominated by the bus transfer, not the cryptographic operation itself, which completes in under 2 ms.
What Sealing Does Not Protect Against
Honest threat modeling requires being clear about the limits. Sealed workload packaging protects the confidentiality of artifacts in transit and at rest. It does not protect against a compromised workload runtime — if the code inside the container has a memory disclosure vulnerability, the plaintext data is still accessible to an attacker who can exploit it. Hardware sealing is a supply chain and storage protection, not a runtime integrity guarantee.
It also does not protect against a malicious operator who controls the confidential VM's attestation measurement. If the policy digest is weak — for example, if it does not include a host measurement register — an attacker who can forge or replay the policy preimage can bypass the second factor. Policy design matters. We'll cover attestation policy composition in more depth in a follow-up piece on the attestation protocol.
For teams evaluating this architecture: start with the model weight sealing use case before tackling full container filesystem encryption. The blast radius of a misconfigured policy is smaller, the integration surface is narrower, and it gives your team hands-on experience with the policy digest construction before applying it to a broader workload scope.
