VERTEX.C2
// Hardened Command Architecture · Open Security Research
Zero-trust command and control for autonomous systems operating in contested RF environments.
A reproducible reference implementation: a simulated drone, an on-camera attack against its MAVLink link, and a hardened ground control stack that defeats it — mapped to NIST SP 800-171 and CMMC L2 controls DoD contractors actually have to satisfy.
Drone C2 links assume a benign network. The network isn't.
Three failure modes recur across COTS autonomy stacks. VERTEX C2 reproduces each one in a controlled simulation, then closes it. The threat model below is the load-bearing constraint for everything that follows.
Plaintext MAVLink
MAVLink v2 ships with no encryption by default. On the LAN segment between SITL and a typical GCS, every command — ARM, SET_MODE, MISSION_ITEM_INT — is readable in Wireshark in seconds.
No Peer Authentication
Common COTS autonomy stacks accept commands from any host that can reach the MAVLink endpoint. A second mavproxy instance on the link can re-task or disarm the airframe without a key, a cert, or a challenge.
Implicit Network Trust
GCS hosts routinely expose inbound ports to the LAN, the operator subnet, or the open internet. The link is trusted by topology rather than by signature, leaving the attack surface coextensive with the network surface.
A hardened ground control stack — declarative, observable, end-to-end encrypted.
Treat the link as adversarial. Treat every payload as untrusted. Verify by signature, not by source.
Default COTS Path
- No encryption
- No peer auth
- No audit log
VERTEX C2 Hardened Path
- Encrypted end-to-end
- Mutually authenticated
- Fully observable
01# default posture — MAVLink in the clear02$ tcpdump -i lo -A 'udp port 14550' | head03[!] MAVLink v2 → SET_MODE: STABILIZE04[!] MAVLink v2 → COMMAND_LONG: MAV_CMD_COMPONENT_ARM_DISARM 1.005[!] MAVLink v2 → MISSION_ITEM_INT: 37.7749, -122.419406# no auth · no encryption · trivially injectable07 08# vertex-c2 hardened posture09$ sudo wg-quick up vertex-c210[OK] tunnel up · psk verified · peer=ALPHA-07 (1.5 KB rx)11 12$ tcpdump -i wg0 -nn13192.168.42.1.51820 > 192.168.42.2.51820: UDP 102 [encrypted]14[OK] commands now signed + encrypted + rate-limited at GCSWhat changes when the link is hardened.
- Encrypted Transport
WireGuard ChaCha20-Poly1305 tunnel between SITL and the GCS replaces the default plaintext MAVLink path.
- Mutual Authentication
Pre-shared peer keys at the link layer; mTLS at the GCS ingress via Traefik. No anonymous control path.
- Zero Inbound Exposure
Operator access lands through a Cloudflare Tunnel. The GCS opens no inbound ports to the public internet.
- Observable by Default
Prometheus + Loki capture every command, link state change, and ingress event. Nothing is unobserved.
FluxCD reconciles the entire GCS stack from a Git repo. Every change is reviewable, signed, and reversible.
k3s on Pi-class compute or a hardened VM. The full topology can be rebuilt from the repo in minutes.
Watch a MAVLink link get intercepted in plaintext — then watch it disappear.
The fastest way to internalize the threat model is to see the commands stream past in clear text. The capture below shows a SITL-to-GCS session in Wireshark, then re-runs the same session over the VERTEX C2 tunnel.
Manifests, code, and threat model in one repo. The README is written as a technical brief. Reproduce the attack and the fix on a single Linux host in under ten minutes.
Mapped to the controls DoD contractors actually live inside.
Ten NIST SP 800-171 controls — the load-bearing subset for a hardened C2 stack — with the specific implementation that satisfies each one. The mapping is partial by design: this is research, not an attestation.
| Control | Requirement | Implementation | Status |
|---|---|---|---|
| AC.L1-3.1.1 | Limit access to authorized users | WireGuard peer keys · GCS mTLS | Satisfied |
| AC.L1-3.1.2 | Limit transactions and functions | Traefik route-level RBAC · scoped GCS commands | Satisfied |
| IA.L1-3.5.2 | Authenticate users and devices | Mutual TLS at ingress · WG pre-shared keys | Satisfied |
| SC.L1-3.13.1 | Monitor and protect communications | WireGuard tunnel · Prometheus link telemetry | Satisfied |
| SC.L1-3.13.5 | Subnetwork separation for public-facing components | Cloudflare Tunnel · zero inbound ports on GCS | Satisfied |
| AU.L2-3.3.1 | Create and retain audit logs | Loki + Promtail capture of all GCS commands | Satisfied |
| AU.L2-3.3.2 | Ensure individual operator accountability | Per-operator certs · signed FluxCD commit history | Satisfied |
| SC.L2-3.13.8 | Cryptographic protection in transit | ChaCha20-Poly1305 (data) · TLS 1.3 (control) | Satisfied |
| CM.L2-3.4.1 | Establish baseline configurations | FluxCD-managed declarative manifests in Git | Satisfied |
| SI.L1-3.14.1 | Identify, report, and correct system flaws | Prometheus alerting · ingress anomaly metrics | Satisfied |
// Note: VERTEX C2 is a research artifact, not a certification package. Cryptographic primitives are chosen for transparency and reproducibility; FIPS-validated module substitution is documented in the repository for environments that require it.
About this project.
VERTEX C2 is open security research by a cleared infrastructure and security engineer working at the intersection of autonomous systems and defense-grade compliance.
The project exists to answer a single technical question concretely: what does a hardened, zero-trust command and control architecture look like for autonomous systems operating in environments where the link is actively contested? The repository treats that question as engineering work — reproducible, audited, and mapped to the compliance frameworks DoD contractors already operate within.
- Status
- Active research · v0.4.2-α
- License
- Apache 2.0
- Domain
- Autonomous Systems · C2
- Posture
- CMMC L2 — partial map
- Reproducible
- Single Linux host · k3s
- Scope
- SITL only · no live RF