What Is a Signing Key? Key Generation in Low Earth Orbit

What Is a Signing Key? Key Generation in Low Earth Orbit

What Is a Signing Key?

Before you trust any secure system, you need to trust one secret: its signing key. If an attacker copies that key, they can impersonate the system it belongs to, and without other mechanisms in place, nobody downstream can tell.

For any company evaluating where to run sensitive workloads, or which infrastructure to partner with, this is a question worth asking on a discovery call: where are the signing keys generated, and who else had access before the compute is given to us?

What a Signing Key Is, and What It Does

A signing key is the private half of a cryptographic key pair. The private key (aka 'secret key') stays secret and produces a digital signature. The matching public key, which can be shared freely, lets anyone verify that signature. A signing key can produce a signature the public key confirms, but the public key cannot reproduce the private key or forge a signature. The whole system holds on a single condition: only the legitimate owner controls the signing key.

Diagram explaining on a high level how a signing key works for symmetric signing key encryption.
High-level how a signing key works with data

That one capability offers three guarantees:

  1. Authentication: a valid signature proving who produced the data
  2. Integrity: proving the data was not altered
  3. Non-repudiation: the signer cannot later deny having signed it

These guarantees work across most of the systems a business already relies on. The HTTPS connection in your browser, the software updates your devices accept, the certificate authorities behind enterprise identity, and the remote attestation that lets one party verify software running on hardware it cannot physically inspect all depend on signing keys staying secret.

A signing key is also only as trustworthy as the place it is kept, and that place is a ladder. A key sitting in a software file or in application memory is the weakest rung, readable by anyone who compromises the operating system. A Trusted Platform Module (TPM) raises the cost of extraction. A Hardware Security Module (HSM) is built so private keys never leave it in plaintext. A Secure Element (SE) delivers that same contract in a chip small enough for a satellite, generating keys on-chip and signing without ever exposing them. Paired with a Trusted Execution Environment (TEE), the key can be used by a workload that never sees its private half. We break those four components down in our post on the hardware behind SpaceComputer satellites.

Where a Key Is Generated Is a Business Decision

Most discussions stop at storage, but the more important question is where the key is generated in the first place. Nearly every commercial secure platform generates or provisions its signing keys during manufacturing. That creates a window, before the hardware is ever deployed, when the key exists somewhere a person could copy it. The verifier has to trust that the manufacturer generated the key correctly and erased every copy afterward. And often, no one outside the manufacturer can audit that promise was kept.

For a company evaluating an infrastructure partner, this matters more than it first appears. When you run workloads on someone else's platform, you inherit their security decisions, and by extension, their key custody decisions. If their signing keys were generated in a factory, and the vendor holds (or once held) a copy, then the security of your data rests on a supply chain you can't audit. That assumption exists in most of the secure compute available today.

What Changes When Key Generation Happens in Orbit

This is the assumption Space Fabric, our satellite-native trusted computing architecture, was built to remove. Rather than generating signing keys before deployment, we defer key generation to once we reach orbit.

On first boot after launch, the secure elements on board generate every signing key themselves, inside the chip, using on-chip entropy. The private keys are flagged non-exportable under hardware policy, so the workload, the operating system, and the satellite operator cannot read them. No SpaceComputer signing key has ever existed on Earth at any point in its lifecycle.

That single change rewrites the trust assumption. A verifier no longer has to trust that a vendor erased a secret it once held. The only thing registered before launch is public, non-secret information: device serial numbers, a hardware certificate, processor identifiers, and configuration hashes. These tie attestation to one specific physical chip without granting any ability to sign. An identically built clone sitting on the ground would generate different keys, and a verifier would reject it.

Two design choices reinforce this.

The first is dual-vendor signing. The trust anchor is split across two secure elements from different manufacturers, the NXP SE050 and the Tropic Square TROPIC01, and both must co-sign every piece of attestation evidence for it to count. Forging a signature would require compromising two independent silicon supply chains at the same time in space. One element is certified and closed-source, the other is fully open with published designs anyone can audit.

The second is physical inaccessibility. Once the keys are generated in orbit, the hardware holding them is beyond reach, and the entire category of attacks that depend on probing a chip or tapping a bus, which terrestrial systems spend heavily to defend against, stops applying.

A comparison of On-Earth versus on-orbit key generation, compared in a table. Background is of the Earth and satellites.

On-orbit key generation: every signing key is generated inside the secure elements after launch, and no private key ever exists on Earth.

Building With SpaceComputer's On-Orbit Key Genesis

For a space-tech company weighing whether to build on or partner with orbital infrastructure, this reframes key management for confidential compute. You can verify the system directly instead of taking a vendor's word that your keys are safe, which turns compliance and security into something you confirm with cryptographic evidence rather than something asserted in a contract. For partners deploying their own workloads, it means your code and data run on infrastructure where the operator cannot reach the keys protecting them, and where you can prove that to your own customers. We go deeper on the custody model in our post on key management beyond the cloud, and on how these keys anchor attestation in our overview of Space Fabric.

A signing key is small, and yet so much of the security stack relies on its integrity. Where it is generated dictates how much of your security you are taking on contractual faith with your manufacturing supply chain. We generate ours in orbit, where no one can reach it and you don't have to take a vendor's word. Trust becomes something verifiable for anyone utilizing our hardware, hence why we often say SpaceComputer is building the 'orbital root of trust'.


Visit our website for more information on our key management service (KMS).
Follow us on X (Twitter) and LinkedIn.
Read more about our trust architecture in our research paper Space Fabric here.

Ready for your next read? Explore the hardware supporting our layered security approach:

4 Hardware Components Behind SpaceComputer’s Satellite Architecture
How SpaceComputer engineers hardware root of trust for satellites, using Secure Elements, TEEs, HSMs, and TPMs in our Space Fabric architecture.