Orbitport

Making Orbitport Verifiable: Reproducible Builds, Docker Hardened Images, and Attested TLS

Introduction

In our previous post, Orbitport: The Gateway to Space, we introduced Orbitport as SpaceComputer’s universal gateway between Earth and in-space infrastructure: a developer-friendly API layer that abstracts away ground-station scheduling, intermittent orbital connectivity, satellite-specific integrations, and the operational complexity of communicating with hardware in orbit.

That first version solves the access problem: how do developers reliably use space infrastructure without becoming experts in satellite communications?

This post is about the next problem: how do you verify the gateway, its software supply chain, and the security of the data path end-to-end?

Orbitport is part of a broader push toward verifiable space infrastructure: systems in which data, software, and runtime integrity are backed by cryptographic evidence rather than operator promises. For use cases such as orbital key management, space-based randomness, secure sensing, and future data-provenance pipelines, clients need to know not only where data came from, but also which software handled it, which environment it ran in, and whether that environment matched the expected release.

Orbitport Phase 1 works, but it still assumes trust in SpaceComputer as the operator. Clients trust that our servers are running the code we claim, that no operator has tampered with it, and that data transiting through our infrastructure remains private. Even if payloads are encrypted, the gateway can still expose metadata, runtime behavior, and operational trust assumptions that matter for high-assurance systems. This managed-trust model is common in cloud services today, but space infrastructure needs a stronger foundation.

Orbitport v1.1 narrows that trust assumption by moving the gateway into a Trusted Execution Environment (TEE), making the guest OS reproducible, verifying Docker Hardened Images and their SBOM-backed provenance at boot, extending workload measurements into hardware registers, and exposing those measurements to clients through attested TLS. The result is a gateway whose build, runtime, and data path can be verified before sensitive payloads are sent through it.

Today, TLS from a ground client terminates at Orbitport, which means the secure link between the operator and the satellite is interrupted at the gateway. Orbitport v1.1 changes that trust boundary. TLS terminates inside the TEE, where data is re-encrypted before being forwarded toward the space-side trust boundary. No operator, cloud provider, or attacker with access to the underlying host should be able to read or tamper with the link in transit.

Clients no longer need to take our word for it. They can verify, through hardware-backed attestation, that the gateway they are talking to is running an unmodified, reproducible build of Orbitport, with the expected Docker Hardened Images and workload measurements bound into the attestation quote.

This post is a deep dive into how we built that guarantee: the reproducible guest OS pipeline, the hardened container supply chain, and the attestation architecture that ties it all together. The gateway attestation pipeline is the focus here; the backend trust model is on a separate, parallel roadmap.

Remote Attestation: Proving What Runs

A TEE is a hardware-isolated region of a processor where code and data are protected from the rest of the system, including the host OS, hypervisor, and cloud provider. Intel TDX, AMD SEV-SNP, and ARM CCA provide TEEs that enable the execution of confidential virtual machines (CVMs). For our current solutions, we rely on Intel TDX, which underpins Orbitport v1.1 and operates at the VM level, meaning the entire guest is sealed off from the host. In the future, we want to extend to other TEEs, especially to ARM CCA once available.

What makes TEEs useful beyond isolation is attestation: the ability for a TEE to cryptographically prove to a remote party exactly what code it is running. The hardware generates a signed quote capturing the environment's state at boot, which a remote verifier can check against a known-good reference.

That state is recorded in RTMRs (Runtime Measurement Registers), a set of registers that act as a running cryptographic log of everything loaded during boot. Orbitport v1.1 extends verified container digests into RTMR3, binding the application layer directly to the hardware attestation. RTMRs are specific to the Intel TDX implementation we use today. The broader architecture is TEE-agnostic: other TEE backends would need an equivalent way to measure runtime state and expose those measurements through remote attestation.

Further reading: Intel TDX spec, go-tdx-guest, RTMRs.

At a high level, Orbitport v1.1 works by building a reproducible guest OS, verifying container images before startup, extending their digests into RTMR3, and exposing those measurements to clients through attested TLS. The client can then verify that it is communicating with the expected Orbitport release running on genuine TEE hardware.

Four Layers of Verifiable Trust

Our architecture builds trust in four nested layers, each anchoring the one above it.

Layer 1 - Hardware Root of Trust: TEE

