I've written a bunch about my desire to be able to connect an untrusted input device to my computer or phone so that we could get hotels and other locations to offer both connections to the HDTVs in the rooms for monitors and a usable keyboard. This would let one travel with small devices like netbooks, tablet computers and smart phones yet still use them for serious typing and UI work while in the hotel or guest area.

I've proposed that the connection from device to the monitor be wireless. This would make it not very good for full screen video but it would be fine for web surfing, email and the like. This would allow us to use the phone as its own mouse, either by having a deliberate mouse style sensor on the back, or using the camera on the back of the phone as a reader of the surface. (A number of interesting experiments have shown this is quite doable if the camera can focus close and can get an LED to light up the surface.) This provides a mouse which is more inherently trustable, and buttons on the phone (or on its touchscreen) can be the mouse buttons. This doesn't work for tablets and netbooks -- for them you must bring your own mini-mouse or use the device as a touchpad. I am still a fan of the "trackpoint" nubbins and they can also make very small but usable mice.

The keyboard issue is still tough. While it would seem a wired connection is more secure, not all devices will be capable of such a connection, while almost all will do bluetooth. Wired USB connections can pretend to be all sorts of devices, including CD-Roms with autorun CDs in them. However, I propose the creation of a new bluetooth HID profile for untrusted keyboards.

When connecting to an untrusted keyboard, the system would need to identify any privileged or dangerous operations. If such operations (like software downloads, destructive commands etc.) come from the keyboard, the system would insist on confirmation from the main device's touchscreen or keyboard. So while you would be able to type on the keyboard to fill text boxes or write documents and emails, other things would be better done with the mouse or they would require a confirmation on the screen. Turns out this is how many people use computers these days anyway. We command line people would feel a bit burdened but could create shells that are good at spotting commands that might need confirmation. In addition, the device would pair with the untrusted keyboard only for a limited time. After any serious period of non-use, the pairing would be forgotten, and a simple re-pair, involving typing a code number on the keyboard or a confirmation on your device screen, would be in order.

Finally the device would be set to output a special key click for every keystroke received from the untrusted keyboard. If you start hearing that click and you are not typing, that's a sign that the keyboard has gone rogue. The device would be set to take keystrokes at a limited speed so you could get to the device and tell it to abort. The longer it has been since you typed, the slower it might get, with dangerous characters like Enter, Alt-Tab and the like given higher barriers. (It might make sense to even not allow enter and the like from the untrusted keyboard. You would have to tap your touchscreen device to hit enter and various other sequences known to cause actions on your OS.)

You might still leave the room with your device still connected, and if you did that just after typing the keyboard might be able to play tricks. To reduce that, you could also decide to always carry a small bluetooth device like a headset. If the headset is not also in the room, the device might refuse input from the keyboard. As such, in most cases, the keyboard could not play games that you would not hear.

As noted, the main goal of an attacking keyboard would be to type commands to get the system to download and run evil code. As long as this always requires confirmation you will be safe from that. It might also try to exploit things like browser bugs and direct your browser to an attacking web site. This is harder to prevent but requires the keyboard detect it has control the browser (without you present to stop it) and then act quickly. If the browser can be modified to require confirmation on typed-in URLs, this can help here. In addition, you would probably need to disable certain keyboard shortcuts, including keyboard based link selection and clicking, from an untrusted keyboard. Typed in links are rarer these days. The keyboard would need to be able to do web searches, as these are very common, but it should be barred from selecting links -- the mouse must be used for that. Running of arbitrary commands will need confirmation, as would keyboard shortcut navigation of menus of commands. For some operations, such as password entry, it will be necessary to use the hard-to-use keyboard or virtual keyboard of the portable device.

With these steps, a user with good security awareness could probably use an untrusted keyboard. This is particularly true if they are used to the idea of signing off from the keyboard every time they want to leave the room, or using a proximity device. If the portable device is not being used as a mouse, then its own proximity sensors or its own camera could be used to assure that a human being is truly sitting at the keyboard, and not accept any keys if this is not the case. In that event, with the audio feedback and the acceptance only of keystrokes that will be displayed (ie. typing) it becomes harder, though not yet impossible, for an untrusted keyboard to do an undetected attack, and possibly even a successful one.