Skip to main content

SpaceTEE: Trusted Execution from Orbit

Just like Offspring sang, kids Trusted Execution Environments aren't alright... or better yet, they're amazing but have one major, known weakness. And a quite physical one: the hardware is physically accessible.

SpaceTEE is the idea that if you move the Trusted Execution Environment (TEE) to orbit, you eliminate the entire category of physical attacks. Can't beat physical isolation.

What's a TEE?​

A Trusted Execution Environment is a secure region within a processor where code and data are isolated from everything else on the system. The operating system can't read it. The hypervisor can't read it. Even a user with root access and physical possession of the machine can't directly inspect what's happening inside the enclave.

The key capability is this: code running inside the TEE processes sensitive data while keeping it encrypted in memory. The processor decrypts data only inside the enclave boundary. Everything outside (ex. the OS, other processes, the hypervisor, even the BIOS) sees only ciphertext.

These are the major implementations you'll encounter:

  • Intel SGX (Software Guard Extensions) - creates isolated enclaves within the CPU. Application code runs inside the enclave with encrypted memory that's inaccessible to the OS, hypervisor, or other processes. SGX is designed for application-level isolation and has the smallest trust boundary of the major TEE implementations.
  • ARM TrustZone - splits the processor into a "secure world" and a "normal world." The secure world has its own memory, peripherals, and execution context that the normal world cannot access. ARM TZ is widely used in mobile devices for payment processing and DRM.
  • AMD SEV (Secure Encrypted Virtualization) - encrypts entire virtual machine memory so that the hypervisor (and other VMs) can't read it, even with physical memory access. Designed for cloud computing scenarios where the VM owner doesn't trust the cloud provider.

The common thread is isolation. Code running inside a TEE is shielded from the rest of the system.

Remote attestation​

The feature that makes TEEs useful for distributed systems is remote attestation. This is a mechanism that lets a remote party verify what code is running inside the enclave, on what hardware, with what configuration.

The flow works roughly like this:

  1. The enclave generates a report containing measurements (hashes) of the code loaded inside it.
  2. The processor signs this report with a hardware-embedded key that's unique to the chip.
  3. The remote party verifies the signature against the chip manufacturer's attestation service.
  4. If the signature is valid and the code measurements match expected values, the remote party knows that specific code is running inside a genuine TEE.

You don't have to trust the machine operator. You don't have to trust the cloud provider. You verify the attestation, and the hardware guarantees the rest. This is powerful, and it's what enables confidential computing: running code on someone else's hardware with a cryptographic guarantee that they can't see your data or tamper with your computation.

Where terrestrial TEEs fall short​

TEEs are well-designed and widely deployed. But they have a threat model boundary that's hard to ignore: the physical layer.

Side-channel attacks​

Researchers have demonstrated numerous attacks against TEEs that exploit physical properties of the hardware. Power analysis measures the power consumption of the processor to infer what the enclave is computing. Electromagnetic emanation analysis captures EM radiation from the chip to extract secrets. Cache timing attacks observe how long memory accesses take to infer what data the enclave is processing.

These attacks are real and have been demonstrated against SGX, TrustZone, and SEV in academic settings. They aren't trivial to execute, but they don't require exotic equipment either. A motivated attacker with physical access to the hardware and some lab equipment can extract enclave secrets.

The common factor is physical proximity. All of these attacks require being close to the hardware. The attacker needs to be able to measure power draw, capture electromagnetic signals, or observe timing at nanosecond resolution. You can't do this remotely.

Physical tampering​

A sufficiently motivated attacker with physical access can go further: decapping chips to expose die layers, probing internal bus lines with microscopic needles, or modifying hardware to inject faults that cause the enclave to leak information. TEE designers work hard to make this difficult (epoxy coatings, tamper-detection circuits, fuses that blow if the package is opened, etc), but it's an arms race. If an attacker has unlimited time, unlimited attempts, and can bring whatever equipment they want, they may eventually succeed.

Several academic papers have demonstrated successful physical attacks against SGX enclaves through voltage glitching and laser fault injection. These require expensive equipment and significant expertise, but they work.

Supply chain attacks​

Before the hardware even reaches the data center, it passes through a supply chain of manufacturers, distributors, shippers, and integrators. A malicious modification introduced during manufacturing or shipping could compromise the TEE before it's ever deployed.

