Zero-Trust Security in Space: Hardware Root of Trust

When your compute infrastructure orbits 408 km above Earth, physical security takes on a new meaning. Here's how we built a zero-trust security model for the most unreachable data center ever deployed.

Why Security is Critical in Space

Orbital infrastructure faces a unique paradox: it's physically the most secure computing platform ever built (no one can physically access it), yet it communicates exclusively over radio waves—one of the most interceptable mediums in existence.

Every command sent to SolarNode traverses the electromagnetic spectrum. Every byte of data returned passes through atmosphere, weather, and potentially hostile territory. Our security architecture must assume that every transmission is observed.

“In space, your attack surface is literally the entire sky.”

Hardware Security Modules (HSM)

At the core of SolarNode's security architecture sits a radiation-hardened Hardware Security Module. Unlike software-based encryption, which can be compromised through memory exploits or side-channel attacks, our HSM provides:

• Hardware root of trust — cryptographic keys never leave the tamper-resistant chip
• True random number generation — using quantum noise from cosmic radiation
• Secure boot chain — every component verified before execution
• Physical tamper detection — automatic key zeroization if the enclosure is breached

The HSM generates and stores all cryptographic material on-chip. Private keys are created in orbit and never transmitted to ground. Even SolarNode engineers cannot extract the keys—they can only instruct the HSM to perform operations with them.

End-to-End Encryption Architecture

Three Layers of Encryption

Every data path in SolarNode is encrypted at three independent layers:

Layer 1: Transport (TLS 1.3)
├── Ground station ↔ Satellite uplink/downlink
├── Certificate pinning with on-board CA
└── Perfect forward secrecy (X25519)

Layer 2: Application (AES-256-GCM)
├── Payload encryption before transmission
├── Per-workload encryption keys
└── Key derivation from HSM master key

Layer 3: Storage (XTS-AES-256)
├── Full-disk encryption on all NVMe storage
├── Per-tenant isolation with separate keys
└── Secure delete with crypto-erase

Compromising any single layer still leaves data protected by the other two. An attacker intercepting the radio link sees only TLS-encrypted traffic. Even if they broke TLS, the application payload is independently encrypted.

Post-Quantum Readiness

We implement hybrid key exchange combining X25519 (classical) with ML-KEM-768 (post-quantum). This ensures that even if quantum computers eventually break elliptic curve cryptography, data intercepted today remains secure.

Autonomous Key Rotation

SolarNode operates autonomously for up to 90 minutes per orbit. Key rotation can't depend on ground station connectivity.

Key Rotation Schedule:
├── Session keys:    Every ground pass (~15 min)
├── Transport keys:  Every 6 hours
├── Workload keys:   Every 24 hours
├── Master keys:     Every 30 days (requires ground authorization)
└── HSM root key:    Never rotated (hardware bound)

Autonomous Rotation Process:
1. HSM generates new key pair
2. New public key signed by current key
3. Key commitment broadcast on next ground pass
4. Old key retained for 2 rotation periods
5. Crypto-erase of expired keys

The HSM handles all key generation autonomously. Ground control can trigger emergency rotation but cannot inject keys—all cryptographic material originates on-orbit.

Threat Model Analysis

Threats We Defend Against

What We Don't Worry About

• Physical theft — the satellite orbits at 7.66 km/s
• USB attacks — no physical ports accessible after launch
• Social engineering — HSM won't release keys regardless of commands
• Power analysis — solar power fluctuations mask electrical signatures

Case Study: Preventing Satellite Hijacking

In 2022, the Viasat KA-SAT network was disrupted by a cyberattack attributed to state actors. The attackers exploited a misconfigured VPN appliance in the ground segment to push malicious firmware updates to satellite modems.

SolarNode's architecture prevents this class of attack entirely:

1. No remote firmware updates without HSM attestation — firmware packages must be signed by a quorum of 3/5 offline signing keys
2. Ground segment is untrusted — compromising ground stations gives access to encrypted traffic only
3. Mutual authentication — the satellite authenticates the ground station, not just the reverse
4. Command rate limiting — the HSM enforces maximum command rates, preventing command flooding

Zero-trust in space isn't just a buzzword. When your infrastructure orbits the Earth every 90 minutes, trust must be earned cryptographically, every single time.

References:

• NIST SP 800-207: Zero Trust Architecture
• CCSDS 350.0-G-3: Security Threats Against Space Missions
• NIST FIPS 140-3: Security Requirements for Cryptographic Modules
• Viasat KA-SAT Incident Analysis (SentinelLabs, 2022)