30 July 1998
To: cryptography@c2.net, gnu@toad.com Subject: Bluetooth personal radio LAN has bogus encryption Date: Wed, 29 Jul 1998 19:49:42 -0700 From: John Gilmore <gnu@toad.com> There's a new standard proposed for automatically connecting laptops, keyboards, printers, mobile peripherals, cellphones, etc. The intent is to replace cables and connectors, so that anything will talk to anything. It's a radio protocol implemented in a single chip, that reaches for about 10 meters, can handle 8 devices on the LAN, run 10 LANs in a room without interference, and push three phone calls and about 440 kbits/sec of full duplex data around a LAN. It's called Bluetooth and is described at www.bluetooth.com. It's supported by Nokia, Intel, Toshiba, Ericsson, IBM, and others. It was announced in May. Unfortunately they are giving us Yet Another screwed up radio encryption scheme. I wonder if they even bothered to take orders from the NSA, or whether they just designed it this way knowing what the answer would be. Here's the description -- which doesn't even deign to name the algorithm -- from http://www.bluetooth.com/techn/baseband/index.asp: Authentication and Privacy The Bluetooth baseband provides user protection and information privacy mechanisms at the physical layer. Authentication and encryption is implemented in the same way in each Bluetooth device, appropriate for the ad hoc nature of the network. Connections may require a one-way, two-way, or no authentication. Authentication is based on a challenge-response algorithm. Authentication is a key component of any Bluetooth system, allowing the user to develop a domain of trust between a personal Bluetooth device, such as allowing only the owner's notebook computer to communicate through the owner's cellular telephone. Encryption is used to protect the privacy of the connection. Bluetooth uses a stream cipher well suited for a silicon implementation with secret key lengths of 0, 40, or 64 bits. Key management is left to higher layer software. The goal of Bluetooth's security mechanisms is to provide an appropriate level of protection for Bluetooth's short-range nature and use in a global environment. Users requiring stalwart protection are encouraged to use stronger security mechanisms available in network transport protocols and application programs. I'm sure NSA and FBI are salivating about building little Bluetooth receivers disguised as pencils, electrical outlets, phone cables, etc. These would be able to listen in on the 40-bit-lousy-cipher-protected transmissions of any device in the room or nearby. To target your communications, they don't even have to break in and substitute your cables with interception-friendly ones; the cables have been replaced by an interception-friendly radio medium which they can probably tap by sticking something on the outside of your house or office. If this protocol is going to replace "cables" in the future, it needs much better authentication and much better privacy. I tentatively think it should be using 3DES for privacy. It's a small number of gates for modern hardware at these data rates, and it's better tested than anything else we have lying around. There need be no hardware options for key length; software can always "dumb it down" by restricting the number of varying bits in the keys. E.g. a 0-length key can just be a key of all zeroes. (Curiously enough, I've heard that in the digital cellular systems that enable encryption -- which are few and far between -- the key they negotiate always turns out to be zero. Funny that. In Bluetooth, at least you could monitor your own devices to see how "random" the key turns out to be in real life.) For authentication, challenge-response is appropriate, but what exactly is the challenge and response? We need more info to evaluate it. We don't want a system that takes many seconds for a "cable" to connect, nor one that requires circuitry for modular multiplication. But we want something that can identify the end-user's own devices among the gaggle of devices reachable in the room, and that can bootstrap a dynamic key-agreement for the privacy layer. Since this thing hasn't been deployed in any products yet, and isn't a government standard where they ignore all public input, we have a real chance to influence it. Let's see what we can learn and what we can get changed in it. They're looking for public acceptance -- and we can influence that, if we are accurate and persuasive. John
To: cryptography@c2.net, gnu@toad.com Subject: Re: Bluetooth personal radio LAN authentication idea Date: Wed, 29 Jul 1998 20:08:22 -0700 From: John Gilmore <gnu@toad.com> A postscript thought: Our implementation of authentication can be arbitrarily complex, if a simple touch-contact interface existed to simplify the user interface. Like the "Java ring", it only needs one wire or contact to communicate. E.g. you would tell the devices "I'm about to introduce you to another of my devices" and then bump the two devices together, and they would establish authentication of each other. (They can push 400 kbit/sec over the Bluetooth radio link, so all they really need is say 9600 baud over the physical-contact link, to pass secrets that shouldn't go via radio, and to prove that the device you're talking to on the radio is the same device your user wants to introduce to you.) An ideal user interface would allowed a tenth-of-a-second contact to provide the authentication. The actual technology of authentication could be as complex as we can reasonably fit into a small chip -- e.g. a randomly generated shared secret key pair for 3DES would suffice. This would eliminate the need to manually configure for authentication, e.g. enter the same 4-digit PIN on each device (which would offer minimal security, and requires a keyboard interface on each device). They contemplate using this for really simple things like headphones (audio output devices), eliminating the cable between a radio, cellphone, ordinary phone, or PC and the headphones. Presumably you wouldn't want your neighbor on the train to be able to listen in on your phone call, using his own (possibly customized) Bluetooth headphones. Of course, people who wanted to intercept you could "bump into you" to authenticate their interception devices to yours. I suppose the paranoid among us could put electrical tape over their "private ports" once they had authenticated their devices to each other. Is that what those black rectangles in those pictures is? John