Hacker News Reader

Comment by entire-name | Hacker News Reader

I guess even some sort of "signed device protocol" will not work. An attacker can just create a device that guesses the device identifier (or whatever is used to create the signature). Then, the attacker device can just keep guessing until it gets it right. Chances are, some serial number or similar will be used for this, so continuous guessing is feasible.

Will the solution to this, then, be to have some sort of "smart card enabled device"? For example, assuming TOFU, you manually accept all device's public keys (and all devices, including cables and stuff will have one of these). Then, the computer will have to verify all actions done by those devices by sending a challenge for each action. But this seems impractical and inefficient...

Perhaps physical security is the only way for this...

View on HN

On Windows XP this would display a “new device: keyboard connected” balloon and the Safely Remove Device icon would immediately set-off my spidersense - it’s unfortunate that newer releases of Windows hide those notifications by default and the only clue that something might be wrong would be hearing the generic device connected sound multiple times in quick succession which many users might think was their sound-card glitching.

I think a solution is for OSs to only allow the automatic mounting of newly-attached devices if they’re “passive” (e.g. mass storage - assuming no autorun.ini, output-only devices, HID class devices that only expose game-controller functionality, etc) - other device classes like mice and keyboards plugged-in to non-trusted ports should always require explicit approval.

While we’re on the subject: keyboards can be massively improved by adding over-the-wire encryption to prevent keyboard-port logging, and the USB keyboard class should be extended to include the keyboard declaring its layout to the host OS. It’s silly that we still need to configure keyboard language settings or that the OS infers it from our regional settings.

How would you approve the keyboard without using the keyboard?

Anyway since we are assuming physical access, they could just swap out your keyboard for one that works normally until you go for lunch, then starts typing for itself..

The OS could display a random sequence of keys that you have to press to enable the keyboard. If the evil cable can't see the screen it wouldn't know what keys to transmit.

This is not a serious suggestion since it would be annoying to most people.

No more annoying than Bluetooth pairing PINs or iOS's passcode-to-use-USB prompts. If the keyboard has secure stateful memory (e.g. for a client-certificate or client-secret) then the user would only have to enter it once.

> How would you approve the keyboard without using the keyboard?

On laptops the built-in mouse and keyboard would be "trusted".

On desktops and servers, I can think of a couple of strategies:

* Always trust keyboards only when plugged into certain USB ports (e.g. ports on the front of the computer highly visible to the computer's operator) * Mutual keyboard/host authentication and encryption.

>Will the solution to this, then, be to have some sort of "smart card enabled device"? For example, assuming TOFU, you manually accept all device's public keys (and all devices, including cables and stuff will have one of these). Then, the computer will have to verify all actions done by those devices by sending a challenge for each action.

Even that's not enough. If you're feeling extra-evil you could tamper with the keyboard switches/traces to do whatever evil stuff you want. It's not like you can authenticate the on/off state at a switch level.

No need for any public crypto. On first use, the computer issues a unique key which the device uses to authenticate all messages, for example with hmac.

Reply on news.ycombinator.com