Secure Autonomy for the Robot and Drone Fleet

Overview

This is a build guide for hardening a small fleet of ArduPilot drones and ROS 2 ground robots against takeover, spoofed commands, malicious firmware, and untracked change. It starts from a STRIDE threat model across every trust boundary, then applies six controls: MAVLink 2 packet signing, WireGuard link encryption, Ed25519 signed firmware, SROS2 least-privilege enclaves, a pymavlink intrusion detector feeding a SIEM, and signed A/B over-the-air updates. Every control is attacked in the lab before it is trusted.

Status: Planned. This page is a published build guide written against the Defence Drone Initiative's digital-enablers stream, which covers communications, cyber, and command and control for autonomous platforms (verify). Nothing on this page is built, attacked, or measured yet. Each control below is defined together with the test case that will prove or break it, and results will appear here only after the lab work runs.

Why this build exists: a security operations background is the differentiator. Most hobby fleets ship with open telemetry links, unsigned firmware, a flat ROS 2 network where any node can publish to any topic, and no logging at all. The professional version of this work is to attack your own fleet in the lab, fix what breaks, and monitor what remains. That cycle, threat model, control, attack, evidence, is the deliverable, not any single tool.

Scope honesty up front: this guide covers a bench fleet of one to three vehicles on a private, isolated network. It does not claim to secure an operational military fleet, and it stays strictly defensive: nothing here jams, spoofs, or carries munitions, RF work is receive-only, and GNSS work is detection only. Only gear owned by the project gets tested, with permission.

Concept Illustrations

Target Spec

There is no single government spec sheet for this build the way the Arctic UAS challenge defines one for the cold-weather drone. The requirement comes from the Defence Drone Initiative's digital-enablers stream, communications, cyber, and C2 for autonomous platforms (verify), read together with what community compliance reviews actually ask for. The table below turns that into measurable targets. Each row gets a test case with pass/fail evidence before it is claimed.

What the Hobby Version Proves

A bench fleet cannot prove operational security for a military program. What it can prove, with published evidence, is that the standard open-source controls work when they are configured deliberately, and exactly how they fail when they are not.

• A written threat model. STRIDE across every trust boundary: the radio link between ground station and vehicle, the companion computer to flight controller link, the ROS 2 network, USB and serial ports, firmware and OTA update paths, and logs and keys. Output is a data-flow diagram, an asset list, a threat table, and one test case per threat.
• Controls with attack evidence. For each of the six controls, a demonstration that the attack works with the control off and fails with the control on. Community guidance for compliance reviews is specific here: show unsigned and wrongly signed packets rejected, and correctly signed packets accepted.
• A working detector, not just walls. Prevention controls get bypassed eventually; the pymavlink IDS and SIEM pipeline prove the fleet notices when they are.
• A measured cost. SROS2 enforcement and WireGuard are not free; the build measures CPU and latency with and without each control so the overhead is a number, not a guess.
• A reusable hardening checklist. The deliverable another hobby fleet could apply in a weekend, with the evidence format a compliance reviewer expects.

Architecture

Figure 1: every trust boundary carries a named control. The GCS link is encrypted by WireGuard and authenticated by MAVLink 2 signing; firmware and updates are signed; the ROS 2 graph is partitioned by SROS2 enclaves; and a protocol-aware IDS watches the traffic that remains, alerting into a SIEM.

The design rule is that each boundary in the threat model maps to exactly one primary control, and the IDS watches all of them. MAVLink 2 signing authenticates commands and blocks replay but does not encrypt, so WireGuard covers confidentiality on the IP path. Signing keys travel only in SETUP_SIGNING over a secure link like USB, never over the radio. The ROS 2 side is partitioned so a compromised node cannot reach topics outside its enclave. Updates and firmware share the signature discipline so a tampered image is refused at two independent points: at boot and at install.

Nothing on this diagram touches the open internet. The lab runs SITL instances and bench hardware on an isolated VLAN behind the managed switch, because attacking your own fleet is only legitimate on infrastructure you own and control.

How to Build It

Phase 0: Threat model first (week 1)

1. Draw the data-flow diagram: ground station, radio link, flight controller, companion computer, ROS 2 graph, USB and serial ports, firmware and OTA paths, logs, and key storage.
2. Build the asset list: signing keys, firmware images, mission data, telemetry logs, hardware tokens.
3. Run STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) across each boundary and record one threat per row.
4. Write one test case per threat. A threat without a test case is a worry, not a requirement.

Phase 1: MAVLink 2 signing (weeks 2-3)

1. Enable signing on the GCS-to-vehicle links. Signing appends a 13-byte block to each packet: a link ID, a 48-bit timestamp in 10 microsecond units since 2015-01-01, and a 48-bit signature made of the first 6 bytes of SHA-256 over the key plus packet.
2. Understand the boundary: signing authenticates and blocks replay, it does not encrypt. One shared 32-byte symmetric key per link.
3. Provision keys only over a secure link: the key travels in SETUP_SIGNING, over USB, never over the radio. On PX4 the key is stored as a file on the SD card; logs must never capture the key.
4. Run the three compliance-review tests: unsigned packets rejected, wrongly signed packets rejected, correctly signed packets accepted. Add the fourth: replayed packets rejected.
5. Set policy for MAVLink 1 and unsigned traffic to reject, then verify the policy holds.

Phase 2: Link encryption (week 3)

1. Stand up a WireGuard tunnel between the vehicle companion computer and the ground station over IP, and route telemetry through it.
2. Document what this does not cover: serial radios stay outside the tunnel, so their limits get stated in the threat model rather than claimed as encrypted.

Phase 3: Signed firmware (weeks 4-5)

