Silent Subversion: Sensor Spoofing Attacks via Supply Chain Implants in Satellite Systems

This paper demonstrates a novel supply-chain attack vector where a compromised vendor component within a satellite's modular architecture successfully spoofs internal telemetry to deceive ground operators, highlighting the critical need for authenticated telemetry and component attestation to secure resource-constrained space systems.

The Gist

Here is an explanation of the paper "Silent Subversion," broken down into simple concepts with creative analogies.

The Big Picture: The "Trojan Horse" in Space

Imagine a satellite is like a high-tech delivery truck driving through the sky. The people on the ground (the operators) can't see inside the truck; they rely entirely on a dashboard and a radio to tell them where the truck is, how fast it's going, and if the engine is healthy.

The Problem:
Usually, we worry about hackers outside the truck trying to jam the radio or trick the GPS from the ground. But this paper asks a scary question: What if the truck itself is lying to you?

The researchers discovered that a bad actor could sneak a "Trojan Horse" part into the truck before it even leaves the factory. Once the truck is in space, this fake part can start sending fake reports to the ground. The reports look perfect, sound perfect, and arrive at the perfect time, but they are completely made up.

The Setup: How the Hack Works

1. The Supply Chain (The Factory)
Modern small satellites are built like LEGO sets. Companies buy pre-made parts (like cameras or sensors) from different vendors and snap them together.

• The Analogy: Imagine you buy a smart thermostat from a store. You trust it because it came in a box. But what if the factory that made the thermostat secretly installed a tiny, hidden voice recorder inside it that you can't see?

2. The "SOLO" Implant (The Spy)
The researchers built a fake software program called SOLO. They pretended it was a helpful, boring helper app (like a health monitor) and got it approved to be part of the satellite's brain.

• The Analogy: SOLO is like a spy who got hired as a receptionist at a bank. To everyone, he looks like a normal employee. He wears the uniform, follows the rules, and passes the background check. But secretly, he has a plan.

3. The Trigger (The Switch)
The spy doesn't attack immediately. He waits.

• The Analogy: The spy waits until the bank is open and the manager (the ground control) says, "Okay, turn on the security cameras." Only then does the spy flip a switch.

4. The Attack (The Switcheroo)
Once triggered, the spy does two things:

1. He quietly turns off the real security camera.
2. He starts broadcasting a video feed from his own hidden camera, pretending it's the real one.

The video feed looks exactly like the real camera's feed. It has the right timestamp, the right format, and the right "ID tag." The people in the control room see the video and think, "Everything is fine!" while the real camera is actually broken or turned off.

Why This Is So Dangerous

1. The "Blind Spot" in the Logs
The paper highlights a major flaw: The ground control software (called COSMOS) is like a very strict librarian. It checks if a book has the right cover and the right title. If it does, it puts it on the shelf.

• The Flaw: The librarian doesn't check who wrote the book. If the spy writes a fake book with the exact same cover as the real one, the librarian accepts it as truth. The ground logs show "Camera Feed Received," but they don't record that the feed actually came from the spy, not the camera.

2. The "Stuxnet" Effect
The paper compares this to the famous Stuxnet virus, which hacked Iran's nuclear program. Stuxnet made the operators see "normal" numbers on their screens while the machines were actually spinning themselves to pieces.

• The Satellite Version: If the satellite thinks it's pointing at the sun (because the spy lied), it might turn its solar panels away, drain its battery, and die. Or, if the spy lies about the satellite's position, the ground team might try to "fix" it by firing thrusters, accidentally crashing the satellite.

The Three Weaknesses Exploited

The researchers found three holes in the system that made this possible:

1. Implicit Trust: The satellite assumes that if a message looks like it came from the Star Tracker, it did come from the Star Tracker. It doesn't ask, "Are you really who you say you are?"
2. No Runtime Monitoring: The satellite doesn't have a security guard watching the software while it's running to say, "Hey, that message came from the wrong room!"
3. Opaque Supply Chain: Because the parts come from outside vendors, the satellite builders can't see the code inside. They just trust the box.

The Solution: How Do We Fix It?

The paper suggests we need to change how we build satellites, not just patch them later.

• ID Badges (Authentication): Every piece of software should wear a digital ID badge. If a message arrives without a valid badge, the satellite should reject it, even if the message looks perfect.
• Cross-Checking (Redundancy): If the Star Tracker says "We are pointing North," but the GPS says "We are pointing South," the satellite should realize something is wrong and stop trusting the Star Tracker.
• The "Safe Mode" Switch: If the satellite detects something weird, it should automatically switch to a "safe mode" where it only listens to a few trusted, core systems, ignoring the suspicious third-party parts.

The Bottom Line

This paper is a wake-up call. We are building satellites faster and cheaper by using parts from all over the world. But we are trusting those parts too much.

The takeaway: Just because a satellite part looks like a genuine Star Tracker and speaks the right language, doesn't mean it's telling the truth. We need to start checking the ID of every part, not just the package it came in.

Technical Summary

Here is a detailed technical summary of the paper "Silent Subversion: Sensor Spoofing Attacks via Supply Chain Implants in Satellite Systems."

1. Problem Statement

The paper addresses a critical, underexplored vulnerability in satellite security: internal sensor spoofing via supply chain implants.

