Live data from Hacker News

The DNSSEC Root Signing Ceremony

cloudflare.com

31–40 of 49 posts

Re: The DNSSEC Root Signing Ceremony

#31
post #29

Earlier quoted context omitted.

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…

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.

Re: The DNSSEC Root Signing Ceremony

#32
post #19

Earlier quoted context omitted.

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 th…

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

Re: The DNSSEC Root Signing Ceremony

#33
post #2

Access requires the cooperation of 7 individuals, all of whom must be present for a Root Signing Ceremony to take place: The Ceremony Administrator An Internal Witness The Credentials Safe Controller The Hardware Safe Controller Crypto Officer #1 Crypto Officer #2 Crypto Officer #3 Fascinating. What's the signing ceremony for .IO look like? .COM? .NET? .CO.UK? .COM.AU?

> Fascinating. What's the signing ceremony for .IO look like?

For a minor novelty TLD abused by tech hipsters because "IO sounds cool", I suspect there's no ceremony at all.

Re: The DNSSEC Root Signing Ceremony

#34

> 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…

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?

Re: The DNSSEC Root Signing Ceremony

#36
post #34

> 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…

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…

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

Re: The DNSSEC Root Signing Ceremony

#37
post #29

Earlier quoted context omitted.

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…

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.

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.

Re: The DNSSEC Root Signing Ceremony

#38
Okay, so this tremendously complicated and secure ceremony is performed to essentially sign a "Verisign is allowed to do whatever they deem appropriate to the root of DNS in the next six months" certificate.

This is really just security theatre, as all the power is delegated to Verisign, and it is almost impossible to detect Zone Signing Key abuse.

Re: The DNSSEC Root Signing Ceremony

#40

> 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…

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…

> 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.
Post reply on HN