Paper: Space Fabric — Satellite-Enhanced Trusted Execution Architecture

Citation

Rezabek, F., Malkhi, D., Yahalom, A. “Space Fabric: A Satellite-Enhanced Trusted Execution Architecture.” arXiv:2603.23745v1 [cs.CR] (Mar 24, 2026). SpaceComputer / UCSB.

Why This Exists

Terrestrial TEEs are insufficient for emerging decentralized satellite networks and orbital computing:

Hardware-based designs (Intel TDX, AMD SEV, ARM CCA) are susceptible to physical attacks — recently demonstrated by TEE.fail and WireTap (DDR5 bus interposition attacks).
More fundamentally: most current platforms root attestation in secrets provisioned during manufacturing → creates a pre-launch trust window + single-vendor dependency that cannot be independently audited.

This is the physical-access gap described in TEEs and Attested TLS’s “Mind the Gap” analysis, taken to its logical extreme: when the workload runs in space, you can’t even check whether a basement-level adversary is present.

Key Insight

Satellites’ post-launch physical inaccessibility = a tamper barrier unattainable on Earth. Once a satellite is in orbit, no adversary can physically tamper with its hardware. This is the inverse of the DCEA / POE problem statement: instead of trying to prove hardware sits in a controlled environment, exploit a fundamentally inaccessible one.

Three Architectural Contributions

1. Satellite Execution Assurance Protocol (SEAP)

Binds workload execution to a specific satellite via a Byzantine-tolerant endorsement quorum of distributed ground stations. The protocol certifies:

What program executes inside the TEE
Where (which satellite)

The Byzantine quorum eliminates single-ground-station trust — a corrupt ground station cannot forge a satellite’s execution claim.

2. Fully on-orbit key generation

Cryptographic secrets are generated within co-located secure elements after launch. No persistent signing secrets are accessible on Earth at any point.

Eliminates the pre-launch trust window (a corrupt ground crew at provisioning time gains nothing).
Eliminates single-vendor manufacturer dependency (no Intel-/AMD-/ARM-equivalent key provisioned at the foundry).
Residual trust assumption: the operator correctly registers device identifiers — a standard operational requirement common to all TEE deployments.

3. Dual-secure-element hardware trust anchor

Distributes the hardware root of trust across two independent secure elements to further reduce single-vendor dependence.

Trust-Model Compared to Terrestrial Approaches

Approach	Pre-launch trust	Vendor dependence	Physical-attack vulnerability
Standard TEE attestation	✅ Manufacturer key provisioned	Single-vendor	✅ Demonstrated (TEE.fail, WireTap)
POE (Intel)	Provider-signed inventory	Single-vendor (Intel)	Out-of-scope (proof of cloud)
DCEA (Flashbots)	TPM provisioning	Multi-vendor possible	Out-of-scope (proof of cloud)
Space Fabric	None (on-orbit keygen)	Dual secure elements	Out-of-physical-reach

Connection to Wiki

Direct continuation of the TEEs and Attested TLS arc: TEE.fail/WireTap → DCEA/POE → Space Fabric.
Sibling of the Trustless TEEs Open Hardware and ERC-733 (TTEE) initiative: both aim to reduce vendor trust, but TTEE uses PUFs + open hardware on Earth, while Space Fabric uses orbital inaccessibility.
Practical for very-high-assurance MEV-relevant workloads: BuilderNet enclaves, distributed-keyper committees for Encrypted Mempools, Private Information Retrieval (PIR) for Ethereum / PIR networks.

Limitations & Tradeoffs

Latency: ground-to-orbit round trip adds ~50–500 ms depending on orbit altitude — material for latency-sensitive MEV (CEX-DEX arb).
Bandwidth: orbital links are constrained vs terrestrial fiber.
Operational cost: launching and maintaining satellite TEEs is orders of magnitude more expensive than cloud TDX.
Scaling: a single satellite can host limited workload; horizontal scaling means more launches.

⟹ Best fit: high-assurance, low-throughput workloads where the trust-model improvement justifies the cost. (Threshold-key custody, attestation-of-record signing, root-of-trust bootstrapping for terrestrial systems.)

Open Questions

❓ Recovery model: if a satellite is destroyed (orbital debris, deliberate ASAT) but its keys were used for ongoing commitments, what’s the recovery procedure?

❓ Endurance: secure elements have finite lifetimes (radiation, thermal cycling); how does the protocol handle scheduled hardware retirement?

❓ Could the same SEAP design be applied to terrestrial high-security facilities (e.g., underground SCIFs) where physical access is similarly controlled but not impossible?