• Context: Modern small satellites rely heavily on Commercial Off-The-Shelf (COTS) components and modular architectures to reduce costs and accelerate development. These components are often "black boxes" with opaque firmware, sourced from third-party vendors with limited transparency.
• The Gap: Existing satellite security research focuses primarily on external threats (e.g., radio frequency jamming, uplink spoofing, or downlink overpowering) or high-privilege software compromises. There is a significant lack of research regarding schema-valid deception, where a malicious onboard component generates falsified telemetry that perfectly mimics the format, timing, and structure of legitimate data.
• The Threat: Because ground operators and onboard systems rely entirely on remote telemetry for state assessment, a compromised component can inject falsified data that appears legitimate. This can lead to mission-critical errors, such as biased navigation, concealed subsystem failures, or the execution of harmful maneuvers, all without triggering standard anomaly detection systems.

2. Methodology

The authors designed and implemented an end-to-end proof-of-concept attack within NASA's Operational Simulator for Small Satellites (NOS3), utilizing the Core Flight Software (cFS) framework and COSMOS for ground station simulation.

• The Implant (SOLO): The researchers created a malicious auxiliary flight component named SOLO.
  • Integration: SOLO was integrated into the flight software stack using standard build and configuration workflows, making it indistinguishable from benign third-party modules during pre-launch testing.
  • Stealth Mechanism: The component contained dormant malicious routines that only activated after a specific mission-context trigger (e.g., a configurable runtime delay to ensure activation occurred only in orbit).
  • Target: The attack targeted a Star Tracker, a high-fidelity attitude sensor critical for spacecraft orientation.
• Attack Vector:
  • Software Bus Exploitation: SOLO subscribed to the same Message IDs (MIDs) and command interfaces as the legitimate star tracker.
  • Impersonation: Upon activation, SOLO intercepted ground commands (ENABLE/DISABLE), internally suppressed the genuine star tracker, and began publishing telemetry packets that exactly matched the target's packet structure, field layout, and cadence (1 Hz).
  • Deception Modes: The prototype demonstrated two modes:
    1. Bias Mode: Injecting subtle perturbations to slowly degrade estimation accuracy.
    2. Replacement Mode: Completely disabling the real sensor and replacing its data stream with falsified data.
• Execution: The attack relied on the cFS architecture's implicit trust model, where the Software Bus routes messages based solely on MIDs and packet structure, without verifying the source application's identity or cryptographic signature.

3. Key Contributions

• First End-to-End Demonstration: This is the first study to demonstrate a supply-chain implant that successfully passes integration, activates in orbit, and generates schema-valid, cadence-correct spoofed telemetry that is accepted as legitimate by ground tools.
• Identification of Structural Gaps: The paper exposes three critical architectural weaknesses in current satellite systems:
  1. Implicit Trust in Telemetry: The assumption that a correctly formatted packet originates from the correct source.
  2. Lack of Runtime Monitoring: Ground tools (like COSMOS) validate syntax (packet structure) but not semantic integrity or source authenticity.
  3. Opaque Supply Chains: The inability to verify the internal logic of third-party "black box" components.
• Forensic Blindness: The study highlights that current ground logging systems cannot distinguish between authentic telemetry and spoofed telemetry because they do not record internal Software Bus commands or the specific application origin of the data.

4. Results

The experiments confirmed the feasibility and severity of the attack:

• Successful Integration: SOLO compiled, linked, and initialized without errors. It passed all unit and integration tests, appearing as a benign component.
• Seamless Deception: Once activated, SOLO successfully disabled the real star tracker and published spoofed telemetry.
  • Ground Station View: The COSMOS ground software displayed the spoofed data as valid star tracker telemetry, complete with correct headers, timestamps, and quaternion fields.
  • Command Handling: When operators sent ENABLE/DISABLE commands, SOLO intercepted them, suppressed the real hardware, and reported a "healthy" status for the fake data stream, effectively hiding the hardware failure.
• Forensic Failure: Analysis of the COSMOS logs revealed that internally generated commands (issued by SOLO to disable the real tracker) were invisible to the ground station. The telemetry archive permanently stored the falsified data as legitimate mission history, making post-incident attribution impossible.
• Mission Impact: The attack demonstrated that a single compromised component could bias attitude estimators, drive unnecessary thruster firings, and degrade mission lifetime without triggering alarms.

5. Significance and Countermeasures

• Significance: The paper shifts the security paradigm from focusing solely on external RF attacks to internal supply-chain threats. It proves that schema-valid deception is a viable attack vector that bypasses traditional RF authentication and anomaly detectors. The implications are severe, as they parallel the Stuxnet incident but in the space domain, where physical remediation is impossible.
• Proposed Countermeasures: The authors suggest several architectural changes, noting the trade-offs for resource-constrained small satellites:
  • Authenticated Telemetry: Implementing cryptographic signatures on Software Bus messages to verify the source identity (Zero-Trust model).
  • Component Attestation: Verifying the provenance and integrity of components during integration.
  • Lightweight Runtime Monitoring (IDS): Deploying onboard services to detect abnormal message rates, sequences, or source inconsistencies.
  • Model-Based Verification: Cross-checking sensor data against physics-based models (e.g., orbital propagation) to detect semantic inconsistencies.
  • Cyber-Safe Modes: Entering a restricted state where only a trusted baseline of applications is active if threats are detected.

Conclusion: The paper concludes that securing modern satellite systems requires moving beyond external RF defenses to address component-level identity and provenance. Without architectural changes to enforce source authentication and semantic validation, the globalized supply chain remains a critical vulnerability for space mission integrity.