Re: Intercepting Microsoft wireless keyboard communications
On Tue, Dec 11, 2007 at 02:01:03PM -0500, j...@tla.org wrote: How many bits (not just data, also preamble/postamble, sync bits, etc.) is the keyboard sending for each keystroke anyway? FWIW, it is likely sending keyboard scan codes: http://en.wikipedia.org/wiki/Scancode It doesn't send the actual characters typed, because games and the like need to know when keys are depressed and released, not just what letter was typed. Here's an overview of keyboard input under Linux: http://www.subspacefield.org/~travis/keyboard/index.html -- Obama Nation | My emails do not have attachments; it's a digital signature that your mail program doesn't understand. | http://www.subspacefield.org/~travis/ If you are a spammer, please email j...@subspacefield.org to get blacklisted. pgpePeM4q7uNa.pgp Description: PGP signature
Re: Intercepting Microsoft wireless keyboard communications
James A. Donald [EMAIL PROTECTED] writes: At every block boundary, keyboard transmits a special signal in the clear that signifies block boundary. Any time that no key has been pressed for a while, then when a key is finally pressed, keyboard transmits a bunch of no- ops sufficient to ensure that the recipient has recently received an entire block, followed by a complete description of current keyboard state, so that ... the battery runs down in a fraction of the time that it does for any other keyboard on the market. Would it be possible to use load modulation (e.g. ISO 14443, for which transponders are readily available) to get around this, where the power for the communication is supplied by the PC? That way you could have a protocol that's as chatty as you like without your keyboard ending up as an advertising device to make your competitors' products look good. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
On 12/10/07, Steven M. Bellovin [EMAIL PROTECTED] wrote: Believe it or not, I thought of CFB... What about PCFB to get around the block issue? I remember freenet using it that way... -- Taral [EMAIL PROTECTED] Please let me know if there's any further trouble I can give you. -- Unknown - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
Steven M. Bellovin wrote: 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? Keypress signals, or change of keyboard state signals, do not need to be a divisor of the cipher block size. At every block boundary, keyboard transmits a special signal in the clear that signifies block boundary. Any time that no key has been pressed for a while, then when a key is finally pressed, keyboard transmits a bunch of no-ops sufficient to ensure that the recipient has recently received an entire block, followed by a complete description of current keyboard state, so that recipient knows what change of keyboard state signals are changes from. Conversely, when the receiver has not received any signal for a while, it expects such a signal, and distrusts anything else. Muggle unfriendliness only occurs if user is typing through a boot up, which is unlikely to terribly surprise the user, who is probably banging away at the same keys over and over again waiting for a reaction, or if the user wanders out of range while typing, then wanders back in range again while still typing, in which case again the user is unlikely to be very surprised. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
| 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. | | Im 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 [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
Steven M. Bellovin wrote: 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. Im 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. Use CFB mode. That takes care of all the above problems. You can transmit any small bunch of bits, don't need to transmit a complete block, and if the keyboard and the receiver get out sync, the keyboard's signal will be decrypted as garbage for the first 128 bits. If one has the keyboard regularly transmit no key's pressed from time to time, and if valid key press representations have a couple of check bits redundancy, with several keypresses being ignored after any invalid key signal, keyboard and receiver will synchronize with no fuss. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Intercepting Microsoft wireless keyboard communications
On Tue, 11 Dec 2007 13:49:19 +1000 James A. Donald [EMAIL PROTECTED] wrote: Steven M. Bellovin wrote: 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. Im 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. Use CFB mode. That takes care of all the above problems. You can transmit any small bunch of bits, don't need to transmit a complete block, and if the keyboard and the receiver get out sync, the keyboard's signal will be decrypted as garbage for the first 128 bits. If one has the keyboard regularly transmit no key's pressed from time to time, and if valid key press representations have a couple of check bits redundancy, with several keypresses being ignored after any invalid key signal, keyboard and receiver will synchronize with no fuss. 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? --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: Intercepting Microsoft wireless keyboard communications
When I looked at this circa 2001-2002, for another company, other 27MHz keyboards didn't even bother to encrypt. Most of the data was sent in the clear, with neither encryption nor robust authentication. 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. Ian. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leichter, Jerry Sent: Friday, 7 December 2007 10:13 AM To: cryptography@metzdowd.com Subject: Intercepting Microsoft wireless keyboard communications http://www.dreamlab.net/download/articles/Press%20Release%20Dreamlab%20T echnologies%20Wireless%20Keyboard.pdf Computerworld coverage at http://www.computerworld.com/action/article.do?command=viewArticleBasic; articleId=9051480 The main protection against interception is the proprietary protocol, which these guys were able to reverse engineer. The exchange is encrypted using a Caeser cipher (XOR with a single byte that is the common key, which is the only secret in the system); they say they can determine the right key within 30 characters or so. Their current hardware can read the data from 33 feet away; with a better antenna, well over a hundred feet should be possible. These things operate at 27 MHz, which will penetrate walls easily. Reading multiple keyboards at once is possible and they already do it. They are looking at injecting data into the stream - presumably not very hard. Many other brands of wireless keyboard may well be equally vulnerable. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