The foundation of our architecture runs the mkosi image on TEE-based hardware. Intel TDX enables CVM with hardware-enforced memory isolation; even the hypervisor and the cloud hyperscaler cannot inspect memory inside the enclave. More importantly for our purposes, TEE cryptographically measures the entire boot sequence, including the kernel, initrd, and OS configuration, and can produce a signed attestation quote that any remote party can verify.

This is what anchors the entire chain. The OS measurement and the container verification are not just claims; they are values locked into tamper-proof hardware registers, signed by an Intel-derived key, and verifiable by anyone.

Layer 2 - Static Trust: The Reproducible Guest OS Image

Built on top of the hardware foundation, we use mkosi to construct our guest OS from scratch. mkosi produces a Unified Kernel Image (UKI), a single, self-contained binary containing the kernel, initrd, and OS from a tightly controlled, declarative specification.

Because every input is pinned, the build is bit-for-bit reproducible. We run builds in a locked, containerized environment with a fixed toolchain version. Package sources are pinned to specific mirror snapshots. Non-deterministic state, such as SSH host keys, machine IDs, logs, and other ephemeral files, is stripped during the post-installation pass.

The result is that the same inputs produce the same binary, with the same hash.

Reproducibility here means the build is deterministic end-to-end, making the attestation meaningful. When TDX measures the boot sequence, the resulting cryptographic measurements are predictable. Anyone who has reviewed our mkosi build configuration can compute those measurements and compare them with the values in a live attestation quote. If they match, the guest OS is exactly what we published.

We will open-source our mkosi build code so this verification is available to everyone.

Layer 3 - Runtime Enforcement: Verified Workloads Before Orchestration

Orbitport runs inside k3s, but k3s is not the trust boundary. Before the orchestrator starts, the measured guest OS checks the expected workload set against the release manifest: image digests, signatures, and provenance requirements.

If any image fails verification, the startup is blocked before the workload reaches orchestration. If verification succeeds, the approved workload set is measured into RTMR3, so any later substitution, bypass, or unexpected image changes that the quote clients verify.

This makes the runtime policy simple: k3s only runs workloads that have already been approved inside the measured guest.

Layer 4 - Workload Supply Chain: Docker Hardened Images, SBOMs, and Provenance

The final layer is the container supply chain itself: the artifacts that Orbitport intends to run.

For Orbitport workloads, we use Docker Hardened Images as the base images. These provide a hardened foundation and include supply-chain metadata such as SBOMs and provenance attestations. On top of those bases, we build Orbitport-specific images with pinned dependencies, deterministic build inputs, generated SBOMs, SLSA provenance, and cosign signatures.

These properties make the workload set auditable before deployment. The base images are hardened, dependencies are pinned, the build process is documented through provenance, and the resulting artifacts are signed and digest-addressed. Layer 3 then enforces this expected workload set at boot and binds it into RTMR3.

In other words, Orbitport clients do not only verify “this is a genuine TEE” or “this is the expected OS.” They can also verify that the gateway is running the expected hardened container images, built through the expected supply chain, and measured into hardware before any sensitive data is sent through it.

Build Pipeline

Guest OS: mkosi

The mkosi build is driven by a declarative mkosi.conf that pins the base OS distribution and every package version. The build process runs through several stages.

mkosi.conf specifies the base OS and pinned package set: the single source of truth for what goes into the image.

Main pipeline orchestrator reads this configuration and drives the full build sequence.

mkosi.extra / skeleton lays out the initial filesystem: directory structure, static configuration files, and any assets that need to be present before package installation.

mkosi.postinst runs after package installation to configure systemd services, create the service user, and perform any runtime setup that requires an installed system. It handles the final hardening pass: downloading and installing pinned third-party software, cleaning up logs and ephemeral state, and stripping anything not needed in production.

The output is a UKI that, given the same inputs, produces the same binary on every build.

Container Supply Chain: Docker Hardened Images

To ensure the utmost security of our containerized gateway, our build pipeline is strictly controlled to guarantee determinism and verifiable origins:

Base Images: We start with foundational Docker Hardened Images, specifically utilizing verified bases like dhi/alpine or dhi/debian.
SLSA Provenance: While building our specific Orbitport images on top of these hardened bases, we generate and attach an SLSA provenance attestation to document the exact build steps and dependencies.
Reproducibility via SOURCE_DATE_EPOCH: To ensure the build process is 100% reproducible and deterministic, we set SOURCE_DATE_EPOCH to a fixed value. This ensures that arbitrary timestamps do not alter the final cryptographic hash of the image. In our current setup, we pin the timestamps to the specific commit timestamp.
Cryptographic Signing: Finally, we utilize sigstore/cosign to cryptographically sign both the resulting Docker image and the SLSA provenance attestation attached to it.

