AP_DiskCrypto: full-disk encryption for SD cards - #33584
Conversation
New library implementing transparent AES-256-XTS encryption of the SD card, one 512-byte sector at a time with the sector LBA as the XTS tweak. The AES block work goes through an abstract backend (AP_DiskCrypto_Backend) so a hardware-accelerated cipher can replace the software one without changing the XTS logic; the software backend wraps the vendored tiny-AES-c core. Driven from the FatFS diskio binding via the ap_diskcrypto_encrypt/decrypt C shims. encrypt_sector()/decrypt_sector() are unit tested on SITL against the FIPS-197 AES vector and an OpenSSL-derived XTS known-answer vector, plus round-trip and tweak tests. init() rejects a key whose two halves are equal, as required by XTS. Compiled in only when AP_DISKCRYPTO_ENABLED (set by AP_FATFS_CRYPTO_ENABLED in a board hwdef, or on SITL); unused AES is dropped by --gc-sections otherwise.
Update ChibiOS to add the optional FatFS diskio encryption hook, gated by AP_FATFS_CRYPTO_ENABLED and implemented by the AP_DiskCrypto library. Excluded from the bootloader; no change when disabled.
Add AP_DiskCrypto to the common vehicle libraries so the diskio encryption shim is compiled into firmware. When a ChibiOS board enables AP_FATFS_CRYPTO_ENABLED, force the shim symbols into the link with -u so the back-reference from libch.a (linked after the AP libraries) resolves.
Host-side tool to decrypt a raw image of an AES-256-XTS encrypted SD card back to a mountable FAT image, given the build-time key.
|
I did something similar for lua https://github.com/andyp1per/ardupilot/tree/pr-lua-encryption the team was unwilling to upstream |
I hope that this changeset is both small enough and useful enough that the team finds it valuable. There's more and more crazy people in the world and the last thing I want is someone tracking me down from a crashed quad, or worse. |
How does this protect against that? If I understand correctly you could just USB into the flight controller and read the SD card via MAVFTP. |
|
@kraln hello, Has this ever happened in practice ? Can you point to a newspaper article, criminal case, or court record where someone tracked down a drone owner from a crashed drone and then targeted them ? The encryption will lead to some other issue, like not beeing able to read log for crash analysis and this is bad from a legal point of view, and for manufacturer that won't be able to protect themselft against pilot mistakes |
If it hasn't happened yet, it will. It's just a matter of time. IMO this is a good proactive step forward and as long as it's optional - it gives those who want it the option to turn on this additional security. |
|
We had a long discussion on the weekly dev call about this feature and while opinions were mixed, I'm personally in favour of adding support for SD card encryption. I think implementing this along with MAVlink2 signing on the autopilot's USB port (see issue here) would allow us to protect vehicle's from having their onboard data downloaded by a malicious actor who has gained access to the vehicle. On the other hand, we're keen that the feature be a custom build server option (e.g. allows the feature to be disabled by default thus saving flash), it should be well written and we need a developer (whether a core member of the dev team or a dev from the wider community) to promise they will continue to maintain the feature. This is important because security related features get a lot of scrutiny and ongoing maintenance can require significant effort. |
Correct, this PR doesn't address any other hardening (enabling/forcing code read protection, disabling or adding authentication and authorization to external command links, etc.) as that would likely:
On an individual level... I couldn't find any news articles, but basically every blog article involving finding a lost drone the first step is "try and figure out who the owner is" https://pilotinstitute.com/found-a-lost-drone/#look-for-an-sd-card On a state level... https://www.police1.com/investigations/drone-forensics-how-police-use-digital-evidence-from-drones-to-fight-crime-and-terrorism . Replace "terrorist" with "dissident" or just anyone who happens to do something the current government doesn't like.
As the other commenter mentioned, this PR by itself doesn't stop someone from connecting over Mavlink or USB and interacting with the FC to inspect the storage or gather logs. I've also included a handy python script which can decrypt the storage (if you know the key). Ultimately, the functionality is optional (and default off). As it's a compile-time option, gated by board-level defines, it's not something I would expect to contribute to either of the (valid!) issues you raised.
Ah shame I missed it! I am/was planning to join the Wednesday EU-timezone call. In addition to the signing, probably code readback protection and a few other hardening things would be needed, but they're all individually useful IMHO.
Being unfamiliar, is this a further level of feature gating beyond the
Amen :-)
Likely best discussed in a different venue, but I can likely request approval from my employer to pick the topic up if that's desirable. I also understand if, for the health of the project and governance, you're generally hesitant to have a topic with someone who is essentially an unknown. FWIW this PR is essentially the full shape of the feature, aside from adding HW support for specific microcontrollers which may have it. A hook on the FatFS block read/write which enables the data to be 'transparently' encrypted/decrypted coming in and going out of storage, paired with what amounts to the reference AES-XTS encryption scheme. I wouldn't expect a lot of churn... |
7 participants
Summary
Adds support for transparent full-disk encryption of the SD card, with a software AES core
and a clean interface for platforms with hardware acceleration.
Off by default.
Classification & Testing (check all that apply and add your own)
Testing performed:
different inputs/outputs against OpenSSL's implementation
AP_FATFS_CRYPTO_ENABLED 1and disabled;the flash cost is ~0 when disabled due to garbage collection at the linker level (so, no impact).
It's about 2.5kb when enabled.
Description
Firmware updates, waypoints, logs and more land on the SD card (when present and on
platforms that support them). The ChibiOS FatFS layer acts as a translation/lookup tool,
so deleting files (well, "unlinking" them) doesn't guarantee data is actually gone. This
means that a lost or stolen card can reveal unintended and undesired information about
the vehicle operator, even if the vehicle is destroyed (stuck in a tree, etc.)
This PR adds transparent full-disk encryption so every sector, including the metadata which
shows what files are present, is encrypted. The encryption is fully software, with an interface
for extending it with hardware acceleration on microcontrollers that support it. The implementation
uses AES-256-XTS, similar to BitLocker,/LUKS, etc.
The key is a build-time constant, so this only protects against the card being removed. There's a python utility
to decrypt SD card contents from a host computer, given the (known) key.
Notes: