Space Fabric: The Trust Layer in Orbit

The hardware and protocol stack behind SpaceComputer's satellites. Dual secure elements, keys born in space, and attestation that proves where your code runs.

The other concept pages talk about what orbit gives you: physical isolation, cosmic entropy, trusted execution beyond anyone's reach. Hope we have successfully nerd-sniped you into these, but you may be asking "what makes those claims actually checkable?" Well, Space Fabric is the answer. It's SpaceComputer's satellite-native security architecture: the specific chips, boot process, and attestation protocol that turn "trust us, it's in space" into a proof you can verify yourself.

Every service you consume through Orbitport, whether the cTRNG or the KMS, ultimately roots its guarantees in this layer. So it's worth understanding what's actually up there.

The problem it solves

Trusted Execution Environments are good at proving what code runs, because remote attestation gives you a signed measurement of the software inside the enclave so you can check it against a known-good build. That's why they get proposed for things like voting machines: you can audit the machine's open-source code, then verify the machine is running that exact build and not some shady compromised thing.

Unfortunately things are not so simple and TEEs aren't foolproof. Attacks like TEE.fail and WireTap defeated state-of-the-art memory encryption by physically interposing on the memory bus. Access to the hardware proved more powerful than malware or stolen credentials, in a way.

To make matters worse, there's a second problem: where did the keys come from? Nearly every commercial secure platform (Intel SGX, AMD SEV, ARM CCA) provisions its root keys during manufacturing. That means there was a window, in a factory, when the key existed somewhere a person could reach. You're trusting that the manufacturer generated it correctly and kept no copies, and you have no way to audit either claim.

Space Fabric attacks both problems at once: move the hardware where nobody can touch it, and don't create the keys until it gets there.

The hardware

The stack is modest: four components, each with a specific trust job.

A TEE for workloads. An ARM TrustZone environment splits the onboard computer into a Secure World (where trusted applications run) and a Normal World (treated as untrusted by design). Customer workloads and the attestation server live in the Secure World. The Normal World handles plumbing, relaying messages to and from the radio, and is assumed compromised in the threat model. It can delay or drop messages, but it can't forge what the TEE signs.
Two secure elements, from two vendors. This is the interesting design decision. Instead of a single trust anchor, there are two independent chips: an NXP SE050 (closed-source, Common Criteria EAL 6+ certified) and a Tropic Square TROPIC01 (open-source RISC-V design, auditable down to the gate level). Every attestation the satellite produces must be co-signed by both. To forge one you'd have to compromise two unrelated silicon supply chains, one of which anyone can inspect, and do it in orbit.
A TPM for the relay. The untrusted side carries a discrete TPM 2.0 module that measures its boot sequence. It sits outside the critical trust path (the secure elements don't depend on it), so it's defense-in-depth: it raises the cost of tampering with the relay without becoming a single point of failure. It also happens to be the natural place to anchor post-quantum signatures as those roll out.
Radiation-aware engineering around all of it. These are commercial off-the-shelf chips, not space-grade ASICs, so the design compensates with thermal shielding, watchdogs, retries, safe-mode recovery, and ground testing beyond expected operational limits. The TROPIC01 integration (announced with Tropic Square in mid-2026) is the first flight of that chip, qualified for a -30°C to 90°C operating range.

Keys born in space

The property that separates Space Fabric from terrestrial platforms is simple to state: no SpaceComputer signing key has ever existed on Earth.

Before launch, the key slots in both secure elements are verified empty. What gets registered with the ground-side verifier is public information only: device serial numbers, hardware certificates, configuration hashes. Nothing secret leaves the factory because nothing secret exists yet.

On first boot in orbit, each secure element generates its own key pairs internally, using on-chip entropy, and flags the private halves non-exportable under hardware policy. The workload can request signatures, but the private keys can't be read out by the operating system, the satellite operator, or SpaceComputer itself. And because the pre-registered hardware certificates tie attestation to those specific physical chips, a perfect clone built on Earth would generate different keys and be rejected by verifiers.

Compare that to the manufacturing-era model, where you trust that a vendor erased every copy of a key and have no way to check. Here you audit a key-generation policy and verify its output cryptographically.

At end of life, disposal is physical too: the satellite de-orbits and burns up on atmospheric re-entry, secure elements and every key inside them included. There is no decommissioned drive to recover and nothing left to run forensics on.

Proving it runs in orbit

Attesting what code runs is standard TEE fare. Space Fabric adds a claim no terrestrial system needs: proving where it runs. Otherwise, how do you know the "satellite" you're talking to isn't a replica in a warehouse?

The answer is the Satellite Execution Assurance Protocol (SEAP), and the idea behind it is called Proof of Execution Triangulation. Ground stations around the world independently challenge the satellite as it passes overhead; a three-message challenge-response exchange takes 210-620 ms per pass. Each station that gets a valid, dual-signed response co-signs an endorsement. Once endorsements from enough geographically distributed stations accumulate (a Byzantine-tolerant threshold, so a few compromised stations can't fake it), the verifier issues a Certificate of Authorization: cryptographic evidence that this specific workload runs on this specific hardware, in orbit.

The initial certificate takes 4-7 orbital passes to assemble, roughly 6-11 hours. After that, day-to-day attestations are cheap: a fresh dual-signed token in 100-200 ms. The satellite's constant motion, which the satellite communication page describes as a constraint, works in security's favor here: a single object tracing a predictable orbit is something many independent observers can check and agree on.

Limitations

Space Fabric is a research-grade architecture entering deployment, and the paper is upfront about its limits:

Compute is small. First deployments run on an ARM Cortex-A7. That's fine for the workloads that need this trust model most (key management, signing, sovereign data processing) and not fine for training your LLM. See space computing for why that constraint exists.
Re-attestation is an open question. The Certificate of Authorization is issued around launch; protocols for re-certifying after software updates, or after rotating a compromised ground-station committee, are active research.
Pre-launch still matters. The guarantees begin at first boot in orbit. Between fabrication and launch, the hardware is protected by conventional means, plus the verified-empty key slots, which at least ensure there's nothing to steal yet.
The secure elements aren't post-quantum yet. The migration path is hybrid: hardware-bound elliptic-curve keys for platform binding, software-based post-quantum signatures layered on top. The post-quantum page covers why that ordering makes sense.

How it connects to what you use

You never interact with Space Fabric directly; there's no sdk.spacefabric namespace. It shows up as the provenance behind everything else:

cTRNG values are generated and signed inside Space Fabric-managed hardware. The signature you can verify traces back to keys born in orbit.
The randomness beacon inherits the same signing chain, published publicly over IPFS.
The KMS roadmap ends with customer keys held in this environment: generated in orbit, non-exportable, destroyed on re-entry.
SpaceTEE is the customer-facing version of the confidential compute story: your workload in the Secure World, attested by the dual secure elements.