These attestations are securely stored in the registry and can be verified by any third-party tool, allowing anyone to audit the integrity of the images we deploy.

Embedding the base images during mkosi build pipeline

To eliminate a few possible problems, such as registry dependencies at runtime, any possible rate limiting through registries, and a possible Time-of-Check-Time-of-Use (TOCTOU) gap between the verification of base images versus their actual use, we pre-pull the images during mkosi build time and embed them inside our UKI.

At the same time, we perform Cosign verification of the digests of these images and store the results for our runtime RTMR service, as described below.

Binding Containers to Hardware: RTMR Extension

Two proof points are required: proving the OS is correct, and that the specific containers running on that OS are the exact verified images we expect. This dual proof is then bound to the hardware attestation quote.

This is where RTMRs come in.

Runtime Measurement Registers (RTMRs) are append-only hardware registers within the TEE environment. Append-only is the key property: once a value is extended into an RTMR, it cannot be modified or reset without rebooting the CVM and generating a completely different quote. They function as a tamper-proof, hardware-anchored ledger of runtime state.

Register Covers

RTMR0 Firmware and BIOS measurements

RTMR1 Bootloader and kernel

RTMR2 OS and system configuration

RTMR3 Application and runtime

We target RTMR3, which is designated for application and runtime measurements. During the boot sequence, after container verification completes, we run the following deterministic extension process using the go-tdx-guest library.

Cryptographic verification — fetch cosign verification results produced during mkosi build.
Digest extraction — from the successful verification output, extract the deterministic content digest of the image.
Format conversion — convert the digest to the 48-byte SHA-384 format required by TEE RTMRs.
Sequential combination — combine this value with the hash of the next verified image, chaining the measurements together.
Hardware extension — extend the final combined value into RTMR3 via go-tdx-guest.

The result is that the verified container digests are permanently embedded in the CPU's hardware registers. If an operator attempts to substitute a container image even with a correctly signed one from a different version the sequence of hashes changes, RTMR3 diverges from the expected value, and the attestation quote fails verification. The swap is detectable at the hardware level, before any workload runs.

Attestation Workflow

With reproducible OS and hardware-bound container measurements, we can now offer clients a way to verify everything remotely, without any prior trust in SpaceComputer.

The problem with standard TLS

When you connect to a server over HTTPS, TLS gives you two things: an encrypted channel, and proof that you're talking to whoever controls that domain. What it cannot tell you is what code is running on the server behind that domain. A compromised operator, a swapped binary, or a misconfigured runtime would all produce a perfectly valid TLS handshake. For most web services, this is an accepted limitation. For a gateway routing cryptographic material to satellites, it is not.

The question is: how does a client gain confidence in the software running on a remote server, not just the identity of its operator?

Attested TLS: binding code to the connection

The answer is attested TLS (aTLS). Rather than presenting only a certificate during the handshake, the server also presents a live TEE attestation quote, a cryptographic measurement of everything running inside the enclave, signed by Intel's hardware. The client receives both the encrypted channel and the proof of what's behind it in a single connection.

The challenge here is generating that quote on demand. A TEE quote cannot be self-issued by software running inside the CVM, it requires cooperation from the host-side infrastructure. On GCP, this means traversing a specific chain: the CVM makes a request to the Intel Quote Generation Service Daemon (QGSD) running on the host, which in turn contacts the Intel Provisioning Certificate Caching Service (PCCS) to retrieve the signing certificates needed to produce a verifiable quote. This infrastructure is provided by GCP as part of their Confidential VM offering, but wiring it into the TLS handshake is non-trivial.

The attested-tls-proxy

To solve this, we use an attested-tls-proxy adapted from Flashbots' implementation, embedded directly in the mkosi image and running in server mode. Its two core jobs are to terminate TLS inside the TEE, ensuring no plaintext ever exists outside the enclave, and to facilitate attested TLS (aTLS), binding the TLS handshake itself to a live hardware attestation quote.

The flow is:

A client initiates a connection to the proxy.
The proxy requests a fresh TEE quote from the host-side infrastructure (GCP CVM → Intel QGSD → Intel PCCS).
The quote is embedded in the TLS handshake and presented to the client alongside the connection.
The client verifies the quote against Intel's Trust Services, confirming the measurements match the published, expected values for this Orbitport release.

The result is that the client is not just establishing an encrypted channel; it is verifying who is on the other end at the hardware level, before any data is exchanged.

