1. The key that opens the right door

Neal Stephenson’s Snow Crash returns as the recalled work because its world runs on cryptographic credentials: the right key grants access, the wrong key does not, and the distinction is enforced without sentiment. A spacecraft command link needs the same discipline. Every maneuver, mode change, and configuration update must carry proof that it came from an authorized source and was not replayed or altered in transit.

This entry reads about secure command authentication and link protection.

2. Authentication versus encryption

The literature distinguishes two protections:

  • Encryption protects confidentiality: an eavesdropper cannot read telemetry or command content.
  • Authentication protects integrity and origin: the spacecraft can verify who sent a command and whether it was modified.

A command link can be encrypted but still vulnerable to replay if it lacks authentication. Conversely, a command can be authenticated without hiding its content. For spacecraft, both are usually needed, but authentication is often the higher priority because an injected command does not need to be read to be damaging.

3. Cryptographic choices under power constraints

Shelby’s CubeSat risk assessment compares ECC and RSA implementations for a 2 W CubeSat with 0.3 W available for security. The numbers are instructive:

  • ECC with Curve25519 key exchange and ChaCha20-Poly1305 AEAD: about 0.18 W operational, good security gain.
  • RSA-2048 with AES-256-GCM: about 0.52 W operational, higher absolute security but consuming over a quarter of the total power budget.

The Security-per-Watt heuristic favors ECC by roughly 2.7×. The practical lesson is that algorithm choice matters for small satellites, and terrestrial defaults may be too expensive.

4. Replay resistance

The Aerospace Corporation report highlights replay-resistant authentication as one of the controls most often scoped out of spacecraft baselines incorrectly. Replay attacks are a top threat vector for spacecraft because commands are transmitted over radio and can be recorded and retransmitted. Countermeasures include:

  • sequence counters that reject out-of-order or duplicate commands;
  • timestamps or nonces bound to command validity windows;
  • cryptographic message authentication codes or signatures that cover the counter or timestamp.

5. Key management in orbit

Key management is where elegant cryptography meets operational friction. The literature notes several challenges:

  • Key rotation: credentials should be updateable, but updates require a secure channel and a fallback if rotation fails.
  • Key storage: keys need protection against extraction if the onboard computer is compromised, favoring hardware security modules or trusted platform modules where budget allows.
  • Ground-station compromise: if a ground station is breached, its keys must be revocable without losing the spacecraft.
  • Multiple operators: constellations and shared ground networks need role-based or mission-based key separation.

Beyond cryptography, the link layer can be hardened by:

  • using spread-spectrum or frequency-agile waveforms that are harder to jam or spoof;
  • limiting command acceptance to pre-approved windows and attitudes;
  • requiring two-factor or multi-party authorization for safety-critical commands such as propulsion burns or deorbit;
  • logging every accepted and rejected command for later forensic analysis.

7. What this changes

  • Command authentication is at least as important as encryption for spacecraft.
  • Elliptic-curve cryptography is generally more power-efficient than RSA for small-satellite-class platforms.
  • Replay resistance, key management, and ground-station revocation are practical problems that shape the command architecture.
  • The desktop should assume its command link is observable and design for authentication, replay resistance, and bounded authorization windows.
  • The next entry will read about onboard protections: defense-in-depth, anomaly detection, and secure boot.