This isn't theoretical paranoia. It's a concern serious enough that major cloud providers run their own hardware verification programs, and governments maintain lists of trusted suppliers. The Snowden documents revealed that intelligence agencies have interdicted hardware shipments to install surveillance implants. If your threat model includes nation-state adversaries, the supply chain is an attack surface.

Insider threats​

Data center operators have physical access to the hardware. In theory, a TEE protects against the operator. In practice, the operator can execute the physical attacks described above. "Trust the cloud provider not to physically attack your enclave" is a weaker guarantee than most people realize.

Terrestrial TEEs dramatically raise the bar for attacks, but they don't eliminate the physical attack surface. For the vast majority of use cases, the raised bar is sufficient. For the highest-assurance use cases, it's not.

The SpaceTEE proposition​

Move the TEE to orbit. That's it, basically.

A satellite in LEO is physically inaccessible. Once launched, no one can touch the hardware. The satellite is moving at 7.5 km/s at an altitude of hundreds of kilometers, and there is no mechanism to physically interact with it.

This eliminates the entire physical attack surface in one move:

No side-channel proximity. You can't measure power consumption or electromagnetic emanation from hardware that's 500 km away and moving at orbital velocity. The physical gap makes proximity-based side-channel attacks impossible in a fundamental way, not merely impractical.

No physical tampering. There is no way to access, modify, or probe the hardware after launch. The tamper resistance isn't a coating or a circuit, but hundreds of kilometers of vacuum.

No supply chain attacks post-launch. The hardware configuration is fixed at launch. Whatever is on the satellite is what runs for the mission's lifetime. There's no opportunity to intercept and modify hardware in transit to a data center because there is no transit after launch. The satellite goes from the integration facility to the launch vehicle to orbit, and the chain of custody is managed through launch.

No insider physical access. The satellite operator communicates with the satellite via radio. They can send commands and receive data. But they cannot physically access the hardware, which means the TEE's isolation guarantee is maintained even against a compromised or coerced operator.

What you end up with is a TEE where the software isolation guarantees (encrypted memory, remote attestation) are reinforced by physical isolation guarantees (orbital inaccessibility). The two layers are complementary. Software isolation protects against software attacks. Physical isolation protects against physical attacks. Together, they cover the full stack.

Remote attestation from space​

Remote attestation is what makes TEEs useful in practice. It's also what makes SpaceTEE verifiable rather than a matter of faith.

Conceptually, SpaceTEE remote attestation works the same way as terrestrial TEE attestation, but the physical context changes the trust assumptions:

  1. The enclave running on the satellite generates an attestation report containing code measurements, signed by hardware-embedded keys.
  2. The signed report is transmitted to the ground during a satellite pass (or via constellation relay).
  3. The verifier checks the signature against known hardware identities established before launch.
  4. The code measurements are compared against expected values.

