Intercepting Microsoft wireless keyboard communications

Leichter, Jerry leichter_jerrold at emc.com
Mon Dec 10 15:32:59 EST 2007


| > Exactly what makes this problem so difficult eludes me, although one
| > suspects that the savage profit margins on consumables like
| > keyboards and mice might have something to do with it.
| > 
| It's moderately complex if you're trying to conserve bandwidth (which
| translates to power) and preserve a datagram model.  The latter
| constraint generally rules out stream ciphers; the former rules out
| things like encrypting the keystroke plus seven random bytes with a
| 64-bit block cipher.  Power is also an issue if your cipher uses very
| much CPU time or custom hardware.
| 
| I"m sure most readers of this list can propose *some* solution.  It's
| instructive, though, to consider everything that needs to go into a
| full system solution, including the ability to resynchronize cipher
| states and the need to avoid confusing naive users if the cat happened
| to fall asleep on the space bar while the CPU was turned off.
Somewhere - perhaps in the Computerworld article - someone mentions that
some devices use Bluetooth, "and are therefore much more secure".

In practice, most Bluetooth devices don't even agree on a non-zero
key when pairing, so just using Bluetooth is no promise of anything.
Does anyone know how good Bluetooth security can potentially be -
and is it practically attainable in the low power/lost message
context that would be needed here?  How are some of the emerging
low-power protocols (e.g., ZigBee) dealing with this?

							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list