# Introduction (/docs) What is SpaceComputer? [#what-is-spacecomputer] SpaceComputer is infrastructure for delivering security-critical services from satellites in low Earth orbit. The core idea is simple: a satellite orbiting at 500+ km, moving at 7.5 km/s, is physically inaccessible in a way no terrestrial data center can match. That physical isolation is a security property — not enforced by policy or guards, but by orbital mechanics. This matters for a specific class of operations: key generation, randomness, confidential computation — workloads where trust in the hardware environment is the hard part. SpaceComputer provides that trust by putting the hardware where no one can reach it. What's available today [#whats-available-today] **Cosmic True Random Number Generation (cTRNG)** is the first live service. Cosmic radiation detectors on satellites observe high-energy particles — quantum events that are genuinely, provably random. The satellite processes them into uniform random bytes, signs the data onboard, and transmits it to the ground during pass windows. The result: true randomness you can verify came from space, not from a chip vendor's black box. How you access it: Orbitport [#how-you-access-it-orbitport] **Orbitport** is the API gateway that abstracts orbital complexity into a normal developer experience. You don't need to understand pass windows, ground station scheduling, or satellite communication bands. You call an API or use the TypeScript SDK, and you get data. Orbitport handles source selection (multiple satellites, multiple payloads), automatic fallback when a source is unavailable, and distributes data through a public IPFS beacon that updates every five minutes — no authentication required. Orbitport Overview What's on the roadmap [#whats-on-the-roadmap] **SpaceTEE** extends the same principle to general computation. Trusted execution environments like SGX protect code from the software stack, but the hardware is still physically accessible. SpaceTEE puts the TEE in orbit, where physical access is off the table entirely — enabling key custody, confidential compute, and attestation with a threat model that includes state-level adversaries. Next steps [#next-steps] * **Understand the fundamentals?** Read the [Concepts](/docs/concepts) — satellite communication, cosmic randomness, and why orbital compute changes the security model * **Ready to integrate?** Jump to [Fetch cTRNG values](/docs/how-to/ctrng) to get your first random number in minutes * **Prefer no dependencies?** [Fetch cTRNG values](/docs/how-to/ctrng#hit-the-ipfs-beacon-directly-no-sdk) covers reading the public IPFS beacon directly with curl or fetch * **Learn by building?** Follow the [Decision Picker tutorial](/docs/tutorials/decision-picker) to build your first Orbitport app from scratch * **Want full project examples?** Check out the [Recipes](/docs/recipes) — complete apps you can clone and run # Support & Contact (/docs/support) Developer Support [#developer-support] Join the community on Telegram for questions, bug reports, and discussions with the team and other developers. Join Telegram Contact Us [#contact-us] Have a question, feature request, or want to share feedback? Fill out the contact form and we'll get back to you. Contact Form Enterprise & Partnerships [#enterprise--partnerships] Interested in enterprise integration, custom deployments, or partnering with SpaceComputer? Reach out directly. [services@spacecomputer.io](mailto:services@spacecomputer.io) # How Cosmic Randomness Works (/docs/concepts/cosmic-randomness) Randomness is one of those things that seems simple until you actually need it to be good. Most of the time, a pseudorandom number generator is perfectly fine. But when the stakes are high (ex. cryptographic key generation, provably fair systems, regulatory compliance), then "good enough" randomness isn't *actually* good enough. Cosmic randomness is a different class of solution. It uses physical phenomena from outside the solar system to produce numbers that are genuinely unpredictable, and it does so in an environment where tampering is physically impossible. True random vs. pseudorandom [#true-random-vs-pseudorandom] This distinction matters, so let's be precise about it. Pseudorandom number generators (PRNGs) [#pseudorandom-number-generators-prngs] These are algorithms. You give them a seed value, and they produce a sequence of numbers that looks random. The output passes statistical tests, it's uniformly distributed, and for most practical purposes it behaves like random data. But it's deterministic. If you know the seed and the algorithm, you can reproduce the entire sequence. Every number is predictable in principle. Good PRNGs (like ChaCha20 or AES-CTR in counter mode) are computationally indistinguishable from random to anyone who doesn't know the seed. For simulations, games, A/B testing, and most application logic, PRNGs are the right tool. They're fast, they're well-studied, and they work. Early game PRNGs are often quite ingenious given the constraints. A favourite example is Elite (1984), which used a Fibonacci linear feedback shift register (LFSR): a handful of bytes, shifted and XORed in a loop. The same tiny seed always produces the same game universe, requiring almost no memory and no floating-point math. The "randomness" was an illusion produced by arithmetic so simple it ran on a 1 MHz processor. A fun example of how PRNGs may simply be not up to scratch is in early Pokemon games, where the player's movements and actions interact with the PRNG in a predictable way. Speedrunners use this to skip sections, jump to other parts of the game, and produce really strange things. True random number generators (TRNGs) [#true-random-number-generators-trngs] TRNGs derive their output from physical processes that are fundamentally non-deterministic. The numbers aren't computed from a seed: they emerge from physical phenomena that cannot be predicted or reproduced, even with complete knowledge of the system's state. Common TRNG sources include thermal noise in electronic circuits, radioactive decay, and photon arrival times. What makes these "true" randomness sources is that the underlying physics is genuinely stochastic. There is no hidden variable, no algorithm, no pattern. The randomness is intrinsic to the physical process. We stop here, before we drag you to the whole "free will" philosophical rabbit hole. Let's think about seeds instead. The seed problem [#the-seed-problem] The security of any PRNG depends entirely on the quality of its seed. If the seed has good entropy, the PRNG output is strong. If the seed is weak (i.e. derived from a predictable source like the system clock, process ID, or insufficient entropy) the entire output stream is compromised. This has caused real-world security failures. Debian's OpenSSL bug in 2008 reduced the effective seed entropy to about 15 bits, making every SSL key generated on affected systems trivially breakable. The Sony PlayStation 3 signing key was compromised because a "random" nonce was reused (effectively a constant seed). These aren't theoretical attacks, they're practical breaks caused by inadequate randomness. A TRNG eliminates the seed problem at its root. There is no seed to be weak. The randomness comes from physics, not from an algorithm initialized with hopefully-good entropy. Why you'd want a TRNG [#why-youd-want-a-trng] If PRNGs are good enough for most things, when do you actually need true randomness? **Cryptographic key generation.** The security of any cryptographic system ultimately rests on the quality of its keys. A key generated from a PRNG seeded with a weak entropy source is vulnerable. If an attacker can guess or reconstruct the seed, they can reproduce the key. True randomness eliminates this attack vector entirely: there's no seed to guess. **Provably fair systems.** Lotteries, gaming, random selection processes... anything where participants need to verify that the outcome wasn't manipulated. A PRNG-based system requires trust in the operator (they could know or control the seed). A TRNG-based system with public verifiability requires trust in nobody. **Compliance and audit requirements.** Some regulatory frameworks (financial services, government, defense) mandate the use of hardware random number generators for specific operations. Having a verifiable, auditable source of true randomness simplifies compliance. Auditors can verify the randomness source rather than having to audit the entire PRNG implementation and seed management chain. **Blockchain and Web3.** On-chain randomness is notoriously hard because blockchain environments are deterministic by design. Miners and validators can observe and potentially manipulate PRNG-based randomness, and as you may have guessed, this has happened already. An external, verifiable TRNG source provides randomness that no chain participant can predict or influence. **High-stakes decision systems.** Random jury selection, clinical trial randomization, resource allocation, or any context where the fairness and unpredictability of the selection process is legally or ethically critical. The stakes may be high enough that "probably random" isn't sufficient: you need "provably random". Cosmic radiation as an entropy source [#cosmic-radiation-as-an-entropy-source] SpaceComputer's cTRNG (cosmic True Random Number Generator) uses cosmic radiation as its entropy source. Cosmic rays are high-energy particles (mostly protons and atomic nuclei), the majority of which originates from outside the solar system. They come from supernovae, active galactic nuclei, and other violent astrophysical processes. By the time they reach Earth's orbital neighborhood, they arrive at random times, from random directions, with random energies. While its intensity increases with the distance to Earth (low earth orbits benefit partly from Earth's powerful magnetic field), it is still strong enough to be useful. Cosmic radiation is: **Genuinely unpredictable.** Cosmic ray arrival is a quantum-level stochastic process. No amount of information about previous arrivals gives you any predictive power over future arrivals. This isn't pseudo-randomness or chaos theory randomness, it's fundamental quantum indeterminacy. The same physics that makes radioactive decay unpredictable makes cosmic ray detection unpredictable. **Not reproducible.** Two identical detectors in the same location will record different cosmic ray events. The process cannot be rewound or replayed. There is no "seed" that determines the sequence of events. **Not manipulable.** You can't aim cosmic rays. You can't increase or decrease the flux in a targeted way. An attacker cannot influence the entropy source without, roughly speaking, controlling astrophysical processes light-years away. This isn't a circuit that someone could bias with a carefully applied electromagnetic field. **Abundant in orbit.** Earth's atmosphere absorbs most cosmic radiation before it reaches the surface. In low Earth orbit, the flux is significantly higher, giving satellite-based detectors a rich and continuous entropy source. The satellite doesn't have to wait for events; they happen constantly. Ground-based cosmic ray detectors work too, but they get a fraction of the flux that's available in orbit. **Independent of the hardware vendor.** The entropy comes from an external, astrophysical process, not from a property of the chip itself. This sidesteps concerns about hardware vendors introducing biases (intentionally or not) into on-chip entropy sources, a concern that has been raised about Intel's RDRAND instruction and other hardware RNGs. The cTRNG pipeline [#the-ctrng-pipeline] Here's how cosmic randomness gets from deep space to your application: 1\. Detection [#1-detection] The satellite carries dedicated hardware for cosmic radiation detection. SpaceComputer currently supports cEDGE and Crypto2 payloads. These instruments detect individual cosmic ray events such as arrival time, energy deposition, and interaction characteristics of each particle. The detectors operate continuously while the satellite is in orbit, accumulating events around the clock. Each event contributes entropy to the random number generation process. 2\. Random number generation [#2-random-number-generation] The raw detection data is processed onboard the satellite to extract entropy. The timing and characteristics of cosmic ray events are fed into a randomness extraction process that produces uniformly distributed random bytes. This processing happens on the satellite itself, in the physically isolated orbital environment. The extraction process ensures that the output is properly conditioned. Even if the raw cosmic ray events have some statistical structure (which they do: the flux rate varies with orbital position, for instance), the extracted random bytes are uniform and independent. 3\. Cryptographic signing [#3-cryptographic-signing] Before the random data leaves the satellite, it's cryptographically signed using a key that resides onboard. This signature serves as a proof of origin: it binds the random data to the specific satellite hardware that generated it. If anyone modifies the data in transit, the signature verification fails. This is a critical property. It's not just random data, but random data with a cryptographic guarantee of where it came from and that it hasn't been altered. The signing key never leaves the satellite, which means the physical isolation of orbit protects the integrity of the attestation chain. 4\. Ground station download [#4-ground-station-download] The signed random data is transmitted to ground stations during satellite pass windows (typically 5-15 minute windows as the satellite crosses overhead). The ground station receives the data and forwards it to Orbitport's terrestrial infrastructure. Because data is generated continuously but downloaded in bursts, there's an inherent batching pattern. A single pass might deliver hundreds or thousands of cTRNG values generated since the last contact. 5\. Distribution [#5-distribution] Orbitport makes the cTRNG data available through two channels: **The API.** `GET /api/v1/services/trng` returns cTRNG values on demand. This is authenticated via Auth0 OAuth2 and gives you the most control over what you get, such as specific sources or specific quantities. Use this when you need programmatic access with source selection control. **The IPFS beacon.** Every five minutes, Orbitport publishes a new block containing cTRNG values to IPFS. Each block includes a sequence number, timestamp, an array of random values, and a pointer to the previous block (forming a verifiable chain). The beacon is public: no authentication required, anyone can read it. Use this when you need a decentralized, publicly auditable randomness source. 6\. Verification [#6-verification] Any consumer of cTRNG data can verify the satellite's signature to confirm two things: the data was generated by the claimed satellite hardware, and the data hasn't been modified since generation. This is what makes the system auditable and trustworthy in a way that a traditional TRNG (which you have to trust the operator of) cannot match. The verification is independent. You don't need to trust Orbitport, the ground station operator, or anyone in the data path. You verify the satellite's signature yourself, and the physical isolation of the satellite ensures the signing key hasn't been compromised. If you consume beacon data from Rust, [ctrng-lib](https://github.com/spacecomputer-io/crypto-ctrng) handles the integrity side for you: it tracks the last served block, enforces timestamp monotonicity, rejects duplicates, and can XOR cosmic entropy with local OS entropy so an attacker would have to compromise both sources at once. Sources and fallback [#sources-and-fallback] Not every API call results in fresh satellite data. Satellites have limited pass windows, and demand may exceed the rate at which new cosmic randomness arrives on the ground. Orbitport handles this through a source hierarchy: **`aptosorbital` (satellite source).** Data generated directly by satellite hardware, with the full cryptographic signature chain. This is the gold standard: true cosmic randomness with provable origin. Availability depends on how recently the satellite has been in contact with a ground station. **`derived` (BIP32 derivation).** When fresh satellite data isn't available, Orbitport can derive additional random values from a cosmic master seed using BIP32 hierarchical derivation. The seed itself was generated in orbit from cosmic radiation, so the derived values inherit its entropy. They're not independently generated cosmic random numbers, but they're derived from one in a cryptographically sound way. For most applications, the distinction between direct and derived cosmic randomness is immaterial. **IPFS beacon (public fallback).** The beacon always has recent data and requires no authentication. It's a good fit for applications that don't need real-time values and prefer a decentralized access pattern. The TypeScript SDK (`@spacecomputer-io/orbitport-sdk-ts`) handles this fallback chain automatically. You call the SDK, it returns randomness, and it picks the best available source without you having to manage the logic. What makes this different [#what-makes-this-different] There are other TRNGs in the world. Hardware random number generators based on thermal noise or shot noise are common and well-trusted. What makes cosmic randomness via satellite distinctive is the combination of properties: 1. **The entropy source is astrophysical.** It's not a circuit on a chip that could theoretically be tampered with or biased by someone with physical access to the hardware. The randomness comes from cosmic ray events that no one controls. 2. **The hardware is in orbit.** The physical isolation guarantee means the detection and generation process is beyond anyone's physical reach. No one can bias the detector, modify the extraction algorithm, or tamper with the signing key. 3. **The output is signed.** Every cTRNG value carries a cryptographic proof of origin that anyone can verify independently. You don't have to trust the pipeline; you verify it. 4. **The distribution is public.** The IPFS beacon makes cosmic randomness a public good. It's verifiable, auditable, and accessible without credentials. No other randomness source provides all four of these properties simultaneously. For applications that need randomness they can prove is fair, prove is untampered, and prove was generated in an environment beyond physical access, cTRNG is purpose-built. How cTRNG compares to other randomness approaches [#how-ctrng-compares-to-other-randomness-approaches] To put cosmic randomness in context, here's how it stacks up against other common randomness sources: **`/dev/urandom` and OS entropy pools.** These are the standard source for most cryptographic operations. They mix entropy from hardware interrupts, disk timing, and other system events. They're excellent for general use, but the entropy quality depends on the system's environment, and there's no way to independently verify where the entropy came from. For most applications, `/dev/urandom` is the right choice. cTRNG adds value when you need provable, auditable entropy provenance. **Hardware RNGs (Intel RDRAND, ARM RNDR).** These use on-chip entropy sources (typically thermal noise in ring oscillators) and are fast and convenient. However, they're black boxes: you trust the chip vendor's implementation. There have been concerns about whether some implementations could contain backdoors. cTRNG's advantage is that the entropy source is external and astrophysical, not embedded in a chip from a single vendor. **Drand and other distributed randomness beacons.** Drand produces public, verifiable randomness through a distributed network of participants running a threshold BLS protocol. It's well-designed for on-chain randomness and public verifiability. The difference with cTRNG is the entropy source: Drand's randomness derives from the protocol's cryptographic assumptions, while cTRNG derives from physical cosmic events. Both are verifiable, but they have different trust assumptions. **VRFs (Verifiable Random Functions).** VRFs produce random outputs that can be verified against a public key. They're useful in blockchain contexts (Chainlink VRF, for example) but are ultimately deterministic. Given the same input and key, they produce the same output. They provide verifiability but not true randomness in the physical sense. Practical considerations for developers [#practical-considerations-for-developers] A few things to keep in mind when integrating cosmic randomness into your application: **Don't use cTRNG for everything.** If you're generating a random color for a UI element, use `Math.random()`. cTRNG is for operations where the provenance and quality of the randomness actually matters: key generation, fair selection, compliance-sensitive operations. Using orbital randomness for trivial purposes wastes a scarce resource and adds unnecessary latency. **Batch when you can.** Rather than requesting a single cTRNG value for every operation, fetch a batch and use them as needed. The IPFS beacon gives you 3 values every five minutes. The API can return multiple values per request. If your application generates keys or makes random selections periodically, maintain a small local pool of cTRNG values and draw from it. **Understand your freshness requirements.** For most cryptographic operations, the age of the random value doesn't matter. A 256-bit random value generated an hour ago has the same entropy as one generated a second ago. The time it was generated doesn't affect its unpredictability. But if your use case involves a time-bound commitment scheme (e.g., "prove this randomness was generated after event X"), freshness matters, and you should use the API with source selection rather than the IPFS beacon. **Use the signature for verification, not just the value.** If you're building a system where fairness needs to be auditable, store the full cTRNG response including the satellite's signature. This lets anyone verify after the fact that the randomness came from the satellite and wasn't substituted. The random value alone is just a hex string. The value plus its signature is the verifiable attestation that your security may depend on. **Plan for source variability.** Your application might get `aptosorbital` (direct satellite) data most of the time and `derived` data occasionally. Both are good randomness, and their difference is in provenance, not quality. If your compliance requirements mandate direct satellite randomness specifically, check the source field in the response and handle the `derived` case appropriately (queue the operation, alert, fall back to a different workflow). Further reading [#further-reading] * [Orbitport Architecture](./orbitport-architecture) -- how Orbitport manages sources, fallback, and the IPFS beacon * [Fetch cTRNG values](/docs/how-to/ctrng) -- practical guide to consuming beacon data through the SDK or directly with curl * [Verifying True Randomness in Cryptographic Systems](https://blog.spacecomputer.io/verifying-true-randomness-in-cryptographic-systems/) -- statistical testing, NIST SP 800-90B validation, and what external verification can and can't prove * [Ctrng-lib](https://blog.spacecomputer.io/ctrng-lib/) -- the Rust library for consuming cosmic randomness with integrity checks built in # Concepts (/docs/concepts) Most developer docs jump straight to "here's how to call the API." We could do that too: Orbitport is just a REST endpoint, after all. But the interesting part isn't the HTTP call, but what's behind it. SpaceComputer delivers services from satellites in low Earth orbit, and that changes things in ways that aren't obvious until you understand the underlying constraints. Why can't you just keep a persistent connection to a satellite? Why does the randomness come in batches? Why is physical isolation such a big deal for key generation? The answers live in orbital mechanics, thermodynamics, and the physics of cosmic radiation. Literally rocket science, but not so much. You don't need to know any of this to call `sdk.ctrng.random()`. But you'll make better architectural decisions if you do, and this is what's covered by these concepts pages. The foundations [#the-foundations] These pages cover the physics and cryptography that make orbital services different from anything terrestrial. None of them assume SpaceComputer exists — they explain the raw material. **[How Satellites Communicate](/docs/concepts/satellite-communication)** — Satellites in LEO aren't always reachable. They pass overhead in 5-15 minute windows, dump data to ground stations, and disappear below the horizon. This page explains the connectivity model and why it matters for the services you'll consume. **[Space Computing: Why Orbit Matters](/docs/concepts/space-computing)** — The whole point of computing in orbit is that no one can physically get to the hardware. That's a security property no data center can offer. But space is also a brutal environment for electronics. No airflow to cool components, limited power, cosmic radiation hitting your chips. This page covers the tradeoffs. **[How Cosmic Randomness Works](/docs/concepts/cosmic-randomness)** — Cosmic rays are *genuinely* random. Not pseudo-random or "random enough", but actually random in the quantum-mechanical, no-hidden-variables sense. This page traces the path from a cosmic ray hitting a satellite detector to a hex string landing in your application. **[Post-Quantum Cryptography and the Satellite Problem](/docs/concepts/post-quantum-cryptography)** — Quantum computers will break today's public-key cryptography on a timeline that overlaps with the lifespan of satellites launching now. And you can't re-key silicon in orbit. This page covers the threat, the NIST replacements, and why crypto-agility matters most for hardware you can't touch. The platform [#the-platform] These pages cover what SpaceComputer actually built on top of those foundations, from the satellite hardware up to the API you call. **[Orbitport: Gateway to Orbital Services](/docs/concepts/orbitport-architecture)** — Orbitport is the layer that turns all the orbital complexity into a normal-looking API. Plugin architecture, source selection, the IPFS beacon, and where the system is headed. **[Space Fabric: The Trust Layer in Orbit](/docs/concepts/space-fabric)** — The hardware and protocol stack on the satellites themselves. Dual secure elements from independent vendors, signing keys that have never existed on Earth, and attestation that proves your code runs in orbit rather than in a warehouse. **[Key Management Beyond the Data Center](/docs/concepts/orbital-kms)** — Every security guarantee bottoms out in a key, and a key is only as trustworthy as the place it was born. This page explains the custody ladder, the key-generation supply chain problem, and the roadmap from attested terrestrial TEEs to keys held in orbit. **[SpaceTEE: Trusted Execution from Orbit](/docs/concepts/spacetee)** — TEEs like SGX and TrustZone protect code from the software stack, but the hardware is still physically accessible. SpaceTEE puts the TEE in orbit, where physical access is off the table entirely. This page covers what that means and what it enables. After this [#after-this] The [How-to Guides](/docs/how-to) cover integration — installing the SDK, configuring auth, working with the IPFS beacon. The [Tutorials](/docs/tutorials) walk you through building apps from scratch. The [Recipes](/docs/recipes) are complete projects you can clone and run. # Key Management Beyond the Data Center (/docs/concepts/orbital-kms) Almost every guarantee in modern security bottoms out in a key. From the HTTPS "padlock" we tell our grandmother to check for, to the verified software update, to the on-chain transaction, and the attestation that says a TEE is running the right code, each involves a signature, and each signature is only as trustworthy as the private key behind it. Which raises two questions that are easy to ask yet a bit uncomfortable to answer. Where does that key live? And where was it *born*? This page is the thinking behind [SpaceComputer's KMS](/docs/how-to/kms). The how-to guide shows you the API calls; this one explains why a key management service is worth running on infrastructure that ends its life burning up in the atmosphere. Signing key guarantees [#signing-key-guarantees] Quick recap: a signing key is the private half of an asymmetric key pair, and we can produce signatures with it. The public half verifies them. Anyone holding the public key can check that a signature was made with the corresponding private key, without ever seeing that private key. From that one asymmetry you get three guarantees: * **Authentication** -- a valid signature proves who produced the data. * **Integrity** -- it proves the data hasn't been altered since. * **Non-repudiation** -- the signer can't later deny having signed it. This asymmetry is at the core of most modern day communication, but it collapses the moment anyone *other* than the legitimate owner can use the key. That simply means copying it: just like a normal household key, a copy is as good as the original, and leaves no evidence. That's what makes key custody such an unforgiving problem: you're defending against an attack you may never detect. The custody ladder [#the-custody-ladder] Where a key lives determines how hard that attack is. There's also a tradeoff between safety, flexibility, cost, and usability. But let's try to "rank them" roughly in ascending order of paranoia: 1. **A file on disk, or application memory.** One OS compromise and the key is gone. This is how most keys in the world are stored, which should worry you. Some of them aren't even encrypted... 2. **A TPM.** The key sits in a dedicated chip, so the extraction requires more than a filesystem read. 3. **An HSM.** Purpose-built hardware where private keys never leave in plaintext, with enforced access policies and physical tamper-proof mechanisms. Extremely expensive to own and operate. They're the banking and CA standard. 4. **A secure element.** Keys are generated *on-chip* and sign without ever being exposed. You can find these in smartphones, and they're small enough to fly on a satellite. 5. **A secure element paired with a TEE.** Same as above, but the workload can request signatures without even being able to see the private half. Cloud KMS offerings (AWS KMS, GCP Cloud KMS) live around rungs 3-4, and they're good. If your threat model is as simple as "attacker steals a laptop" or "developer leaks an env var", a cloud KMS solves your problem and you can stop reading. If your threat model is "storing private keys you use to communicate with a satellite", you're not there yet. The paranoia ladder measures the wrong thing if you climb it and ignore two questions it doesn't answer: who *else* can walk up to the hardware, and *where* was the key generated in the first place? The generation problem [#the-generation-problem] Storage gets all the attention, but a key is most vulnerable at birth. Most commercial secure hardware is provisioned during manufacturing: the key is generated (or worse, injected) in a factory, then the device ships. That means there was a moment when the key existed in a place full of people and processes you will never see. Trusting the device means trusting that the manufacturer generated it correctly, kept no copies, erased every trace, and that all of this can be audited, which for an outside party it usually can't. If you deploy on someone's platform, you inherit their key custody decisions, their supply chain, and their factory floor. This isn't hypothetical pedantry. In 2011, attackers [stole the seed values RSA had generated and retained](https://www.theregister.com/2011/06/06/lockheed_martin_securid_hack/) for its SecurID tokens, then used them against RSA's own customers, including Lockheed Martin. The compromise happens before you ever take delivery, so no amount of operational security afterward helps. As [the SpaceTEE page](./spacetee) argues for compute, the only fix is to remove the window entirely rather than promise harder. What orbit changes [#what-orbit-changes] [Space Fabric](./space-fabric), SpaceComputer's satellite architecture, closes the window by refusing to create keys on Earth at all. Key slots are verified empty before launch. On first boot in orbit, the two onboard secure elements generate their own keys internally, from their own entropy, and mark them non-exportable in hardware. No Space Fabric signing key has ever existed on Earth. For key management specifically, that yields properties no terrestrial KMS can offer: **Custody nobody can visit.** The hardware holding your keys is at 500+ km, moving at 7.5 km/s. The entire category of physical attacks (probing a chip, tapping a bus, coercing a technician) requires nation-state anti-satellite capability, and even then destroys rather than extracts. Compare the [space computing page](./space-computing) on physical isolation as a security property. **Verifiable generation.** Because the pre-launch registration contains only public information (serial numbers, hardware certificates, configuration hashes), you don't have to trust that secrets were handled well. There were no secrets. You verify the generation policy and its attested output instead. **Provable disposal.** When the satellite de-orbits, the keys are destroyed by atmospheric re-entry along with the silicon holding them. Key deletion is normally the *least* verifiable operation a KMS performs: you get an API response saying "deleted" and a compliance checkbox. Re-entry is deletion you can, in principle, watch. From here to there: the KMS roadmap [#from-here-to-there-the-kms-roadmap] Before we go and launch all the satellites into space, let's recalibrate: the KMS you can call today does not run on a satellite yet. SpaceComputer is deliberately walking it up a trust ramp: **Phase 1 (EarthKMS) -- attested terrestrial TEEs.** Key operations execute inside hardware-attested trusted execution environments on the ground. You interface through [Orbitport](./orbitport-architecture) using the same gateway, auth, and SDK as cTRNG, and remote attestation lets integrators verify the environment handling their keys cryptographically rather than contractually. The supported schemes today (TRANSIT for general-purpose encryption and signing, ETHEREUM for secp256k1/EIP-191) are documented in the [KMS how-to](/docs/how-to/kms). This is a different trust model from HSM-backed offerings, and in several ways a stronger one: you verify the environment handling your keys instead of taking someone's word for it. **Phase 2 -- threshold cryptography.** Operations get distributed across multiple independent parties, each running a partial signer inside its own TEE. No single participant, SpaceComputer included, holds enough key material to sign or decrypt unilaterally. This removes the single-operator trust assumption before the hardware even leaves the ground. **Phase 3 (SpaceKMS) -- space-native keys.** Hybrid Earth/orbit key storage, moving toward keys generated and held on Space Fabric hardware: born in orbit, non-exportable, physically unreachable, destroyed on re-entry. Early orbital deployments run as hardened proofs-of-concept first, and rolled out to production afterwards. :::warning The current KMS is **experimental** across all of this -- interfaces and guarantees are still moving, and you shouldn't protect production data with it yet. The [how-to guide](/docs/how-to/kms) spells out the caveats. ::: Further reading [#further-reading] * [Use the KMS](/docs/how-to/kms) -- create keys, encrypt, sign, and rotate through the SDK * [SpaceComputer Secure Key Management Services Beyond the Cloud](https://blog.spacecomputer.io/kms-beyond-cloud/) -- the roadmap post this page draws on * [What Is a Signing Key? Key Generation in Low Earth Orbit](https://blog.spacecomputer.io/what-is-a-signing-key/) -- the custody-ladder argument in full * [Space Fabric](./space-fabric) -- the hardware that makes "keys born in space" literal # Orbitport: Gateway to Orbital Services (/docs/concepts/orbitport-architecture) Satellites are complicated infrastructure. Orbital mechanics, ground station scheduling, communication protocols, data buffering, pass windows... none of this is something an application developer should have to think about. But if you're curious, head to the [satellite communication](./satellite-communication) concepts page. Orbitport is the abstraction layer that makes orbital services consumable through standard web APIs. One endpoint, one SDK, and the orbital complexity stays behind the curtain. What Orbitport does [#what-orbitport-does] At its core, Orbitport is a gateway. It sits between your application and a growing constellation of satellite providers, handling: * **Data ingestion** from satellites via ground stations * **Source management** across multiple providers and hardware payloads * **Authentication and access control** * **Automatic source selection and fallback** when a given source is unavailable * **Public data distribution** through the IPFS beacon * **Signature verification** to ensure data integrity from satellite to consumer You interact with Orbitport the way you'd interact with any REST API. The fact that the data originates from hardware moving at 7.5 km/s in low Earth orbit is, from your application's perspective, an implementation detail. The plugin architecture [#the-plugin-architecture] Orbitport is designed around a three-layer plugin architecture. This is an internal design choice, and allows the system to scale to new satellites, new providers, and new services without redesigning the core. Orbitport Architecture Celestial layer [#celestial-layer] This is the satellite side. Each satellite provider integrates as a plugin that speaks the provider's native protocol and translates data into Orbitport's internal format. Currently, the celestial layer supports these payloads: * **cEDGE**: cosmic radiation detection hardware that generates cTRNG values * **Crypto2**: an additional payload with similar capabilities As more satellite operators come online with orbital compute or sensing services, they integrate at this layer. The rest of the stack doesn't need to change. Terrestrial layer [#terrestrial-layer] This layer handles ground station infrastructure and communication. It manages: * Scheduling and prioritizing satellite passes * Receiving and buffering data downloads * Routing data from ground stations to Orbitport's processing pipeline Different ground station networks can plug in here. Some providers operate their own ground stations, while others use shared networks. The terrestrial layer normalizes these differences. Application layer [#application-layer] This is what you interact with. The application layer exposes orbital services through clean, documented APIs: * **cTRNG**: cosmic True Random Number Generation, available now * **spaceTEE**: Trusted Execution from orbit, on the roadmap Each service has its own API surface, but they share common infrastructure for authentication, rate limiting, and source management. What Orbitport abstracts away [#what-orbitport-abstracts-away] Satellite infrastructure has properties that would be painful to deal with directly. Data arrives in batches during short pass windows, not as a continuous stream. Latency is variable — seconds if data was recently downloaded, or you might be pulling from a buffer that's minutes old. Availability depends on orbital mechanics: predictable gaps, but gaps nonetheless. None of this is your problem. Orbitport's entire job is to make orbital services feel like calling a normal API. The source selection picks the freshest available data. The IPFS beacon publishes every five minutes regardless of satellite pass schedules, so there's always something recent. The SDK handles fallback automatically. Your code calls `sdk.ctrng.random()` and gets a value. Where it came from and how it got to the ground, all of that is handled behind the curtain. One thing worth understanding: "freshness" means something different for randomness than for most data. A cTRNG value generated twenty minutes ago is exactly as random as one generated a second ago. Randomness doesn't expire. So even when satellite contact is intermittent, the data you get is no less useful. The only case where freshness matters is if you need to prove a value was generated *after* some event. And for that, the IPFS beacon's timestamped blocks have you covered. If you want to understand the satellite communication model that creates these constraints, see [How Satellites Communicate](./satellite-communication). But for integration purposes, you can treat Orbitport as a normal REST API. Source selection and the fallback chain [#source-selection-and-the-fallback-chain] One of Orbitport's most important jobs is deciding where your data comes from. Not all sources are equal, and not all sources are always available. When you request cTRNG data, Orbitport evaluates available sources and picks the best one: Primary: `aptosorbital` [#primary-aptosorbital] Direct satellite data. Random bytes generated from cosmic radiation by satellite hardware, cryptographically signed onboard. This is the highest-assurance source: true cosmic randomness with full provenance. Availability depends on satellite passes. If the satellite recently passed over a ground station, fresh data is in the buffer. If not, this source may be temporarily unavailable. Secondary: `derived` [#secondary-derived] When fresh satellite data isn't in the buffer, Orbitport can derive additional random values using BIP32 hierarchical key derivation from a cosmic master seed. The master seed was generated in orbit from cosmic radiation, so derived values inherit its entropy properties. This is a practical tradeoff. Derived values aren't independently generated cosmic random numbers, but they're cryptographically derived from one. For most applications, derived randomness is indistinguishable from direct satellite randomness in terms of quality. The difference matters mainly for auditability: you can't trace a derived value back to a specific cosmic ray event. Public: IPFS beacon [#public-ipfs-beacon] The IPFS beacon operates on a fixed five-minute publishing cycle, independent of API requests. It's always available, requires no authentication, and provides a public, append-only record of cTRNG values. The TypeScript SDK (`@spacecomputer-io/orbitport-sdk-ts`) implements this fallback chain automatically. You make one call, the SDK evaluates source availability, and returns the best data it can get. You can also request specific sources explicitly if your application requires it. The IPFS beacon in detail [#the-ipfs-beacon-in-detail] The beacon deserves its own section because it serves a dual purpose: it's both a fallback data source and a public transparency mechanism. Every five minutes, Orbitport publishes a new block to IPFS with the following structure: ```json { "previous": "/ipfs/bafkrei...", "data": { "sequence": 87963, "timestamp": 1769179239, "ctrng": [ "88943046891c6c971f185c7cd69a350d...", "802a5afa3b09c360ec56cbe67cb615e0...", "dbbe94501ed32c55acb4ad4512da0c38..." ] } } ``` Each block contains: * **`sequence`** -- a monotonically increasing block number * **`timestamp`** -- Unix timestamp of block creation * **`ctrng`** -- an array of cTRNG values (currently 3 per block, but this may increase) * **`previous`** -- an IPFS CID pointing to the prior block, forming a chain The chain structure means anyone can traverse the full history of published randomness. This is important for applications that need to audit or verify randomness after the fact. Lottery results, random selection processes, anything where fairness needs to be provable. Because the beacon uses IPNS for its stable address, consumers always fetch the latest block from the same URL. The IPFS content-addressing guarantees that once a block is published, it can't be retroactively modified without changing its CID (and breaking the chain). No authentication is required to read the beacon. It's a public good. Authentication [#authentication] API access to Orbitport uses OAuth2 via Auth0. The flow is standard: 1. You register and receive a client ID and client secret. 2. Your server exchanges these credentials for an access token. 3. You include the token in API requests as a Bearer token. 4. Tokens expire and need to be refreshed. The SDK handles token lifecycle automatically if you provide credentials. For server-side integrations, the recommended pattern is a proxy that manages tokens centrally and exposes a simpler interface to your client-side code. The IPFS beacon, by contrast, requires no authentication at all. API surface [#api-surface] The current API is focused on cTRNG: ```text GET /api/v1/services/trng ``` This returns cosmic random data from the best available source. You can specify source preferences and other parameters. Full details are in [Fetch cTRNG values](/docs/how-to/ctrng). As SpaceComputer adds services (starting with spaceTEE), new endpoints will appear under the same base URL, using the same authentication and the same SDK. Current state and what's ahead [#current-state-and-whats-ahead] Today, Orbitport operates as a centralized gateway. All requests flow through SpaceComputer's infrastructure, which manages satellite data ingestion, source selection, and distribution. This is the pragmatic starting point: it works, it's simple to integrate with, and it lets the team iterate on the satellite infrastructure without breaking consumer APIs. Centralized doesn't mean take-our-word-for-it, though. The gateway itself is built to be verifiable: the OS image is a reproducible build (same inputs, bit-identical binary), containers run from hardened images whose digests are checked at boot and locked into hardware measurement registers, and the TLS connection you open can carry a live attestation quote proving exactly which build you're talking to. The details are in [Making Orbitport Verifiable](https://blog.spacecomputer.io/making-orbitport-verifiable/). The roadmap moves toward a more distributed, resilient system: **More satellites.** The plugin architecture means adding a new satellite provider is an integration task, not a redesign. Each new satellite increases the volume and freshness of available data. **More services.** cTRNG is the first orbital service. SpaceTEE (trusted execution in orbit) is next. The same architectural layers - celestial, terrestrial, application - support both. **More providers.** Orbitport is designed to be provider-agnostic. As the market for orbital compute services grows, multiple satellite operators can feed into the same gateway. **Distributed operation.** The long-term vision is a permissioned network of Orbitport nodes, reducing single-point-of-failure risk and enabling geographic distribution of the gateway itself. The IPFS beacon is an early step in this direction: its distribution already has no single point of failure. For developers integrating today, the key point is that the API surface is stable even as the backend evolves. Your integration code won't need to change as Orbitport adds satellites, providers, and services behind the same endpoints. Further reading [#further-reading] * [Orbitport: The Gateway to Space](https://blog.spacecomputer.io/orbitport-gateway-to-space/) -- the launch post introducing the gateway * [Making Orbitport Verifiable](https://blog.spacecomputer.io/making-orbitport-verifiable/) -- reproducible builds, hardened images, and attested TLS in depth * [Space Fabric](./space-fabric) -- the satellite-side trust architecture the gateway fronts # Post-Quantum Cryptography and the Satellite Problem (/docs/concepts/post-quantum-cryptography) Here's an uncomfortable piece of arithmetic: * A satellite launched today will operate for five to fifteen years. * Credible estimates for "Q-Day", the arrival of a quantum computer big enough to break current public-key cryptography, cluster between 2029 and 2035. See the problem here? Those two timelines overlap, and unlike your web server, a satellite can't be re-keyed with a maintenance window and an apology email. The cryptographic decisions baked in at design time govern the entire mission. In fact, this is such a big problem, Google has already pulled its internal post-quantum deadline forward to 2029. The deadline is quite real, and orbital hardware happens to be the hardware least equipped to miss it. The 60-second version of the problem [#the-60-second-version-of-the-problem] Today's public-key cryptography (RSA, elliptic curves, Diffie-Hellman) rests on math problems classical computers can't solve in any useful timeframe: factoring big integers, and computing discrete logarithms. Breaking a 2048-bit RSA key classically takes longer than the universe has been around! However, *non-classically*, things take a big turn. Shor's algorithm, published back in 1994, solves exactly those problems exponentially faster on a quantum computer. The catch has always been building a quantum computer large and stable enough to run it. Once one exists, everything downstream of RSA and ECC becomes forgeable or readable: TLS handshakes, code signing, on-chain transactions, etc. Post-quantum cryptography (PQC) is the fix, and it's less exotic than it sounds: new algorithms built on math problems (mostly lattices and hash functions) that *neither* classical nor quantum computers can crack efficiently. There's no specific hardware required to implement it, although not all chips are ready to accelerate these operations to the same speeds as classical cryptography. PQC runs on the same servers, phones, and satellite computers as today's cryptography, and NIST has even standardized the replacements: | Standard | Based on | Replaces | | ---------------------------- | --------------------------- | ----------------------------- | | **ML-KEM** (FIPS 203) | CRYSTALS-Kyber, lattice | RSA / DH key exchange | | **ML-DSA** (FIPS 204) | CRYSTALS-Dilithium, lattice | RSA / ECDSA signatures | | **SLH-DSA** (FIPS 205) | SPHINCS+, hash-based | conservative signature backup | | **FN-DSA** (FIPS 206, draft) | FALCON, lattice | compact signatures (\~2027) | So the migration story is not "wait for the standards". That ship has sailed a few years ago. The story is deployment, and deployment is where satellites get interesting. Threat one: harvest now, decrypt later [#threat-one-harvest-now-decrypt-later] Most of us fall in the "we're safe until Q-Day" trap. Unfortunately, it's not that easy, because encrypted data can be recorded. Let us fuel those nightmares a little bit: An adversary who captures your encrypted traffic today can simply store it and decrypt it the day quantum hardware catches up. This is called *harvest now, decrypt later*, and the more you think of it, the longer you'll stay awake at night. When you visit a website and you establish an SSL handshake with it, *that handshake may not be quantum safe*. Someone capturing that handshake can *and will* decrypt it in a few years. For satellite links this is somehow even worse: downlinks are radio broadcasts over huge footprints. Anyone with a dish and patience can record them. The [satellite communication page](./satellite-communication) explains why interception has always been assumed in link design. So for PQC, the question we want to ask isn't "when does quantum arrive?" but "will this data still matter when it does?". If it's telemetry with a shelf life of minutes, nobody cares. But earth-observation imagery, key material, anything sovereign or medical or proprietary with a ten-year confidentiality requirement... it's already exposed, today, if it crosses a link protected only by classical key exchange. That's what makes ML-KEM the urgent half of the migration. Confidentiality is the guarantee you can lose retroactively. Threat two: forged history [#threat-two-forged-history] The subtler casualty is attestation. Remote attestation, the mechanism [SpaceTEE](./spacetee) and [Space Fabric](./space-fabric) build on, is a chain of signatures rooting in keys fused into silicon. When quantum computers can break the elliptic-curve keys at those roots, an attacker can do worse than impersonate hardware going forward: they can fabricate plausible-looking evidence about the *past*. Any historical attestation, audit log, or command-provenance record verified only by a quantum-broken key stops being evidence. For confidentiality you can at least triage by data lifetime. But for integrity of records, the deadline is harder: the fix requires new roots of trust, and the industry's current confidential-compute platforms all root trust in ECC keys provisioned at fabrication. Replacing those is a hardware cycle, which takes a decade or so (one exception: hash-based constructions. Signatures like SLH-DSA and hash-based proof systems lean only on hash functions, which quantum computers merely dent rather than break. A proof generated in 2026 stays verifiable in 2040 regardless of how Q-Day shakes out.) Now add the orbital constraint from the top of the page: you cannot swap silicon at 500 km. A satellite that launches with a quantum-vulnerable, non-upgradable root of trust has a cryptographic expiration date, and it was set on launch day. Crypto-agility, or "don't marry an algorithm" [#crypto-agility-or-dont-marry-an-algorithm] The design lesson generalizes past satellites. Since standards will keep evolving (FN-DSA is still in draft, parameters get revised, implementations get broken, etc), the systems that survive the transition are the ones where swapping an algorithm is a configuration change, not a hardware revision or a code rewrite. That property has a name, *crypto-agility*. It's pretty cheap at design time but brutally expensive to retrofit. The most common and practical pattern during the transition is **hybrid deployment**: run a classical algorithm and a post-quantum one together (ex. X25519 *and* ML-KEM for key exchange, or ECDSA *and* ML-DSA for signatures), so security holds as long as either layer does. You pay a cost, since PQC keys and signatures are larger, and that stings precisely where satellites hurt most: on constrained radio links. But you're never worse off than the stronger of the two schemes. If you operate anything with a long deployment life, satellite or otherwise, three questions are worth asking your vendors now: 1. Are the algorithms NIST PQC standards, or something bespoke? 2. Can the system swap algorithms without hardware changes? 3. What's the actual migration timeline if Q-Day lands in 2029 rather than 2035? How SpaceComputer handles it [#how-spacecomputer-handles-it] [Space Fabric](./space-fabric) was designed after this problem was visible, which bought it the luxury of being algorithm-agnostic from the start. The attestation, endorsement, and verification layers treat the signature scheme as pluggable rather than welded in. The concrete plan is the hybrid pattern above, applied to orbit. Hardware-bound elliptic-curve keys in the secure elements keep doing what they're uniquely good at, which is binding identity to one specific physical chip, while quantum-resistant signatures (ML-DSA) are layered on top in software, with the satellite's TPM as an independent root of trust for post-quantum provisioning. Current secure elements don't natively speak PQC yet (almost none do), so this hybrid path is how you get quantum resistance without waiting a hardware generation. The measured overhead is tolerable even on space links: attestation exchanges grow from about 1.9 kB to about 8 kB under the hybrid ECC + FALCON configuration. The honest status: this is a migration in progress, not a solved checkbox. Which is exactly the posture the timeline math demands from anyone launching hardware this decade. Further reading [#further-reading] * [What Is Post-Quantum Cryptography?](https://blog.spacecomputer.io/what-is-post-quantum-cryptography/) -- the fundamentals, algorithm families, and a five-step readiness checklist * [The Post-Quantum Cryptographic Expiration Date on Every Satellite You're Launching](https://blog.spacecomputer.io/post-quantum-cryptography-satellites/) -- the satellite-specific argument in full * [Space Fabric](./space-fabric) -- where the hybrid PQC roadmap lands in the hardware * [NIST Post-Quantum Cryptography project](https://csrc.nist.gov/projects/post-quantum-cryptography) -- the standards themselves # How Satellites Communicate (/docs/concepts/satellite-communication) If you've only worked with terrestrial infrastructure, there's one thing you don't usually think about: uptime. If you can't reach a service, that's because your connection is down, or more rarely, the service is down. With satellites, there's a third possibility: the satellite is just not in range. While cloud servers are always on, always reachable, and round-trip times are measured in milliseconds, satellites in low Earth orbit are none of those things. So, understanding the connectivity model is essential because it shapes how every orbital service works, including the ones you'll integrate through [Orbitport](./orbitport-architecture), which, fortunately, attempts to abstract that away from you as a developer. Low Earth Orbit: the basics [#low-earth-orbit-the-basics] The satellites that power SpaceComputer's services orbit at roughly 500-2000 km altitude. This is called Low Earth Orbit, a very fast orbit that is not so far away to make latency unbearable, but also not so close that it decays easily. For example, the ISS operates at \~400km and Starlink satellites at \~500km. At that height, orbital mechanics dictate a period of about 90 minutes per revolution around the Earth. The satellite is moving *very* fast, around 7.5 km/s relative to Earth's surface, which poses some interesting challenges. First of all, the range. If you're taking off on an airplane, maybe only half the city sees you. If you're 10km away, then maybe a small country sees you. If you're 500km away, then maybe the whole Europe sees you. This is why you can literally see the ISS flying above you at night. Here's a graphic of the [CUTE](https://db.satnogs.org/satellite/YMFQ-1347-4330-8510-2436) satellite passing over Europe: CUTE satellite pass Anyway, from any given ground station's perspective, the satellite rises above the horizon, crosses the sky, and sets again in about 5 to 15 minutes. That's your communication window. Once it drops below the horizon, you're done until the next pass, which could be hours later depending on the orbit geometry and how many ground stations you have. This is nothing like a data center. There is no persistent TCP connection. There is no always-available endpoint. The satellite is reachable in short bursts, and everything about the system has to be designed around that constraint. Why LEO specifically? [#why-leo-specifically] Higher orbits are great for their own reasons. For example, geostationary earth orbit (GEO) satellites are so far away that they move at the same speed as the Earth spins around itself. From an earth standpoint, they're stationary and theoretically accessible 24/7 from basically half the globe, making them very useful for weather, surveillance, and communication. Unfortunately that means they orbit *very* far away, like \~36000km away. This means that placing a GEO satellite is incredibly expensive and latency is unbearable for synchronous communication, and radiation wants to fry their electronics like a breakfast egg. These electronics need to be so heavily shielded from cosmic radiation, they aren't as fast as we wanted to and have less "computational density". LEO, however, has compelling advantages for compute workloads. The lower altitude means lower launch costs, lower radiation exposure for electronics, and lower signal latency during passes. The tradeoff is the short pass windows, but for services like cTRNG, where data is generated continuously and downloaded in batches, LEO is the right choice. Most of the new space economy operates in LEO. The satellites are smaller, cheaper to build and launch, and can be replaced more frequently as hardware improves. This is the orbit that makes commercial space computing economically viable. Orbital geometry and pass frequency [#orbital-geometry-and-pass-frequency] A satellite's orbit isn't random. It follows a precise, predictable path determined by its altitude, inclination (the angle of the orbital plane relative to the equator), and other parameters. This means you can predict exactly when a satellite will be visible from a given location, weeks or months in advance. For a typical LEO satellite in a polar or near-polar orbit, a ground station near the equator might see the satellite 4-6 times per day, with each pass lasting 5-15 minutes. A ground station at higher latitudes sees more passes from polar-orbiting satellites, because the orbital tracks converge near the poles. This predictability is both a constraint and an advantage. You know exactly when data will arrive, which lets you plan around it. But you also know exactly when you won't have connectivity, which your system has to handle gracefully. Ground stations: the intermediary [#ground-stations-the-intermediary] A ground station is the physical link between terrestrial networks and the satellite. It has an antenna (often a tracking dish that follows the satellite across the sky), a radio transceiver, and networking equipment to bridge into the internet. If it sounds easy, that's because it is, and [you can run your own DIY ground station for less than $100](https://wiki.satnogs.org/Build). Of course, it won't be reliable enough for commercial usage, but it follows the same principle as the ground stations we use at SpaceComputer. When a satellite passes over a ground station, the two establish a link and exchange data as fast as they can before the pass ends. This creates a store-and-forward model: 1. The satellite collects or generates data while in orbit (e.g., cTRNG values from cosmic radiation detection). 2. It stores that data onboard until a ground station is in range. 3. During the pass window, it dumps the buffered data to the ground station. 4. The ground station forwards the data to terrestrial servers (like Orbitport). The more ground stations you have, the more frequently you can download data. A single station might get 4-6 passes per day from a given satellite. A network of stations spread across different latitudes can increase that substantially, potentially getting a download opportunity every orbit. Ground stations connect to one satellite at a time, dealing with every detail like pointing, encrypting, encoding, dealing with delay, transmission errors, and all the other environmental factors. Optimizing for these windows makes talking to satellites its own business, although some ground stations are used to talk exclusively to some satellites (ex. your neighbour's Starlink dish). Others are used for research purposes but they'll be happy to help you communicate if you schedule communication windows in advance. If this sounds "analog", that's because it often is: just like you'd schedule a few minutes in your university's supercomputer in 1960, you often need to arrange your comm slot via e-mail with some person working 9-5 on the other side. Pass scheduling [#pass-scheduling] Scheduling matters. Each pass has to be planned: which satellite talks to which station, what data gets prioritized, how much bandwidth is available in the window. When multiple satellites share a ground station network, passes can conflict. Two satellites might be visible simultaneously, but the antenna can only track one at a time. Ground station operators maintain detailed schedules, allocating pass time across their customer base. For SpaceComputer, this means the rate at which new data arrives on the ground (ex. cTRNG) depends not just on how fast the satellite generates it, but on how much ground station time is available and how it's prioritized. This is an operational layer that terrestrial developers never have to think about, but directly affects the freshness and availability of the data you consume through Orbitport. Ground station networks [#ground-station-networks] Individual ground stations have limited coverage. A station in Norway sees different passes than one in Chile. To maximize contact time with a satellite, operators distribute stations across multiple latitudes and longitudes. Several commercial ground station networks (like AWS Ground Station, KSAT, and Leaf Space) offer ground-station-as-a-service by operating multiple, geographically distributed ground stations. Satellite operators can rent time on antennas around the world rather than building and maintaining their own stations, which dramatically lowers the barrier to operating a satellite. Communication bands [#communication-bands] Satellites communicate with ground stations using radio frequencies. Two approaches are relevant here: S-Band (traditional) [#s-band-traditional] S-Band (2-4 GHz) is the workhorse of small satellite communications. It's reliable and well-understood, but bandwidth is limited: typically a few Mbps at best. For SpaceComputer's workloads (random number data, attestation payloads, signed messages), this is more than sufficient. The constraint isn't bandwidth per se, it's the combination of limited bandwidth and limited pass windows. You get a few megabits per second which is *okay* but... only for a few minutes. That puts a ceiling on how much data you can move per pass. To put this in perspective, a single cTRNG value is 32 bytes. At even 1 Mbps, you can transfer tens of thousands of random values in a single pass, so it's clear that the bottleneck for randomness delivery isn't bandwidth but it's the generation rate of the onboard hardware and the frequency of ground station contacts. LEO constellation relays [#leo-constellation-relays] Services like Iridium and Starlink have changed the game by building satellite-to-satellite links. Instead of waiting for your satellite to pass over a ground station, it can relay data through a constellation of interconnected satellites that always have at least one node in contact with the ground. This provides near-continuous connectivity. The tradeoff is cost and complexity: you need compatible hardware on your satellite and a commercial agreement with the constellation operator. But it eliminates the store-and-forward model entirely for satellites that support it. Iridium's network covers the entire Earth's surface, including the poles and oceans. Starlink's inter-satellite laser links offer high-bandwidth relay capability. For orbital compute services that need lower latency and higher availability, constellation relay is increasingly attractive. SpaceComputer's infrastructure can work with both models. Some satellites rely on direct ground station passes, others may use constellation relay links for lower-latency data delivery. The Orbitport abstraction layer aims to handle both transparently and abstract these complexities away from you. What about latency? [#what-about-latency] Some back-of-the-napkin math tells us that speed of light to LEO and back adds about 3-10 ms of propagation delay depending on altitude. That's negligible compared to terrestrial internet latency, which is often higher and using much more complex infrastructure. But again, for most use-cases the real latency challenge isn't signal propagation: it's waiting for the satellite to be *reachable*. If you're using direct ground station passes, "latency" isn't really the right concept. It's more like "data age": how long ago was this data generated onboard? It could be minutes or hours, depending on when the last pass occurred. With constellation relay, you get closer to traditional latency semantics. The satellite relays data through the constellation in near-real-time, and the total path might add a few hundred milliseconds. Meaningful, but workable for most applications. Comparing communication models [#comparing-communication-models] It helps to see these approaches side by side, especially if you're deciding how much latency and freshness variability your application can tolerate. Direct ground station passes only [#direct-ground-station-passes-only] This is the simplest and cheapest model. The satellite stores data onboard, downloads it during passes, and the data makes its way to Orbitport. You'll see data freshness ranging from a few minutes to a few hours depending on how recently a pass occurred. Orbitport's IPFS beacon and derived randomness source smooth over the gaps. For cTRNG consumers, this model works well. Randomness doesn't have a shelf life: a random number generated two hours ago is exactly as random as one generated two seconds ago. Constellation relay (Iridium, Starlink) [#constellation-relay-iridium-starlink] With relay, data can reach the ground within seconds of generation. The satellite sends data to the nearest constellation node, which hops it through the mesh to a ground-connected node. Freshness drops from hours to seconds. The cost is higher: relay bandwidth isn't free, and the satellite needs compatible hardware. But for services where near-real-time delivery matters (think SpaceTEE computation results, or time-sensitive attestations), relay is the enabling technology. Hybrid [#hybrid] In practice, many satellite missions use both. Bulk data (large cTRNG batches, telemetry, diagnostics) goes through ground station passes when bandwidth is plentiful and free. Time-sensitive data (attestation results, SpaceTEE outputs, alerts) routes through constellation relay for immediate delivery. Orbitport's architecture supports this hybrid model natively. The source selection logic and fallback chain don't care how the data reached the ground. They care about what data is available and how fresh it is. A note on security of the communication link [#a-note-on-security-of-the-communication-link] Satellite-to-ground communication travels through open space. Anyone with the right antenna and receiver tuned to the correct frequency could, in principle, intercept the signal. This is true for S-Band, constellation relay, and any other radio-based link. This is why cryptographic signing onboard the satellite matters so much. Even if someone intercepts the data in transit, they can't modify it without invalidating the signature. And since cTRNG values are meant to be public (or at least not secret), interception of the raw data doesn't compromise security. For SpaceTEE workloads where the computation output might be sensitive, the data would be encrypted onboard before transmission, using keys established through the remote attestation process. The communication link is treated as untrusted, and the cryptographic protocols handle the rest. This is the same philosophy as TLS on the internet: assume the network is hostile, and protect data at the application layer. The link itself is actually the easy part. Historically, when satellite systems get breached, it happens on the ground: phished operator credentials, malware on control systems, spoofed commands from a compromised station. The 2022 Viasat incident took out thousands of modems across Europe through a misconfigured VPN on the management network — the satellite was never touched. It's the reason SpaceComputer's [Space Fabric](./space-fabric) doesn't let any single ground station vouch for the system: attestations require agreement across many geographically distributed stations, so one bad station can't speak for the constellation. The blog covers this in [Ground Station Cybersecurity](https://blog.spacecomputer.io/ground-station-cybersecurity/). The bigger picture [#the-bigger-picture] Satellite communication is evolving fast. More ground stations, more constellation relay options, and eventually on-orbit networking between compute satellites will keep pushing latency down and availability up. The store-and-forward model that dominates today is a transitional state, not an endpoint. But even as connectivity improves, the fundamental character of orbital services remains: they're physically remote, they follow orbital mechanics, and they offer properties (like physical isolation) that no terrestrial infrastructure can replicate. Understanding the communication layer helps you appreciate both the constraints and the guarantees that make orbital services worth using in the first place. What this means for you (spoiler alert: not much) [#what-this-means-for-you-spoiler-alert-not-much] Everything above — the pass windows, the batching, the variable data freshness — is real, but it's not your problem. Orbitport abstracts all of it. You call an API or use the SDK, and you get randomness. Whether that value arrived from a satellite ten minutes ago or was derived from a cosmic seed is handled by the [source selection and fallback chain](/docs/concepts/orbitport-architecture#source-selection-and-the-fallback-chain) behind the scenes. The reason this page exists isn't to give you things to worry about, but background information on why the IPFS beacon publishes on a fixed cycle, why there's a derived randomness fallback, why source selection exists at all. The communication constraints explain the architecture. If you want the details on how Orbitport handles all of this, that's covered in the [Orbitport architecture page](./orbitport-architecture). # Space Computing: Why Orbit Matters (/docs/concepts/space-computing) Every security model has an assumption about physical access. Data centers use locked cages, biometric scanners, and security guards. Cloud providers publish SOC 2 reports and let auditors walk the floor. But at the end of the day, someone can always get to the hardware. An employee, a government with a warrant, an attacker with enough motivation. Orbit attempts to eliminate that assumption entirely. Physical isolation as a security property [#physical-isolation-as-a-security-property] A satellite in low Earth orbit is moving at roughly 7.5 km/s, hundreds of kilometers above the surface. In practical terms, no one is walking up to it. No one is attaching a probe. No one is swapping out a chip. Once the satellite is launched, the hardware is physically inaccessible for the duration of the mission. This isn't a policy control or an administrative safeguard, but just plain physics. And it provides a security guarantee that no terrestrial deployment can match: * **No insider threat to hardware.** There's no operator who can physically access the machine. The operations team communicates with the satellite via radio uplink. They can send commands and receive data. But they cannot touch the hardware. * **No physical side-channel attacks.** Power analysis, electromagnetic emanation probing, cold boot attacks, all these require physical proximity to the hardware. Proximity that doesn't exist when the target is in orbit. * **No supply chain tampering post-launch.** Once the satellite reaches orbit, the hardware configuration is fixed and no one is inserting a malicious component. The window for supply chain attacks closes permanently at launch. * **No jurisdictional seizure.** No government can compel physical access to a satellite in the way they can serve a warrant on a data center. The hardware is in orbit, and orbital space isn't subject to the same legal frameworks as terrestrial infrastructure. For most workloads, this level of physical isolation is overkill. You don't need it to serve a web app or run a batch job. But for a specific class of problems such as key generation, cryptographic attestation, randomness generation, confidential computation, the physical isolation guarantee is transformative. It changes the threat model from "we trust the operator's physical security controls" to "physical access is impossible." How this compares to terrestrial security [#how-this-compares-to-terrestrial-security] It's worth being concrete about the gap. A well-run data center might have: * Mantrap entry with biometric authentication * 24/7 security guards and camera surveillance * Background checks on all personnel * Tamper-evident seals on server racks * Visitor escort policies and audit logs These are good controls. They make physical attacks hard and expensive. But they don't make physical attacks impossible. A nation-state adversary, a compromised insider, or a sufficiently motivated attacker with time can defeat these controls. The history of intelligence operations is full of examples. A satellite in orbit doesn't need any of these controls because the physical access problem is solved by altitude. The security guarantee doesn't degrade over time, doesn't depend on policy compliance, and doesn't require ongoing vigilance. It just *is*. The thermal problem [#the-thermal-problem] But there's a catch, and it's a big one: space is terrible for computing at scale. On Earth, computers stay cool through convection: fans push air over heatsinks, and the air carries heat away. In orbit, *there is no air*, so convection is impossible. The only way to shed heat is through thermal radiation. For example, emitting infrared photons into space. This works, but it's dramatically less efficient than convection, making thermal management one of the harder engineering problems in space computing. What this means in practice is that you can't run heavy compute workloads in orbit without massive radiator panels. A rack of GPUs that works fine in a data center with industrial air conditioning would overheat and fail within minutes in a satellite. The surface area needed to radiate away that much heat would make the satellite impractically large and expensive to launch. This is a hard physical constraint, not an engineering problem that clever design will solve away. The Stefan-Boltzmann law is not negotiable. The power side of the equation [#the-power-side-of-the-equation] Thermal limits are closely tied to power limits. Everything in orbit runs on solar panels and batteries. A typical small satellite might generate 10-100 watts of electrical power. Compare that to a single modern GPU that draws 300-700 watts, and the mismatch is obvious. 100W *really* isn't much for the amounts of energy that we're used to work with on our everyday lives. Larger satellites can generate more power, but more power means more heat, which brings you back to the radiator problem. Not to mention that larger satellites cost more to build and launch, and the radiator hardware can pose a huge burden in the weight you're trying to put (and keep) in orbit. There's an economic constraint layered on top of the physical one. None of this is going to change in a fundamental way. Incremental improvements in solar efficiency and thermal management will expand the compute envelope over time, but the gap between orbital and terrestrial compute density will remain enormous for the foreseeable future. The radiation environment [#the-radiation-environment] Space is also a harsh radiation environment. Cosmic rays and trapped radiation in the Van Allen belts can cause bit flips in memory (single-event upsets) and gradual degradation of electronics (total ionizing dose effects). Satellite processors are either radiation-hardened (expensive, slower than commercial parts) or radiation-tolerant with error correction (cheaper, but still constrained). This is another reason we currently don't see high-performance compute in orbit. The processors that survive the radiation environment are generations behind what we'd find in a terrestrial data center. But again, for the workloads that matter here - cryptographic operations, randomness generation, small attestation tasks - these processors are more than capable. Interestingly, cosmic radiation is both a challenge (for electronics reliability) and an opportunity (as an entropy source for cTRNG). The same high-energy particles that cause bit flips in processors also drive SpaceComputer's randomness generation. The trick is keeping the two concerns separate: radiation-hardened processing for reliability, dedicated detectors for randomness. The launch cost factor [#the-launch-cost-factor] Everything in orbit got there on a rocket, and launch costs directly affect what's economically viable. The good news is that launch costs have dropped dramatically over the past decade, driven primarily by SpaceX's reusable rockets. A kilogram to LEO costs roughly $2,000-4,000 today, down from $50,000+ a decade ago. This matters for space computing because it makes small, specialized satellite payloads affordable. You don't need a billion-dollar flagship mission to get compute hardware into orbit. A payload the size of a shoebox, riding as a secondary payload on a larger launch, can carry the hardware needed for cTRNG or SpaceTEE at a cost that makes commercial sense. As launch costs continue to fall and rideshare opportunities proliferate, the economics of orbital compute will keep improving. More hardware in orbit means more capacity, more redundancy, and lower per-unit costs for orbital services. In turn, this poses more problems regarding security, encryption, and safety. Constrained but powerful [#constrained-but-powerful] So you can't commercially run a GPU cluster in orbit *yet*. What can you run? Quite a lot, actually, as long as the workload is lightweight. Modern satellite processors are capable machines: they just can't sustain the thermal output of heavy parallel computation. For workloads measured in milliwatts rather than kilowatts, the thermal constraint barely matters. And those workloads happen to be exactly the ones that benefit most from physical isolation: **Random number generation.** Detecting cosmic radiation events and converting them to random bytes is a low-power operation. The hardware (sensors, basic processing, cryptographic signing) fits comfortably within a satellite's thermal budget. And randomness is one of the workloads where the provenance guarantee (proof that the data was generated in a specific, physically isolated environment) matters enormously. **Cryptographic key generation and custody.** Generating a key pair inside a satellite means the private key was created in a physically inaccessible environment. If the satellite never exports the private key, you have a hardware security module that no one can physically attack. The key exists in one place in the universe, and that place is moving at 7.5 km/s above the atmosphere. **Attestation and signing.** A satellite can sign data to prove it was generated or processed onboard. The signature is verifiable by anyone, and the physical isolation of the signing key gives the attestation a stronger guarantee than any terrestrial HSM. If you trust the satellite's identity (established at launch and verified through the chain of custody), you trust the signature. **Lightweight confidential computation.** Small computation tasks that need provable isolation, like multi-party computation setup, secret sharing operations, or compliance-critical calculations, can run within a satellite's compute and thermal envelope. These aren't big jobs, but they're high-value jobs where the isolation property is worth the operational overhead of orbital deployment. The pattern is consistent: orbital compute is ideal for operations that are small in computational terms but large in trust requirements. The key insight is that for these workloads, the computational cost is negligible. What you're really "paying" for is the isolation guarantee. And orbit provides that guarantee more convincingly than any terrestrial alternative. What "lightweight" *actually* means [#what-lightweight-actually-means] To be concrete: a modern satellite processor can comfortably handle AES encryption, SHA-256 hashing, ECDSA signing, and BIP32 key derivation. These operations complete in milliseconds on even modest hardware. Generating a random 256-bit value from a cosmic ray detector and signing it takes trivial compute resources. Where you hit limits is sustained computation: iterating over large datasets, running inference on even small ML models, or processing high-bandwidth data streams. If your workload requires more than a few watts of sustained compute, it probably needs to stay on the ground. The sweet spot is operations that are computationally simple but extraordinarily sensitive. A single ECDSA key generation might take microseconds of CPU time, but the security implications of that key could be worth millions. That's the kind of asymmetry where orbital compute makes economic sense. Not a replacement for the cloud [#not-a-replacement-for-the-cloud] This should be obvious, but it's worth stating explicitly: space computing is not trying to replace AWS. It's not going to host your database, run your CI pipeline, or serve your frontend. If you hear someone pitch orbital compute as a general-purpose cloud replacement, they're either confused or selling something. Orbital compute is a complement to terrestrial infrastructure. It handles the small, high-assurance workloads where physical isolation is the critical property. Everything else stays on the ground, where bandwidth is cheap, latency is low, and you can throw as many GPUs at a problem as you want. The architecture pattern looks like this: your application runs on terrestrial infrastructure, and it calls out to orbital services for the specific operations that benefit from space-grade isolation. Orbitport is the bridge between these two worlds. It's a single API that lets your Earth-bound application consume services running in orbit without managing satellite passes, ground stations, or communication protocols. Think of it like using a hardware security module (HSM), except the HSM is in orbit and the isolation guarantee is backed by 500 km of vacuum instead of a tamper-resistant enclosure. When to use orbital services [#when-to-use-orbital-services] A practical decision framework: * **Do you need provable physical isolation?** If an auditor, regulator, or counterparty needs assurance that no one could have physically accessed the hardware, orbital compute provides a guarantee that's hard to argue with. * **Is the workload small and high-value?** Key generation, signing, randomness, small confidential computations. If the operation takes milliseconds to seconds and the trust requirement is high, it's a good candidate. * **Can you tolerate variable latency?** Orbital services aren't always instantly reachable. If your workload can wait seconds to minutes (or can use a buffered data source like the IPFS beacon), orbital fits. * **Is the alternative "trust the operator"?** If the terrestrial version of your workload requires trusting a cloud provider, a data center operator, or a hardware custodian, and you'd rather not, orbital compute removes that trust requirement. If you answered yes to most of these, you're looking at a good candidate for orbital services. Where this is heading [#where-this-is-heading] SpaceComputer operates individual satellite payloads that provide specific services (cTRNG being the first). The thermal and communication constraints mean each satellite does a focused job. The trajectory over the next several months is toward orbital compute networks: multiple satellites with different capabilities, communicating with each other and with the ground, forming a distributed system in orbit. As launch costs continue to drop and satellite-to-satellite communication matures, the range of viable orbital workloads will expand. Some milestones on that path: * **More satellites, more providers.** Orbitport's plugin architecture is designed for a multi-provider future. As more satellite operators offer compute and sensing services, they plug into the same API layer. Redundancy improves. Single points of failure disappear. * **SpaceTEE.** Trusted execution environments in orbit, combining TEE-grade software isolation with orbital physical isolation. This is on SpaceComputer's roadmap and builds on the same infrastructure that supports cTRNG today. SpaceTEE is covered in detail in its [own concept page](./spacetee). * **Orbital data processing.** As thermal management improves and on-orbit power generation scales up, the range of computation you can do in space will grow. Not GPU-scale, but meaningful processing that benefits from the isolation guarantee. * **Inter-satellite networking.** Satellites that communicate directly with each other, forming an orbital mesh. This reduces dependence on ground stations and enables new architectures where orbital nodes coordinate without terrestrial intermediaries. The important thing is that the fundamentals are already here. The security property (physical inaccessibility of the hardware) doesn't require future technology. It's a consequence of putting hardware in orbit, and it works today. cTRNG is the proof. Everything else is a matter of scaling up what's already proven. Common misconceptions [#common-misconceptions] A few things worth clearing up, since they come up frequently: **"Satellites can be hacked via radio uplink."** Yes, satellites receive commands via radio, and command link security is critical. But command authentication and encryption are well-understood problems. The satellite verifies cryptographic signatures on commands before executing them. A compromised uplink doesn't give you physical access to the hardware, it gives you the ability to send commands, which is a different attack surface than physical access. **"Space debris could destroy the satellite."** It could. This is an operational risk, not a security risk. Mission planning accounts for debris avoidance, and critical data is managed trustlessly by SpaceComputer designs. The security properties don't depend on any single satellite surviving indefinitely. **"You could retrieve a satellite."** In theory, a nation-state could launch a mission to rendezvous with and capture a satellite. In practice, this would be visible to the entire global space surveillance network, would take weeks to months to execute, and would be an act of extraordinary geopolitical significance. It's not a practical attack vector for any realistic threat model. By the time someone could execute a physical retrieval, you'd know about it and could revoke any keys or credentials associated with that satellite. Could be a premise for your own sci-fi novel, though! **"Space computing is just a gimmick."** This one's fair to question. The answer depends entirely on your workload: if you're looking for general-purpose compute, yes, space is absurd. No serious person would suggest running a personal website in orbit. But if you're looking for physical isolation as a security property for specific high-assurance operations, space is the only environment that provides it unconditionally. The question isn't whether space computing is useful in general. It's whether your specific use case benefits from a physical isolation guarantee that no terrestrial deployment can match. If you're generating cryptographic keys, producing verifiable randomness, or running confidential computations where the threat model includes physical access to hardware, then orbital compute isn't a gimmick. It's the only architecture that fully addresses the threat. Further reading [#further-reading] * [How Satellites Communicate](./satellite-communication) -- the connectivity model that shapes orbital services * [How Cosmic Randomness Works](./cosmic-randomness) -- the first orbital service built on the principles described here * [SpaceTEE: Trusted Execution from Orbit](./spacetee) -- the next step in orbital compute, combining TEEs with physical isolation * [Orbitport Architecture](./orbitport-architecture) -- the gateway that makes orbital services accessible to developers # Space Fabric: The Trust Layer in Orbit (/docs/concepts/space-fabric) The other concept pages talk about what orbit gives you: [physical isolation](./space-computing), [cosmic entropy](./cosmic-randomness), [trusted execution beyond anyone's reach](./spacetee). 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](./orbitport-architecture), 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 [#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-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](./post-quantum-cryptography) 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 [#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 [#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](./satellite-communication) 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 [#limitations] Space Fabric is a research-grade architecture entering deployment, and the [paper](https://arxiv.org/pdf/2603.23745) 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](./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](./post-quantum-cryptography) covers why that ordering makes sense. How it connects to what you use [#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](./cosmic-randomness)** 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](./orbital-kms)** roadmap ends with customer keys held in this environment: generated in orbit, non-exportable, destroyed on re-entry. * **[SpaceTEE](./spacetee)** is the customer-facing version of the confidential compute story: your workload in the Secure World, attested by the dual secure elements. Further reading [#further-reading] * [Space Fabric: What you need to know](https://blog.spacecomputer.io/space-fabric-breakdown/) - the blog breakdown this page distills * [4 Hardware Components Behind SpaceComputer's Satellite Architecture](https://blog.spacecomputer.io/satellite-hardware-components/) - deeper on the SE/HSM/TEE/TPM roles * [SpaceComputer Partners with Tropic Square](https://blog.spacecomputer.io/spacecomputer-partners-with-tropic-square/) - the open-silicon half of the dual-vendor story * [Space Fabric: A Satellite-Enhanced Trusted Execution Architecture](https://arxiv.org/pdf/2603.23745) - the full technical paper # SpaceTEE: Trusted Execution from Orbit (/docs/concepts/spacetee) 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? [#whats-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 [#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 [#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 [#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 [#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 [#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 [#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 [#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-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 [#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 [#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 [#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 [#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](./cosmic-randomness). 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 [#further-reading] * [Space Computing: Why Orbit Matters](./space-computing) -- the physical isolation argument in detail, including thermal constraints and the orbital compute tradeoff * [How Satellites Communicate](./satellite-communication) -- the communication model that underlies SpaceTEE data delivery * [Orbitport Architecture](./orbitport-architecture) -- the gateway through which SpaceTEE services will be exposed # Authentication (/docs/how-to/authentication) This guide covers how to obtain Orbitport API credentials, configure them in the SDK, and authenticate without the SDK if needed. Get your credentials [#get-your-credentials] 1. Go to [accounts.spacecomputer.io](https://accounts.spacecomputer.io/) and sign up for an account. 2. Once signed in, create an application. The dashboard gives you a **Client ID** and a **Client Secret**. 3. Copy both — you will use them as your OAuth2 client credentials. The Client Secret is shown only once, so store it somewhere safe (a password manager, a secret store, an `.env` file outside source control). Configure credentials in the SDK [#configure-credentials-in-the-sdk] Pass your credentials to the SDK constructor: ```typescript import { OrbitportSDK } from "@spacecomputer-io/orbitport-sdk-ts"; const sdk = new OrbitportSDK({ config: { clientId: "your-client-id", clientSecret: "your-client-secret", }, }); ``` The SDK runs the full OAuth2 client-credentials flow for you. On the first authenticated call (`sdk.ctrng.random()`, `sdk.kms.*`, etc.), the SDK will: 1. Request an access token from the auth server (`https://auth.spacecomputer.io/oauth/token`). 2. Cache the token and reuse it for subsequent requests. 3. Refresh the token automatically when it expires. If you need to inspect the cached token state: ```typescript const isValid = await sdk.auth.isTokenValid(); const tokenInfo = await sdk.auth.getTokenInfo(); await sdk.auth.clearToken(); // force a fresh token on the next call ``` Use environment variables [#use-environment-variables] Keep credentials out of source code by loading them from the environment: ```bash export ORBITPORT_CLIENT_ID= export ORBITPORT_CLIENT_SECRET= ``` ```typescript const sdk = new OrbitportSDK({ config: { clientId: process.env.ORBITPORT_CLIENT_ID, clientSecret: process.env.ORBITPORT_CLIENT_SECRET, }, }); ``` `ORBITPORT_CLIENT_ID` and `ORBITPORT_CLIENT_SECRET` are the names the SDK's own examples and tests use, so any other code you copy from the SDK repo will line up. Use the SDK without credentials [#use-the-sdk-without-credentials] If you do not pass `clientId` and `clientSecret`, the SDK skips authentication entirely and reads cTRNG values from the public IPFS beacon: ```typescript const sdk = new OrbitportSDK({ config: {} }); // No auth needed -- this reads from the IPFS beacon. const result = await sdk.ctrng.random(); ``` When credentials are provided but the API is unreachable, the SDK also falls back to IPFS automatically. :::note Credential-less mode applies to **cTRNG only**. KMS operations always require a Client ID and Secret -- there is no IPFS-equivalent fallback for key management. ::: Authenticate without the SDK [#authenticate-without-the-sdk] If you need to call the Orbitport API directly (for example, from a language without an SDK or from a shell script), do the OAuth2 client-credentials exchange yourself. Get an access token [#get-an-access-token] ```bash ACCESS_TOKEN=$(curl --silent --request POST \ --url "https://auth.spacecomputer.io/oauth/token" \ --header 'content-type: application/json' \ --data '{ "client_id":"'"${ORBITPORT_CLIENT_ID}"'", "client_secret":"'"${ORBITPORT_CLIENT_SECRET}"'", "audience":"https://op.spacecomputer.io/api", "grant_type":"client_credentials" }' \ | jq -r '.access_token') ``` Call an authenticated endpoint [#call-an-authenticated-endpoint] Pass the token as a Bearer token: ```bash curl --request GET \ --url https://op.spacecomputer.io/api/v1/services/trng \ --header "authorization: Bearer ${ACCESS_TOKEN}" ``` Tokens are valid for a finite window (typically 24 hours). Cache them and refresh when expired -- which is exactly what the SDK does for you. Next steps [#next-steps] * [Fetch cTRNG values](./ctrng) -- read cosmic randomness from the API or the public IPFS beacon. * [Use the KMS](./kms) -- create keys, encrypt, decrypt, and sign with managed keys. * [Orbitport Architecture](../concepts/orbitport-architecture) -- understand how authentication fits into the system. # Fetch cTRNG values (/docs/how-to/ctrng) This guide covers how to fetch cTRNG (cosmic True Random Number Generation) values: through the SDK with API + IPFS fallback, through the SDK in IPFS-only mode, and directly from the public IPFS beacon without any dependencies. Install the SDK [#install-the-sdk] ```bash npm i @spacecomputer-io/orbitport-sdk-ts ``` Fetch a value (API with IPFS fallback) [#fetch-a-value-api-with-ipfs-fallback] If you have credentials, the SDK will hit the Orbitport API first and fall back to the IPFS beacon automatically if the API is unreachable. ```typescript import { OrbitportSDK } from "@spacecomputer-io/orbitport-sdk-ts"; const sdk = new OrbitportSDK({ config: { clientId: process.env.ORBITPORT_CLIENT_ID, clientSecret: process.env.ORBITPORT_CLIENT_SECRET, }, }); const result = await sdk.ctrng.random(); console.log(result.data.data); // hex string of random bytes console.log(result.data.src); // "aptosorbital", "derived", or "ipfs" ``` If you don't have credentials yet, follow the [Authentication guide](./authentication) to create an account and get a Client ID and Secret. Response structure [#response-structure] Every `random()` call returns a `ServiceResult`: ```typescript interface ServiceResult { data: CTRNGResponse; metadata: { timestamp: number; request_id?: string; }; success: boolean; } interface CTRNGResponse { service: string; // "trng" (API) or "ipfs-beacon" src: string; // "aptosorbital", "derived", or "ipfs" data: string; // the random value as a hex string signature?: { value: string; pk: string; }; // present only for satellite-signed values timestamp?: string; provider?: string; } ``` The `src` field tells you where the value came from: `aptosorbital` is direct satellite data, `derived` means the gateway derived it from a cosmic master seed (see [source selection](../concepts/orbitport-architecture#source-selection-and-the-fallback-chain)), and `ipfs` means the SDK read it from the public beacon. The `signature` field appears only when the value comes directly from a satellite (`src: "aptosorbital"`) -- it is the satellite's cryptographic signature over the random data. Derived and IPFS-sourced values do not include a per-call signature. Use the SDK without credentials [#use-the-sdk-without-credentials] You can skip auth entirely and read straight from the public IPFS beacon: ```typescript const sdk = new OrbitportSDK({ config: {} }); const result = await sdk.ctrng.random(); console.log(result.data.data); ``` In this mode, the SDK never contacts the API. It reads the latest beacon block from both an IPFS gateway and an IPFS API node and compares them for integrity. Force IPFS as the source [#force-ipfs-as-the-source] Even with credentials configured, you can require an IPFS read via the `src` option: ```typescript const result = await sdk.ctrng.random({ src: "ipfs" }); ``` Select an array index [#select-an-array-index] The IPFS beacon publishes an array of cTRNG values per block (currently 3, may grow). Pick a specific value with `index`: ```typescript const first = await sdk.ctrng.random({ src: "ipfs", index: 0 }); const second = await sdk.ctrng.random({ src: "ipfs", index: 1 }); const third = await sdk.ctrng.random({ src: "ipfs", index: 2 }); ``` `index` is 0-based. Out-of-bounds indices wrap via modulo against the array length, so requests never fail on length. Traverse historical blocks [#traverse-historical-blocks] Each beacon block links to the previous one via a `previous` field, forming a chain. Use `block` to walk back through it: ```typescript // Fetch a value from block 10012, second item in the array. const historical = await sdk.ctrng.random({ src: "ipfs", block: 10012, index: 1, }); ``` `block` accepts: * `"INF"` (default) -- the latest block. * A number -- traverses the `previous` chain back to that sequence number. Requesting a block above the current head throws. Use a custom beacon path [#use-a-custom-beacon-path] If you operate your own IPFS beacon or want to point the SDK at a different one: ```typescript const result = await sdk.ctrng.random({ src: "ipfs", beaconPath: "/ipns/your-custom-beacon-cid", }); ``` Default IPFS configuration: | Setting | Default | | ----------- | ---------------------------------------------------------------- | | Gateway | `https://ipfs.io` | | API | `https://ipfs.io` | | Beacon path | `/ipns/k2k4r8lvomw737sajfnpav0dpeernugnryng50uheyk1k39lursmn09f` | Override any of these via `OrbitportConfig.ipfs`. Hit the IPFS beacon directly (no SDK) [#hit-the-ipfs-beacon-directly-no-sdk] The IPFS beacon is a public IPNS address that publishes a fresh block every five minutes. No credentials are needed -- you can read it with `curl`, `fetch`, or any HTTP client. Beacon URL [#beacon-url] ```text https://ipfs.io/ipns/k2k4r8lvomw737sajfnpav0dpeernugnryng50uheyk1k39lursmn09f ``` Fetch with curl [#fetch-with-curl] ```bash curl https://ipfs.io/ipns/k2k4r8lvomw737sajfnpav0dpeernugnryng50uheyk1k39lursmn09f ``` Fetch with fetch [#fetch-with-fetch] ```typescript async function fetchCTRNGFromIPFS() { const response = await fetch( "https://ipfs.io/ipns/k2k4r8lvomw737sajfnpav0dpeernugnryng50uheyk1k39lursmn09f" ); const data = await response.json(); console.log("Sequence:", data.data.sequence); console.log("Timestamp:", data.data.timestamp); console.log("cTRNG values:", data.data.ctrng); return data.data.ctrng[0]; } ``` Beacon block shape [#beacon-block-shape] ```json { "previous": "/ipfs/bafkreial7oeangta7hakknhzsjzja4k2sehnsykx2u7bm6wdz46ug42me4", "data": { "sequence": 87963, "timestamp": 1769179239, "ctrng": [ "88943046891c6c971f185c7cd69a350d850fca480facf549777efc4602ec94a6", "802a5afa3b09c360ec56cbe67cb615e038f307c905d199993e28ce38c21e9108", "dbbe94501ed32c55acb4ad4512da0c3871f497930c4d2d9061bbe7bd634458fc" ] } } ``` | Field | Description | | ---------------- | --------------------------------------------------------- | | `previous` | CID of the previous block. Follow it to traverse history. | | `data.sequence` | Sequence number of this block. | | `data.timestamp` | Unix timestamp when the block was created. | | `data.ctrng` | Array of cTRNG hex strings. Currently 3 values per block. | The beacon publishes a new block every **five minutes**, so values you fetch may be a few minutes old. For lower-latency access, use the authenticated API or the SDK. Next steps [#next-steps] * [Authentication](./authentication) -- get credentials for the API. * [Use the KMS](./kms) -- create keys, encrypt, decrypt, and sign with managed keys. * [Cosmic Randomness](../concepts/cosmic-randomness) -- learn where the randomness comes from. # How-to Guides (/docs/how-to) Each guide covers one task. Find what you need, follow the steps, move on. * **[Authentication](/docs/how-to/authentication)** -- Create an Orbitport account, get a Client ID and Secret, authenticate via the SDK or directly with OAuth2. * **[Fetch cTRNG values](/docs/how-to/ctrng)** -- Read cosmic random numbers from the API or the public IPFS beacon, with or without the SDK. * **[Use the KMS](/docs/how-to/kms)** -- Create keys, encrypt and decrypt data, sign messages (including Ethereum EIP-191), generate data keys, and rotate keys. Related [#related] Want to understand what's happening under the hood? The [Concepts](/docs/concepts) pages cover satellite communication, cosmic randomness, and the Orbitport architecture. To build your first app step by step, try the [Decision Picker tutorial](/docs/tutorials/decision-picker). For complete project examples, see the [Recipes](/docs/recipes). # Use the KMS (/docs/how-to/kms) This guide covers the Orbitport Key Management Service through the SDK: discovering capabilities, creating keys, encrypting and decrypting data, signing messages (including Ethereum EIP-191), generating data keys for envelope encryption, and rotating keys. For the reasoning behind a KMS that runs on attested (and eventually orbital) hardware, see [Key Management Beyond the Data Center](../concepts/orbital-kms). :::danger\[Experimental — do not use in production] The Orbitport KMS is **experimental**. Interfaces, key formats, and on-the-wire shapes can change without notice, and operational guarantees (durability, availability, key recoverability) are **not** in place yet. Do **not** use it to protect production data, sign production transactions, or hold keys you cannot afford to lose. Use it for prototypes, internal tooling, and exploration only -- and assume any keys you create today may be rotated, invalidated, or deleted before general availability. ::: What KMS provides [#what-kms-provides] The Orbitport KMS gives you managed cryptographic keys with two schemes: * **TRANSIT** -- general-purpose keys for symmetric encryption (`AES_256_GCM96`) and signing (`ECDSA_P256`/`P384`, `Ed25519`, `RSA_4096`). Supports encrypt, decrypt, sign, generate data key, and rotate. * **ETHEREUM** -- secp256k1 keys that expose an Ethereum address and support EIP-191 personal-sign-style messages. Supports sign only. The SDK talks JSON-RPC 2.0 to the gateway at `POST /api/v1/rpc`. Inputs are camelCase; outputs preserve the gateway's PascalCase wire shape (so `KeyId`, `KeyMetadata`, `CiphertextBlob`, etc. appear as-is on the response). Prerequisites [#prerequisites] KMS requires API credentials -- there is no public fallback for key operations. Follow the [Authentication guide](./authentication) to get a Client ID and Secret if you don't have them yet. ```typescript import { OrbitportSDK } from "@spacecomputer-io/orbitport-sdk-ts"; const sdk = new OrbitportSDK({ config: { clientId: process.env.ORBITPORT_CLIENT_ID, clientSecret: process.env.ORBITPORT_CLIENT_SECRET, }, }); ``` Discover capabilities [#discover-capabilities] Use `getCapabilities()` to inspect the schemes, key specs, and algorithms the gateway supports: ```typescript const caps = await sdk.kms.getCapabilities(); console.log(caps.data.Schemes.map((s) => s.Scheme).join(", ")); // e.g. "TRANSIT, ETHEREUM" ``` This is the authoritative source -- the reference tables at the bottom of this page reflect what the SDK supports today, but `getCapabilities()` always reports what your gateway actually offers. Create a key [#create-a-key] `createKey` provisions a new key. The most common shape: ```typescript const aes = await sdk.kms.createKey({ alias: "demo-aes", keySpec: "AES_256_GCM96", keyUsage: "ENCRYPT_DECRYPT", scheme: "TRANSIT", // default }); const aesKeyId = aes.data.KeyMetadata.KeyId; ``` Add a `description` and `tags` to label the key: ```typescript const labelled = await sdk.kms.createKey({ alias: "demo-aes-prod", keySpec: "AES_256_GCM96", keyUsage: "ENCRYPT_DECRYPT", description: "payments service envelope key", tags: [{ TagKey: "env", TagValue: "prod" }], }); ``` For an Ethereum-compatible signing key: ```typescript const eth = await sdk.kms.createKey({ alias: "demo-eth", keySpec: "ECC_SECG_P256K1", keyUsage: "SIGN_VERIFY", scheme: "ETHEREUM", }); console.log(eth.data.KeyMetadata.Address); // the Ethereum address ``` `alias` must be unique within your tenant. `description` and `tags` are optional in the SDK from version 0.2.2 onwards — when you omit them the SDK still sends the fields to the gateway as an empty string and an empty array. :::warning\[SDK 0.2.1] The version currently published to npm, **0.2.1**, does not send those defaults, and the gateway rejects a `createKey` without them (HTTP 400). Until 0.2.2 is on npm, pass `description` and `tags` explicitly on every `createKey` call. ::: Encrypt and decrypt [#encrypt-and-decrypt] Symmetric round-trip with a TRANSIT AES key: ```typescript const enc = await sdk.kms.encrypt({ keyId: aesKeyId, plaintext: "hello kms", }); const dec = await sdk.kms.decrypt({ keyId: aesKeyId, ciphertextBlob: enc.data.CiphertextBlob, }); console.log(dec.data.Plaintext); // "hello kms" ``` `encrypt` and `decrypt` accept an `encoding: "utf8" | "bytes"` option. The default is `"utf8"`, which auto-decodes to a string. Use `"bytes"` for binary fidelity: ```typescript const bytes = new Uint8Array([0xde, 0xad, 0xbe, 0xef]); const enc = await sdk.kms.encrypt({ keyId: aesKeyId, plaintext: bytes, encoding: "bytes", }); const dec = await sdk.kms.decrypt({ keyId: aesKeyId, ciphertextBlob: enc.data.CiphertextBlob, encoding: "bytes", }); // dec.data.Plaintext is a Uint8Array ``` Sign a message [#sign-a-message] Sign over a precomputed digest with an ECDSA P-256 key: ```typescript const ec = await sdk.kms.createKey({ alias: "demo-ecdsa", keySpec: "ECDSA_P256", keyUsage: "SIGN_VERIFY", }); // 32 bytes -- a SHA-256 digest you computed locally. const digest = new Uint8Array(32); // fill with your digest const sig = await sdk.kms.sign({ keyId: ec.data.KeyMetadata.KeyId, message: digest, signingAlgorithm: "ECDSA_SHA_256", messageType: "DIGEST", }); console.log(sig.data.Signature); // base64 signature ``` Sign an Ethereum personal-sign-style message with EIP-191: ```typescript const ethSig = await sdk.kms.sign({ keyId: eth.data.KeyMetadata.KeyId, message: "Hello, Ethereum", signingAlgorithm: "ETHEREUM_SECP256K1", messageType: "EIP191", }); ``` `messageType` controls how the gateway interprets `message`: | `messageType` | Meaning | | ------------- | ----------------------------------------------------------------------------- | | `RAW` | Sign the message bytes directly (the gateway hashes them). | | `DIGEST` | `message` is already a hash; sign it as-is. | | `EIP191` | Apply the Ethereum personal-sign prefix before hashing. ETHEREUM scheme only. | Generate a data key (envelope encryption) [#generate-a-data-key-envelope-encryption] `generateDataKey` returns a fresh symmetric key both as plaintext (so you can use it locally) and wrapped under your master key (so you can store the wrapped form alongside the data and only need the master key to decrypt later): ```typescript import { fromBase64ToUint8Array } from "@spacecomputer-io/orbitport-sdk-ts"; const dk = await sdk.kms.generateDataKey({ keyId: aesKeyId, dataKeySpec: "AES_256", }); const rawKeyBytes = fromBase64ToUint8Array(dk.data.Plaintext); const wrappedBlob = dk.data.CiphertextBlob; // store this with your data ``` `Plaintext` is always raw base64 binary key material -- there is no `encoding` flag for this method. The SDK exports `fromBase64ToUint8Array`, `fromBase64ToUtf8`, and `toBase64` helpers for manual decoding. You can request `numberOfBytes` instead of `dataKeySpec` for a custom-length key. Rotate a key [#rotate-a-key] Bump the key's primary version. New encryptions and signatures use the new version; previously produced ciphertexts and signatures remain decryptable / verifiable under their original version. ```typescript const before = aes.data.KeyMetadata.PrimaryVersion; const rotated = await sdk.kms.rotateKey({ keyId: aesKeyId }); console.log(`PrimaryVersion: ${before} -> ${rotated.data.KeyMetadata.PrimaryVersion}`); ``` Rotation is supported on TRANSIT keys only. ETHEREUM keys do not support rotation. Errors and retries [#errors-and-retries] KMS methods throw `OrbitportSDKError` with a typed `code`. Common KMS-specific codes: | Code | When | | ----------------------- | ------------------------------------------------------------------------ | | `KMS_KEY_NOT_FOUND` | The `keyId` does not exist (or has been deleted). | | `KMS_INVALID_KEY_STATE` | The key cannot be used for the requested operation in its current state. | | `KMS_ERROR` | A generic gateway-side KMS failure. | | `JSON_RPC_ERROR` | The gateway returned a JSON-RPC error envelope. | | `AUTH_FAILED` | Credentials missing or token rejected. | The raw JSON-RPC code is exposed at `error.details.jsonRpcCode` for advanced branching. KMS methods do **not** retry by default -- `createKey` and `sign` are not idempotent. Pass `RequestOptions.retries` per call when you want retry behavior: ```typescript await sdk.kms.encrypt( { keyId: aesKeyId, plaintext: "hi" }, { retries: 3 }, ); ``` Reference [#reference] Schemes and supported operations [#schemes-and-supported-operations] | Scheme | Encrypt / Decrypt | Sign | Generate Data Key | Rotate | | ---------- | ----------------- | ---- | ----------------- | ------ | | `TRANSIT` | yes | yes | yes | yes | | `ETHEREUM` | no | yes | no | no | Key specs [#key-specs] | Scheme | Key specs | | ---------- | ------------------------------------------------------------------ | | `TRANSIT` | `AES_256_GCM96`, `ECDSA_P256`, `ECDSA_P384`, `ED25519`, `RSA_4096` | | `ETHEREUM` | `ECC_SECG_P256K1` | Signing algorithms [#signing-algorithms] | Algorithm | Compatible key specs | | ---------------------- | -------------------- | | `ECDSA_SHA_256` | `ECDSA_P256` | | `ECDSA_SHA_384` | `ECDSA_P384` | | `ED25519` | `ED25519` | | `RSA_PKCS1V15_SHA_256` | `RSA_4096` | | `RSA_PSS_SHA_256` | `RSA_4096` | | `ETHEREUM_SECP256K1` | `ECC_SECG_P256K1` | Next steps [#next-steps] * [Authentication](./authentication) -- get credentials for the API. * [Fetch cTRNG values](./ctrng) -- read cosmic randomness alongside your KMS operations. * [Orbitport Architecture](../concepts/orbitport-architecture) -- understand how KMS fits into the wider system. # Cosmic Cipher (/docs/recipes/cosmic-cipher) A Next.js app that generates secure passwords using cosmic randomness from Orbitport's cTRNG service. The app fetches a true random seed from satellites, then generates passwords client-side with customizable length and character requirements. Includes automatic fallback to local crypto when the cosmic service is unavailable. Video Walkthrough [#video-walkthrough]