If the signature is valid and the measurements match, you know: this specific code is running inside a genuine TEE, on verified hardware, in orbit. No one has physically tampered with the hardware (because they can't). No one has modified the code outside the update mechanisms you've verified.

The attestation chain is longer than a terrestrial TEE (it includes the satellite communication path), but the physical guarantee at the root is stronger.

Pre-launch verification​

One important aspect of SpaceTEE trust is pre-launch verification. Before the satellite reaches orbit, the hardware and software are inspected and verified in a controlled environment. The code measurements, hardware identities, and cryptographic keys are established and recorded. Launch itself is a witnessed, documented event.

This gives you a clear chain of custody: the hardware was verified on the ground, loaded into the launch vehicle, and sent to orbit. From that point forward, no one has physical access. The attestation report you receive from orbit connects back to the pre-launch verification through the hardware identity chain. It's a complete, verifiable story from manufacturing to orbital operation.

What SpaceTEE enables​

Combining TEE software isolation with orbital physical isolation opens up use cases that are difficult or impossible to serve with terrestrial confidential computing alone:

Key custody with provable isolation. Generate and store cryptographic keys inside an orbital TEE. The private key never leaves the enclave, and the enclave is physically beyond anyone's reach. This is a hardware security module with the strongest possible physical isolation guarantee. For organizations that need key custody they can prove is secure against physical attacks, there's nothing comparable on the ground.

Confidential computation for adversarial settings. Multi-party computations where none of the parties trust each other, or trust any single infrastructure provider. An orbital TEE provides a neutral execution environment that no single party can physically compromise. The computation runs in space, beyond the reach of all participants. This is relevant for inter-organization computations, privacy-preserving analytics, and any scenario where "trust the cloud provider" is insufficient.

Compliance workloads requiring provable isolation. Some regulatory frameworks require demonstrable isolation of sensitive computations. "The computation ran inside a TEE on a satellite in orbit" is a strong statement to make to an auditor. Remote attestation provides the cryptographic evidence, and orbital mechanics provides the physical guarantee. For regulated industries that need to demonstrate isolation beyond what a data center can offer, SpaceTEE provides a qualitatively different level of assurance.

Root of trust for distributed systems. A SpaceTEE can serve as a trust anchor for larger distributed systems. If you need a single, inarguable source of truth for key generation, timestamp attestation, or random number certification, an orbital TEE is a compelling foundation. The root of trust is literally above the fray: it can't be physically compromised by any party in the system.

Tamper-proof audit logs. An orbital TEE can maintain an append-only log of events, signed by enclave-held keys, where the physical isolation ensures no one has tampered with the logging process. For financial audit trails, chain-of-custody records, or regulatory reporting, this provides a guarantee that the log reflects what actually happened.

Practical considerations​

SpaceTEE is compelling in theory, and real in ambition, but it comes with constraints that are worth understanding honestly:

Compute is limited. The thermal realities of space mean you can't run heavy workloads inside an orbital TEE. This is a platform for lightweight, high-assurance operations (i.e. key generation, signing, attestation, small computations), not general-purpose cloud computing. If your workload involves processing gigabytes of data or running complex models, it doesn't belong in orbit.

Latency is variable. Communication with the satellite depends on ground station passes or constellation relay links. You won't get the sub-millisecond response times of a cloud TEE. Depending on the communication model, plan for seconds (with constellation relay) to hours (with direct ground station passes) of round-trip time. Design your application accordingly and batch operations rather than interactive request-response.

Availability is intermittent. Unless the satellite has continuous connectivity via constellation relay, it's reachable only during pass windows. Orbitport's fallback architecture helps smooth this out, but the underlying intermittency is real. Applications that depend on SpaceTEE should be designed to tolerate periods where the enclave is unreachable.

Deployment is irreversible. You can update software on a satellite remotely (with proper safeguards and verification), but hardware is fixed at launch. There's no swapping out a faulty chip or upgrading a processor. The hardware you launch with is the hardware you have for the mission's lifetime. This makes pre-launch testing and verification absolutely critical.

Mission lifetime is finite. Satellites don't last forever. LEO satellites typically operate for 3-10 years before deorbiting. Key material and services need migration plans. This is a different operational model than a data center where you can swap hardware and maintain continuity indefinitely.

Software updates require care. Updating code in an orbital TEE is possible but must be done through verified channels with cryptographic authentication. You can't SSH into a satellite. Every update is a remote operation over a constrained communication link, and a bad update could brick the payload with no way to physically intervene. This means software deployment cycles are slower and more deliberate than terrestrial environments. You test exhaustively on the ground before pushing anything to orbit.

These constraints mean SpaceTEE won't replace terrestrial TEEs for most workloads. It's the right tool for specific high-value computation where the physical isolation justifies the operational constraints. If you're building a system where the threat model explicitly includes physical attacks on hardware, SpaceTEE is the answer to a question that terrestrial infrastructure fundamentally can't resolve.

Current status​

SpaceTEE is part of SpaceComputer's roadmap. It is not yet a live, generally available service.

What is live today is cTRNG: cosmic True Random Number Generation. cTRNG and SpaceTEE share the same underlying infrastructure: the same satellites, the same ground stations, the same Orbitport gateway, the same plugin architecture. cTRNG is, in a meaningful sense, the proof of concept for the broader orbital compute thesis. It demonstrates that satellite hardware can generate cryptographic material in orbit, sign it, transmit it to the ground, and deliver it through a developer-friendly API.

SpaceTEE extends this foundation. Instead of generating random numbers onboard, the satellite runs arbitrary (lightweight) code inside a trusted execution environment. The data path is the same: satellite -> ground station -> Orbitport -> your app. But the capability is broader: where cTRNG provides a specific service (randomness), SpaceTEE provides a platform (isolated computation).

When SpaceTEE becomes available, it will be accessible through the same Orbitport API and SDK you use for cTRNG today. The integration pattern won't change, but the set of available services will expand.

For updates on SpaceTEE development and availability, follow the SpaceComputer documentation and announcements.

Further reading​