Trusted Execution Environments (TEEs) make it possible to run sensitive code securely on infrastructure that is not fully trusted. In theory, attestation allows users to verify that an enclave is running on genuine hardware; in practice, however, deploying these enclaves has remained a significant challenge for developers. Build pipelines are often non-deterministic, making enclave images difficult to reproduce and leaving users to track low-level measurements that are nearly impossible to audit with confidence.
Blue Images were introduced in Marlin Oyster to eliminate these barriers. They provide a reproducible and immutable enclave platform where the execution environment is fixed and verifiable, while user code and data are supplied dynamically at launch.
This article explains the architecture of Blue Images, how they bridge the verification gap in traditional TEEs, and how this design makes enclave deployment simpler and more robust without weakening underlying trust guarantees.
TEEs, such as AWS Nitro Enclaves, provide hardware-enforced isolation and remote attestation. This allows an enclave to prove to external parties that it is running on genuine hardware with a specific, measured initial state.
Historically, deploying these enclaves has been difficult due to a significant verification gap:
Ultimately, while attestation proves that an enclave is running on genuine hardware, it does not provide a clear way to verify that it is running the intended application with the intended configuration. Blue Images were introduced in Oyster to bridge this gap.
The core innovation of Blue Images is the strict separation of platform identity from workload execution. Rather than baking applications into unique enclave images, a Blue Image defines a fixed, reproducible, and verifiable environment that remains stable across different deployments.
To ensure that an enclave image is not a black box, Oyster utilizes Nix to define the entire Blue Image build declaratively. Every component, including system packages, binaries, kernel artifacts, configuration files, and information required to interact with external services such as the Oyster KMS root server, is explicitly specified and pinned.
Because the build process is a pure function of its definition and does not depend on external state, any party can rebuild the image from source and arrive at the exact same binary. This determinism ensures that cryptographic measurements remain stable identifiers rather than moving targets.
A Blue Image acts as a sealed appliance, containing only the essential components required to boot and operate a trusted environment:
By keeping the platform fixed and the workload flexible, trust can be reused across thousands of different applications without reintroducing the verification complexity of traditional baked-in enclave builds.
When a Blue Image boots, its identity is captured through hardware-enforced measurements known as PCRs. In the Oyster ecosystem, PCR0-PCR2 serve as the enclave’s fingerprint:
In the Blue Image model, the workload is a dynamic input rather than a static part of the image. This separation allows users to deploy diverse applications on a single, audited platform without needing to manage custom enclave image files (EIFs).
When a job is submitted, users provide init params, which typically include a Docker Compose file and necessary configurations. The Oyster tooling packages these params, encrypts sensitive fields, and computes a cryptographic digest representing the entire workload configuration.
Once inside the enclave, the user’s code is executed using Docker. This allows developers to use familiar packaging tools while the Docker environment itself remains outside the enclave’s core identity model, keeping the platform measurement clean.
This framework allows developers to choose their desired level of strictness: they can pin exact Docker image digests to ensure absolute bit-for-bit reproducibility or use versioned tags to allow for controlled application upgrades under different trust assumptions.
To ensure the enclave cannot silently switch configurations, it must commit to its workload before execution. The enclave takes the digest of the received init params and extends it into PCR16, which is then locked.
This creates a clear split in the trust model:
While PCRs are the cryptographic source of truth, they can be difficult for users to audit manually. To simplify this, Oyster introduces the Image ID, a single identifier computed as a hash of the platform and workload measurements:
Image ID = Hash(PCR0, PCR1, PCR2, PCR16)
Users verify the enclave by checking the attested Image ID against the expected value generated during job submission. If the IDs match, the user has hardware-backed proof that the enclave is running on the correct Blue Image and has committed to the intended workload. This model also allows external smart contracts to verify enclave outputs by simply checking a single Image ID.
Traditional enclave deployments often burdened users with low-level operational complexity, requiring them to manage custom images and track shifting PCR measurements. Blue Images eliminates this friction by establishing a sealed appliance model that separates the trusted platform from the dynamic application.
The Impact of the Blue Image Model
By shifting the focus from manual image building to runtime commitment, Blue Images provide several key advantages:
Ultimately, Blue Images resolve the trade-offs that have traditionally limited enclave-based systems. By fixing the platform identity and binding workloads at runtime, Marlin Oyster provides a foundation for verifiable compute that is not only secure but also practical and flexible for the decentralized web.
By standardizing the execution environment, Blue Images pave the way for a library of pre-audited platforms. Users can select a known-good environment for their specific needs, effectively outsourcing the complex task of infrastructure auditing while retaining full control over their application logic.
Documentation
Open Source
Subscribe to our newsletter.
