Intercepting Microsoft wireless keyboard communications

Leichter, Jerry leichter_jerrold at emc.com
Tue Dec 11 10:25:54 EST 2007


On Tue, 11 Dec 2007, Steven M. Bellovin wrote:
| On Tue, 11 Dec 2007 13:49:19 +1000
| "James A. Donald" <jamesd at echeque.com> wrote:
| > Use CFB mode.  That takes care of all the above problems...
| Believe it or not, I thought of CFB...
| 
| Sending keep-alives will do nasties to battery lifetime, I suspect;
| most of the time, you're not typing.  As for CFB -- with a 64-bit
| block cipher (you want them to use DES? they're not going to think of
| anything different), it will take 9 keypresses to flush the buffer.
| With AES (apparently your assumption), it will take 17 keypresses.
| This isn't exactly muggle-friendly.  Just think of the text in the
| instructions...  Redundancy?  I wonder how much is needed to avoid
| problems.  It has to be a divisor of the cipher block size, which more
| or less means 8 extra bits.  How much will that cost in battery life?
Keep-alives are a bad idea.  It's interesting how they keep hitting
limitations of various tecshnologies.  Back in the '70's, I worked on
the design of some protocols to be used by terminals.  In Europe, the
only remote access mechanism you could use was X.25, provided by the
local PTT.  If you had two buildings across the street from each other,
you were legally forbidden from running a wire between them - the PTT
had a monopoly.  An X.25 charges were per packet - a keep-alive would
cost you a fortune.  In fact, sending ACK's could double your costs!

I don't know enough about low-power design to guess where the power
costs actually go.  If there is a significant cost in just starting
the transmitter, then sending two bytes might not use up anything
like twice the energy of sending just one (though it will certainly
use *some* more).

Realistically, some key codes are much, much more frequent than others.
A simple Huffman encoding of the keycodes should let you get an average
message length well below the two bytes that I think are the standard.
(Yes, there are variations due to keyboard usage, but even a fairly
generic encoding should give you reasonable compression.)

No Huffman code is a prefix of another, so you can tell when you've
reached the end of a code.  Then you can use the remaining bits of a
2-byte block for redundancy.  (Of course, some rare keys will require
sending an extra block.)  Just sending as many bits as you can of a
count of messages the keyboard thinks it sent would probably be a pretty
effective check.

These days, you can probably cost-effectively put enough memory
in a keyboard to make this possible.
							-- Jerry

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



More information about the cryptography mailing list