Hacker News Reader

Comment by scintill76 | Hacker News Reader

> The only way to move information from the outside world into the laptop/HSM is via USB drive. Accordingly, the key-signing request is loaded into the laptop via USB.

Hmm, how sure are they that the OS only allows USB drives (as opposed to keyboards, network controllers, etc.), and contains no exploitable bugs? Is an image of the media the laptop was booted from publicly available, and has it been audited?

I almost feel silly asking, given all the time spent designing this and how smart the people are, but after all that trouble it seems amateurish to use USB...

View on HN

I too do not know enough to not feel silly for asking this, but I have a similar feeling, and I am not sure if I have misunderstood the past year's worth of popular articles on USB security, the risk posed by the USB in the context of the ceremony, or both. I had gotten the impression that the firmware vulnerabilities of USB flash drives had proven to be inherent, unavoidable, and utterly devastating; that, basically, any given USB drive could become a general-purpose bus-querying hostile computing device, if once plugged into a machine controlled by a capable and motivated adversary.

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.

I don't know too much about badusb, but I think some mitigation is possible.

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.

There may also be the threat of a malicious entity submitting their key-sign request on a malicious USB device, although the article doesn't seem to say whose USB device gets plugged in.

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.

a camera for scanning something like QR codes

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 :)

Couldn't you just use an actual device medium?

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.

Are SD cards 'raw'?

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.

Doesn't the laptop boot from the DVD drive? If it's already busy being used for the operating system, it can't be used for input/output.

Add another optical drive. The USB they've already got would probably be OK, as an optical disc is more "inert" than a USB flash drive.

Or, you could probably copy the OS from the initial DVD to a ramdisk, allowing to insert a new disc to load data from.

> I had gotten the impression that the firmware vulnerabilities of USB flash drives had proven to be inherent, unavoidable, and utterly devastating

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.

> I assume they transfer it to local storage first before signing it so that a potentially malicious storage device can't pull a switcheroo.

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.

It doesn't have persistent local storage but it does have RAM.

I thought a similar thing myself. The USB drive seems to be the weakest spot of this whole thing, especially with how prevalent USB-based infections are (Stuxnet, anyone?), and the fact that sophisticated enough malware can operate completely autonomously.

I also wonder what other things they may have locked down on the laptop itself to try to stymie key exfiltration? I assume they pulled the wifi/bluetooth chip, but what about the speakers? After all - the whole ceremony is being broadcast live, and depending on the audio degradation from the live stream the speakers may actually be stable enough for successful data exfil.

I'm also curious if they attempt to do any power cleaning/shielding to prevent any forms of tempest monitoring?

> I also wonder what other things they may have locked down on the laptop itself to try to stymie key exfiltration?

The private keys are in the HSM, a separate device (according to the article, connected by an Ethernet cable). The laptop doesn't have access to them.

The main risk I can imagine would be a compromised laptop signing a different KSR which has extra keys, and saving it in a hidden area of the USB key, while pretending to sign the original KSR (and presenting the hashes of the original KSR to the operators).

I agree. The interesting thing here is not even code injected into the laptop, but about fake writes.

Because the article states, that Verisign provide their KSR via the USB, which is than is PGP signed and that signature is checked visually.

But what about, when the DNSSEC signatures are written to the USB stick, which then is handed over to Verisign to be implemented. They are also checked visually? Or can the USB stick (the implemented logic) forge the write and basically modify the written results?

I don't understand the purpose of such an attack. The USB stick can't forge a signature (not even the laptop has the key -- it's in the HSM.) If it corrupted the signature by lying about the writes, they could just re-write on new media.

Reply on news.ycombinator.com