A key design decision here is embedding the proxy inside the mkosi image rather than running it as a sidecar or external service. If the proxy lived outside the measured environment, an attacker who compromised the host could replace it, stripping the attestation from connections while leaving the application untouched. By baking it into the UKI, the proxy itself is part of what TEE measures; its presence and integrity are covered by the same attestation quote it generates.

What the client actually verifies

When a client receives the TEE quote, they are verifying several things at once:

The hardware is genuine. The quote is signed by a CPU manufacturer's hardware-derived key that cannot be forged outside of a real TEE CPU. This rules out software-based impersonation of a CVM.

The boot sequence is correct. The quote contains measurements of the kernel and OS image. Because our mkosi build is bit-for-bit reproducible, these measurements are published and predictable. A mismatch means the OS was tampered with.

The containers are the ones we claimed. The RTMR3 value in the quote encodes the cosign-verified digests of every DHI container, extended at boot. A client who knows the expected RTMR3 value for this Orbitport release can confirm that the exact right containers are running, not a subtly different version, not a patched binary.

If all measurements match, the client has cryptographic evidence, not just a contractual promise that they are talking to an unmodified Orbitport instance running inside a genuine TEE enclave, with verified containers whose digests are locked into hardware.

Threat Analysis

The architecture above was designed with a specific adversary in mind: a malicious or compromised operator who controls the infrastructure but should not be trusted with the data flowing through it.

Malicious operator

The TEE hardware registers are set by the CPU before any operator-controlled software runs, and the resulting measurements are published per release. Every connection carries a live attestation quote, so a client can verify independently without asking us that the software they are talking to matches what we published. No runtime configuration change can pass attestation with the wrong measurements.

Compromised supply chain

We run cosign verification against every Docker Hardened Image at boot, before k3s initializes. If any image fails verification, the workload does not start, there is no fallback, and no operator override.

Tampered OS or boot sequence

The mkosi build is bit-for-bit reproducible, so anyone can independently compute the correct OS hash. TEE measures the entire boot chain into tamper-proof hardware registers before any software runs. A modified image produces a different measurement, the quote diverges from the published value, and verification fails.

Standard HTTPS interception

Every connection carries a live TEE quote via the attested-tls-reverse-proxy. Clients verify they are talking to a genuine, unmodified CVM. The proxy is embedded inside the measured UKI, so it cannot be stripped or replaced at the host level without invalidating the attestation.

Runtime container swap

Verified container digests are extended into RTMR3 during boot, before any workload runs. RTMRs are append-only any swap changes the expected RTMR3 value, the quote fails verification, and the substitution is immediately detectable.

Trust assumptions

Intel and GCP. We trust that Intel's TEE implementation is correct and that GCP's hypervisor does not compromise CVM isolation. This is the accepted baseline assumption in every TEE-based system deployed today.

Application correctness. TEE attests that the right code is running, not that it is bug-free. Application-layer vulnerabilities are outside the scope of what attestation can detect.

Active verification. These protections only apply if clients actually verify the TEE quote. We are working on tooling to make this a lightweight default step rather than an optional one.

Taken together, these mitigations do not make Orbitport trustless, but they make the remaining trust assumptions explicit and verifiable. The operator can still deploy, maintain, and route the gateway, but clients no longer need to blindly trust the operator’s claims about what software is running or how the data path is protected.

Summary

Orbitport v1.1 answers a question that becomes increasingly important as space infrastructure matures: how do you verify not only access to space systems, but the gateway, software supply chain, and data path that mediate that access?

By combining a reproducible guest OS, Docker Hardened Images with SBOM-backed provenance, hardware-bound workload measurements, and attested TLS, Orbitport moves from managed trust toward verifiable trust. Clients can check what software handled their data, what environment it ran in, and whether that environment matched the expected release before sending sensitive payloads through the gateway.

This does not remove trust entirely. Intel, GCP, and application correctness remain part of the trust model. But it narrows the operator's role, currently SpaceComputer, from something clients must implicitly trust to something they can verify against published measurements, signed artifacts, and live attestation quotes.

In the meantime, we’re open-sourcing the mkosi build configuration so that anyone can independently reproduce our OS measurements and verify them against a live Orbitport instance.

The evidence is there, and you shouldn’t have to take our word for it.

Visit the SpaceComputer website.
Follow us on X (Twitter) and LinkedIn.
Read our newest research paper Space Fabric here.

Read more on Orbitport: