Entry 679 — Reading: onboard protections, defense in depth, anomaly detection, and secure boot

1. The robot that must not harm

Isaac Asimov’s I, Robot returns as the recalled work because its positronic brains are governed by internal rules that constrain behavior regardless of external instructions. A spacecraft’s flight software needs analogous internal guards: even if a command passes authentication, the platform should still refuse actions that violate safety rules, and it should notice when its own behavior departs from expected patterns.

This entry reads about onboard protections: defense in depth, anomaly detection, and secure boot.

2. Defense in depth on a spacecraft

The Aerospace Corporation argues that spacecraft have historically been designed as if the RF link were the only defensive boundary. The recommended correction is defense in depth, with protections at multiple layers:

• Governance and supply chain: vendor accountability, firmware provenance, and component acceptance testing.
• Ground segment: segmented networks, access control, and monitoring.
• Communications link: encryption, authentication, replay resistance.
• Onboard computing: secure boot, memory protection, least privilege, bus segregation.
• Mission data and flight software: code signing, logging, and fail-safe modes.

The key insight is that no single layer is sufficient. If the link is breached, onboard controls must still contain the damage.

3. Secure boot and software integrity

Secure boot ensures that only cryptographically signed firmware runs on the spacecraft. The Aerospace report recommends:

• a hardware root of trust implemented in radiation-tolerant non-programmable equipment;
• verification of the device’s own code and configuration before execution;
• cryptographic signatures or code signing for all software and firmware updates;
• rejection of unsigned or improperly signed images.

For small satellites, a full hardware root of trust may be too heavy, but the intent can be approximated with verified bootloaders, signed images, and rollback protection.

4. Bus segregation and least privilege

Critical and non-critical subsystems should communicate over separated buses, or their shared buses should be explicitly protected at each interface. The principle of least privilege means each subsystem receives only the permissions it needs. A payload computer should not be able to command propulsion thrusters, and a communications radio should not be able to modify flight software.

5. Anomaly detection and intrusion detection

Onboard anomaly detection is emerging as a practical near-term protection for resource-constrained spacecraft. Southwest Research Institute’s project aimed to design an autonomous onboard system that distinguishes malicious command messages from legitimate ones. Kratos describes on-orbit intrusion detection systems that monitor data, commands, and behavior in real time.

Shelby’s CubeSat assessment rates AI-driven anomaly detection as the most viable near-term emerging technology for CubeSats, given lightweight models that can run on ARM Cortex-M class processors within milliwatt budgets. Constraints include:

• limited training data representative of orbital conditions;
• risk of false positives that trigger unnecessary safe modes;
• adversarial inputs crafted to evade detection;
• need for fallback rules or invariants for safety-critical checks.

6. Logging and forensic accountability

Continuous verbose logging is unsustainable on a 1–2 W CubeSat, but selective logging of critical state transitions is feasible. Recommended events include:

• safe-mode entry and exit;
• command acceptance and rejection;
• subsystem resets;
• authentication failures;
• software update attempts;
• anomalous sensor or actuator behavior.

Logs should be stored in a cyclic buffer and downlinked opportunistically, preserving accountability without exhausting power or storage.

7. What this changes

• Onboard protections are the second line of defense after link authentication.
• Secure boot, bus segregation, least privilege, and selective logging are feasible even on small satellites.
• Anomaly detection is promising but requires realistic training data and clear fallback behavior.
• The desktop should not rely on a single security boundary; it should layer protections from supply chain through to fail-safe modes.
• The next entry will close the cybersecurity reading arc.