Key Management Beyond the Data Center

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. 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

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

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

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 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 argues for compute, the only fix is to remove the window entirely rather than promise harder.

What orbit changes

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 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

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 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. 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 spells out the caveats. :::

Further reading

• Use the KMS -- create keys, encrypt, sign, and rotate through the SDK
• SpaceComputer Secure Key Management Services Beyond the Cloud -- the roadmap post this page draws on
• What Is a Signing Key? Key Generation in Low Earth Orbit -- the custody-ladder argument in full
• Space Fabric -- the hardware that makes "keys born in space" literal