We recently completed a full security assessment of a custom RISC-V flight controller SoC and the autonomous drone platform built around it for a client. The engagement gave us unusual depth of access: full RTL source, firmware source, schematics, and a production-representative prototype.
Here is what we found, and what it teaches about embedded security in autonomous systems.
Scope
The assessment covered four surfaces:
- The flight controller FPGA prototype: an SoC with dual-core RISC-V, an AES-GCM accelerator, sensor interfaces, and motor control.
- The firmware image: bare-metal, no RTOS.
- The telemetry link: encrypted and frequency-hopping.
- The ground control station software.
We used ChipWhisperer for side-channel analysis, bus pirate and logic analyzers for interface probing, Ghidra for firmware analysis, and custom tooling for protocol fuzzing.
Key findings
Critical: secure boot not enabled. The SoC had a secure boot ROM in the IP library, but it was not enabled in the flight controller configuration. The device booted directly from unverified SPI flash. An attacker with physical access could replace the firmware with a malicious image. We recommended enabling the secure boot chain with PUF-derived key verification.
High: AES-GCM timing side-channel. Power analysis using ChipWhisperer revealed timing-dependent power variation during AES operations. After approximately 50,000 captured traces, we could observe correlation patterns that could theoretically enable key extraction. We recommended a constant-time execution mode in the hardware accelerator — a fix that required changes to the SoC RTL, not just firmware.
High: JTAG debug active. The debug port was accessible on the prototype. For production, we recommended a one-time-programmable fuse to permanently disable JTAG after manufacturing test.
High: firmware stored unencrypted. SPI flash contents were readable with a bus pirate. Combined with the inactive secure boot, this meant full firmware extraction and analysis was trivial.
Medium: telemetry nonce management. The AES-GCM nonce was regenerated from TRNG rather than incremented, causing periodic collisions and a predictable 47-second communication disruption. Not a cryptographic vulnerability, but operationally significant for defense applications.
What makes this assessment different
Our findings didn’t end at “we recommend fixing this.” The client gave us access to the RTL source, not just the compiled firmware. So the side-channel finding led directly to a concrete hardware fix: constant-time AES mode added to the accelerator’s IP library. It was not a workaround bolted onto firmware. The JTAG recommendation became a standard feature the client rolled into every future SoC configuration, not a one-off patch.
That’s the value of a full-depth assessment. Fixes that hold at the silicon layer protect every product built on that platform going forward, not just the unit we tested.
This is part of the KnytX security-consulting practice: hands-on hardware and firmware assessments for embedded and autonomous systems. To scope an assessment of your own device, book a scoping call.