My understanding is that it requires cooperation from the kernel. USB itself does not automatically allow DMA, but a driver can instruct the host controller to handle packets via DMA.
So if you blacklist all device types (input devices) except the SD card and the driver for that card does not need DMA then everything should be fine because they check the signature of the key signing request. I assume they transfer it to local storage first before signing it so that a potentially malicious storage device can't pull a switcheroo.
Long story short:
- they need a USB/udev firewall
- whitelist devices that don't allow DMA through their drivers
- verify the data *after* transferring it from USB.In the article they mention it doesn't have local storage. It's too bad they didn't go into more detail about tamper proofing the USB portion of the ceremonies.
> This laptop has no battery, hard disk, or even a clock backup battery, and thus can’t store state once it’s unplugged.
1. Use an USB key that doesn't have an updateable firmware. 2. Configure the laptop to only accept a single USB mass storage device on a dedicated port. No keyboard, no mouse. I should be possible with udev rules.
I agree it's probably simple to lock down the possible USB devices (ideally, don't even compile-in support for them in the kernel), but I am wondering if anyone can confirm it's been done, and I would still worry about exploits in the USB stack or hardware. It seems like this is the biggest chink in the armor, so I'd go for hand-keying from paper (a redundant encoding can probably make this not excruciating for the humans involved), another optical disc (CD-R), a floppy disk, a camera for scanning something like QR codes, a simple wired serial link, serial over infrared. I suppose these all have some tradeoffs, but at least some of them don't involve plugging in another electronic device that uses a complex general-purpose protocol just to transfer what probably amounts to a few dozen kilobytes.
I can see it now: A hacker with tiny QR code imprinted cuff links or rings. They brush their hand close to the camera, seemingly by accident, and BOOM! Buffer overflow in the QR decoder :)
The fact that a burnable CD should have no parts that can think actually makes using one for input and one for output probably safer (though you would then need the trusted application to include a CD/DVD burning capability).
As an alternative, a 'raw' interface, such as an actual programmable flash device or maybe an SD card could work.
I thought that they have their own ARM processors inside together with (updatable?) firmware. You can buy wifi-enabled cards, for instance.
OTOH, I assume they don't have direct access to the USB bus and so can't pretend to be other devices. But that still leaves lots of room to do nasty things with the data 'secured' on it.
Or, you could probably copy the OS from the initial DVD to a ramdisk, allowing to insert a new disc to load data from.
If that understanding was correctly received, and given the strength of potential motivation involved here, my thought is that the problem presented by the USB drive could only be combated by (a) ensuring that the USB drive was obtained in a random enough fashion that vast numbers would need to be deliberately compromised with this specific target in mind for that approach to be feasible, and (b) ensuring that the USB drive was neither ever unsupervised nor connected to any USB port (except one on a "known-to-be-clean" computer) after the selection occurred.
The problem that I see with those measures is that if compromising the laptop with a compromised USB drive were possible, then the actual security of the process would be purely dependent on the security of measure (b), as established by a single actor at the ceremony: that is, whomever provides the USB with the key-signing request. This last point just by itself would seem to be a degree of risk well beyond the criteria implied by the established protocol.