[3115] in cryptography@c2.net mail archive
Bluetooth personal radio LAN has bogus encryption
daemon@ATHENA.MIT.EDU (John Gilmore)
Wed Jul 29 23:20:13 1998
To: cryptography@c2.net, gnu@toad.com
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