1. Practise on a spare board first. The ArduPilot secure bootloader verifies signed firmware images, up to two key pairs, using Ed25519 via the Monocypher library. A forum post claiming ECDSA is wrong.
2. Keep the private key offline. Keys are manageable over the MAVLink secure-command path, so that path is part of the security boundary and gets its own test case.
3. Know the failure modes from forum reports before touching the real fleet: the bootloader allows unsigned firmware when all public keys are removed; USB can bypass MAVLink signing, so lock down DFU; a wrongly signed board loops in the secure bootloader, which is why the spare board exists.
4. Test: a tampered image refused at boot; a correctly signed image accepted; key removal behaviour documented, not discovered by accident.

Phase 4: SROS2 least-privilege enclaves (weeks 5-7)

1. Stand on ROS 2 Jazzy (Ubuntu 24.04). Lyrical Luth went GA May 22, 2026 as an LTS to May 2031, but package support lags, so Jazzy is the base.
2. Create the SROS2 keystore and one enclave per node, with signed governance and permissions files; enforcement comes from the security environment variables.
3. Write least-privilege topic policies: each node can publish and subscribe only what its job requires.
4. Restrict multicast discovery and firewall the DDS ports on the fleet network.
5. Measure CPU and latency with and without enforcement, and publish both numbers.

Phase 5: Monitoring and IDS (weeks 7-9)

1. Build the primary detector on pymavlink. Suricata has no native MAVLink parser, so it is used only for raw-payload rules or flow logging, not protocol-aware detection.
2. Alert on: unsigned MAVLink 2 traffic, SETUP_SIGNING attempts, parameter writes and mission uploads from unknown sysIDs, arm/disarm from unexpected sources, timestamp regressions, duplicate sysIDs, and MAVLink 1 frames.
3. Add a ROS graph monitor that flags new nodes, topics, and QoS changes against the approved baseline.
4. Ship alerts to a SIEM: Wazuh or ELK. An alert nobody reads is not a control.

Phase 6: Update integrity (week 9)

1. Reuse the secure fleet updates work: TPM measured boot and signed A/B updates.
2. Demonstrate a tampered update rejected, with the evidence logged for the test-case table.

Phase 7: Attack your own lab (weeks 9-12)

1. Run ArduPilot SITL instances on an isolated network, never against anything you do not own.
2. Inject unsigned, replayed, and malformed MAVLink traffic at the fleet and record what each control and the IDS do.
3. Fuzz the parsers with AFL++ or libFuzzer and track crashes to closure.
4. No RF jamming or spoofing, ever. GNSS work is detection only.
5. Write the spec-gap report and publish the hardening checklist with the evidence table.

Spec-Gap Table

Honest status as of publication: every control is designed and every test case is written, and none of them have run yet. This table will be rewritten with evidence as the lab phases complete.

Metrics to Publish

• Test-case pass/fail table with evidence: one row per threat, one artefact per row (pcap, log excerpt, or console capture).
• Signing acceptance and rejection counts: unsigned, wrongly signed, correctly signed, replayed.
• SROS2 overhead: CPU and end-to-end latency with and without enclave enforcement.
• WireGuard overhead on the telemetry path, measured the same way.
• IDS alert latency: injected attack to SIEM-visible alert, in seconds.
• IDS coverage: alert classes tested versus alert classes defined, with misses named.
• Fuzzing results: crashes found, crashes fixed, parser coverage notes.
• Key-handling audit: proof that no signing key appears in any log or telemetry capture.

Hardware to Buy First

• Spare Pixhawk or Cube flight controller: the signed-bootloader practice board, because a wrongly signed board loops in the secure bootloader and that lesson should happen on a spare.
• Pi 5 companion computer: carries the WireGuard endpoint, the ROS 2 nodes, and the pymavlink IDS.
• Two hardware security keys: one in use, one backup, for key custody and signing operations.
• Managed switch with VLANs: the isolated lab network boundary that makes attack testing legitimate and contained.

Vehicles already in the program (the X500-class quad and the rover chassis) become the test fleet; nothing airworthy is required before Phase 7, because SITL carries the early attack work.

Safety and Legal Notes

Related Builds

• Secure Fleet Updates, the signed A/B OTA and TPM measured-boot design this build reuses for update integrity.
• Decision Black Box, the tamper-evident logging sibling: security alerts and evidence rows belong in the same append-only discipline.
• Thermal Search-and-Rescue Drone, the X500-class quad that becomes the first signed-firmware test vehicle in this fleet.
• GPS-Denied Navigation Rover, the ground vehicle side of the fleet, sharing the ROS 2 network this guide partitions with SROS2.
• Canadian Defence Hardware Program, the hub page: how this build fits the Defence Drone Initiative digital-enablers stream and the rest of the bench.

Roadmap

• Now to December: this build and the counter-drone scoring harness come first in the program calendar because they are software and simulation work; the southern Ontario winter is no obstacle when the fleet under attack is SITL instances on a lab VLAN.
• Week 1: publish the STRIDE threat model, data-flow diagram, asset list, and the threat-to-test-case table.
• December to March: run Phases 1-7 indoors; the cold-weather hardware builds (Arctic drone bench work, snow navigation) run in parallel, and their vehicles join this fleet as signed-firmware test subjects once they exist.
• Evidence publication: the test-case table with pass/fail artefacts and the hardening checklist land here as each phase completes, replacing the Planned rows in the gap table.
• Program fit: the evidence pack is written so it maps onto the digital-enablers language of the MINERVA challenges run through Innovative Solutions Canada and the IDEaS program's counter-drone work, where cyber-resilient C2 for autonomous platforms is a stated interest.