SpaceComputer | Orbital Root of Trust

Introducing Proof of Execution Triangulation (Proof of ET 👽) as a new security standard for compute verifiability in orbit. As computing moves to orbit, verifying execution location becomes a baseline requirement, especially for sensitive data operations. Proof of ET works by verifying that workloads are executed on the correct satellite they were sent to, through a distributed network of ground stations across the globe. Proof of ET applies to: → Multi-tenant orbital compute: AI companies sharing satellite compute infrastructure can verify that proprietary models executed on the specific satellite they contracted, with cryptographic proof that the workload was not replicated on the ground. → Sovereign data processing: Government agencies processing classified or regulated data in orbit receive verifiable evidence that their processing pipeline ran unmodified on attested hardware. → Scientific data provenance: Climate, weather, and Earth observation data processed on board a satellite can be independently verified from sensor to output, strengthening the evidentiary value of space datasets. TLDR: Remote attestation proves what code ran. Proof of Execution Triangulation proves where it ran. Follow along as we build the secure space infrastructure for the space economy. 🛰️

We are excited to announce that we've open-sourced crypto-ctrng 🎉 For our devs out there, it's a Rust library that plugs cosmic entropy into anything expecting RngCore or CryptoRng, the two standard randomness interfaces in the Rust cryptography ecosystem. No API key required! What's in the library: > XOR with OS randomness default > ChaCha20 DRBG with auto-reseed > Multi-gateway IPFS fallback > TestU01 & PractRand in the test suite. Uses of crypto-ctrng include for ECDSA nonces and threshold signatures. Today's public beacon is shared across consumers, so application code personalizes per user. Toufic B., our applied cryptographer, walked us through the design at EthCC in Cannes earlier this year. Repo: https://lnkd.in/evQ3zVsA Developer support: t.me/SpaceComputerOfficial

Happy Earth Day, Earthlings! 🌏 🛰️

Let's break down process-based vs VM-based TEEs in under 60 seconds. It's one of the first design decisions in confidential computing. Process-based TEEs isolate sensitive operations inside the enclave. It has a small trusted compute base, strong security, and code rewrites required to fit to isolate sensitive processes onto the enclave model. VM-based TEEs isolate an entire virtual machine. Code doesn’t have to be changed to run inside the TEE, but the guest OS and vendor firmware are now inside the trust boundary (where sensitive processes run alongside compute workloads). It’s a larger attack surface for a lower deployment cost. Terrestrially, the choice is a tradeoff between security and usability. Orbit shifts the weight of that specific tradeoff, though it does not remove the need to make deliberate TEE architecture decisions. SpaceComputer selected ARM TrustZone, a process-based TEE, for Space Fabric, our hardware and software architectures. Two reasons drove the choice beyond fit with the rest of our architecture. First, a smaller trusted computing base is better suited to orbital constraints. There is less code to verify, a smaller attack surface, and lower compute overhead on power and mass-constrained satellite hardware. Second, our stack is open-source end to end. The trust anchor is independently auditable rather than dependent on a single vendor's attestation service. The process-vs-VM question is one input among many in designing trust infrastructure for the space internet. Follow along as we build it. 🚀

Canada, the US, and Australia have all set PQC migration plans in line with upcoming security risks. Yet the same standards haven't been set for satellite hardware and software. Until regulators catch up, the burden falls on operators to ask the right questions. Three questions every satellite operator should be able to answer about their security: 1. Are your algorithms NIST PQC-compliant? NIST finalized its post-quantum cryptography standards in 2024: ML-KEM, ML-DSA, SLH-DSA. These are production-ready and shipping in Chrome, Cloudflare, and AWS. 2. Are your systems agile enough to swap cryptographic algorithms without changing hardware? If an algorithm's vulnerability is exploitable, can your software adapt, or does it require physical intervention on hardware that physically unreachable in orbit? 3. What is your migration timeline if Q-Day is 2029, not 2035? Considering the approximate quantum resources needed to break ECC dropped by 20x this year, all satellite architecture needs a post-quantum readiness plan. Satellites launching today will still be operating when quantum computers arrive. The encryption the satellite has launch is what must be capable of defending against post-quantum attacks. This is why at SpaceComputer we're building for the in orbit to be long, while the window to launch with security standards is shrinking.

Every organization needs a post-quantum readiness plan for when a sufficiently powerful quantum computer can break today's public-key cryptography. If you're building in orbit, there's an extra layer of preparedness required compared to the ground-based organizations. When Google's updated 2029 quantum deadline arrives, the satellites launching this year will still be operational. Read about what security decisions each satellite operator needs to be taking into consideration right now. 👇

We’re thrilled to announce that we’ve joined the NVIDIA Inception Program! 🚀 As we scale our compute and security capabilities in orbit, the #NVIDIAInception program will help to accelerate development of our infrastructure. Ad astra! 🚀

Google just set a 2029 deadline for post-quantum cryptography (PQC) migration. Their latest research shows elliptic curve cryptography can be broken with 20x fewer quantum resources than previously estimated. Cloudflare matched the timeline within days. There are 14,904 satellites in orbit today, and the Satellite Cybersecurity Act was only recently reintroduced in Congress. Generally, fewer than 5% of enterprises have implemented quantum-safe encryption of any kind. This poses a huge security risk for the space industry, as most satellite systems security still rely on elliptic curve cryptography (ECC). As we build SpaceComputer's security stack, post-quantum cryptography will be a design requirement. We plan to have our architecture PQC-ready in line with the industry's 2029 goal, and encrypted from the hardware layer up, because the satellites launching today will still be operating when quantum computers arrive. The transition is coming, and it’s time to build infrastructure with post-quantum security in mind.

Happy Friday from the SpaceComputer team 🖖 We are proponents of high quality randomness, especially when it comes to true random number generators (TRNGs), like our cosmic TRNG. High quality randomness is critical for security services, but we also believe that it should be able to create things that inspire us to build creatively, and for unique solutions. José Pedro Sousa, Developer Relations at SpaceComputer created the cosmic vibe check: where you can see for what's on your mind if 'it's so back' or 'it's so over'. Test it out here 👉 https://lnkd.in/eKnU_FBK Let us know what you got in the comments! 😂

We're headed to EthPrague! Catch Daniel Bar - 丹尼尔 on stage, speaking about why security and confidential compute in orbit for AI and other applications is critical infrastructure for the rapidly scaling space economy. 🚀