| CATHAL'S
CORNER |
|
Cathal Mc Daid
Feb 2001 |
Nothing has caused more concern and confusion in Bluetooth than the
nature of Bluetooth security implementation. From those who insist
that its security is a disaster area, prey to any half-capable
opportunist, to the contrary view that’s its security is second to
none. The nature of its microwave link, as opposed to a fixed cable
connection means that it is especially vulnerable to attack.
In this document we will briefly examine the nature of the security
features implemented and their effectiveness. This part covers the lower
level of Bluetooth security (Link Level security), next month we will
examine the upper layers and the merits/drawbacks of Bluetooth in the
security arena.
In the Bluetooth Generic Access Profile (GAP) the bed-rock on which
all other profiles are based), 3 Security modes are defined:
Security Mode 1: non-secure
Security Mode 2: service level enforced security
Security Mode 3: link level enforced security
In Security mode 1 a device will not initiate any security - this is
the non-secure mode.
The essential difference between Security Mode 2 and Security Mode 3
is that in Security Mode 2 the Bluetooth device initiates security
procedures after the channel is established (at the higher
layers), while in Security Mode 3 the Bluetooth device initiates
security procedures before the channel is established (at the
lower layers).
At the same time two possibilities exist for Device’s access to
services:
"trusted device" and
"untrusted device"
The trusted device have unrestricted access to all services. The
untrusted device doesn’t have fixed relationships and its access to
services is limited. For services, 3 security levels are defined:
services that require authorization and authentication, services that
require authentication only and services that are open to all devices.
These levels of access are obviously based on the results of the
security mechanisms themselves so they aren’t really of interest to
us, thus will concentrate on the two areas where the security mechanisms
are implemented: the service level & link level.
In this section we will examine Security Mode 3 (Link Level
security), next month we will examine Security Mode 2 and Bluetooth’s
overall security strength.
There are 4 entities used to setup/maintain the security at the link
level
-
The Bluetooth device address (BD_ADDR), which is a 48-bit
address that is unique for each Bluetooth device and defined and
allocated by the IEEE.
-
Private link key, which is a 128-bit random number used
for authentication purposes.
-
Private encryption key, 8-128 bits in length that is used
for encryption.
-
A Random number (RAND), which is a frequently changing
128-bit random or pseudo-random number that is made by the Bluetooth
device itself.
These are used in the following security mechanisms
There are several kinds of keys in the Bluetooth system to ensure
secure transmission. The most important key of these is the link key,
which is used between two BT devices for authentication purposes. Using
the link key an encryption key can be derived. This secures the data of
the packet and is regenerated for all new transmissions. Finally,
although not a key there is the PIN code, which can be used to help
identify devices to each other.
There are four types of link keys possible. All the link keys are
128-bit random numbers and are either temporary or semi-permanent.
-
Unit key, KA,is derived at the
installation of the Bluetooth device from a unit A.
-
Combination key, KAB, is derived
from two units A and B. This key is generated for each pair of
devices and is used when more security is needed.
-
The Master key, Kmaster, is used
when the master device wants to transmit to several devices at ones.
It over rides the current link key only for one session.
-
The Initialisation key, Kinit,is
used in the initialisation process. This key protects initialisation
parameters when they are transmitted.
Encryption key is derived from the current link key. Each time
encryption is needed the encryption key will be automatically changed.
The reason for separating the authentication key and encryption key is
to facilitate the use of a shorter encryption key without weakening the
strength of the authentication procedure.
Figure 1 - Key control
This is a user selected or fixed number, normally 4 digits in length,
but it can be anything
between 1 to 16 octets. The user can change it when it wants to and
this adds security to the system. The PIN can be used entering it into
one device (fixed PIN), but it is safer to enter it to both units.
The exchange of the keys takes place during an initialisation phase,
which has to be carried out separately for each two units that want to
implement authentication and encryption. All initialisation procedures
consists of the following:
After this procedure the link is either built or aborted.
The Bluetooth authentication scheme is essentially a challenge-response
strategy, where a 2-move protocol is used to check whether the other
party knows a shared identical secret key ( a symmetric key). Basically
the protocol checks that both devices have the same key, and if they do
authentication is successful. also during the authentication procedure ,
an ACO value (Authenticated Ciphering Offset) is generated and stored in
both devices. This ACO value is used (in a round-about way) to generate
the encryption key later on.
Figure 2: Description of the authentication process
The Authentication scheme works as follows:
Step 1 The verifier sends the claimant a random number to be
authenticated.
Step 2 Both verifer+claimant use the authentication function
E1 with the RAND (random number), the claimants BD_ADDR and the current
link key to get a response.
Step 3 The claimant sends the response to the verifier, who
then makes sure the responses match.
This application indicates who is to be authenticated. Note this
means that the verifier may not necessarily be the master, as some of
the applications may require only one way authentication, (only one
party is authenticated) , rather than mutual authentication.
If the authentication fails, there is a period of time (the waiting
time) that must pass until a new attempt at authentication can be
made. This can subsequently increase or decrease depending on the
results of previous authentication attempts (until preset timers have
been exceeded).
The Bluetooth encryption system systematically encrypts the payload
of each packet. This is done with a stream cipher E0, which is
re-synchronized for every payload. The E0 stream cipher consists of 3
elements:
Figure 3: Description of the encryption process
First the payload key generator combines the input bits in an
appropriate order, then it shifts them to the 4 LFSR (Linear Feedback
Shift Registers) of the key stream generator.
There are several encryption modes available (depending on whether a
device uses a semi-permanent link key or a master key). If a unit key or
a combination key is used, broadcast traffic is not encrypted.
Point-to-point traffic can be either encrypted or not. If a master key
is used, there are three possible modes. In
-
encryption mode 1, nothing is encrypted.
-
encryption mode 2, point-to-multipoint (broadcast) traffic
is not encrypted, but point-to-point addressed traffic is encrypted
with the master key.
-
encryption mode 3, all traffic is encrypted with the
master key.
As the encryption key size can vary from 8 to 128 bits, the size of
the encryption key used between the two devices must be negotiated, with
either device (master and slave) proposing , or rejecting each other’s
key size suggestion.
Some boundaries are placed on the negotiation though. In each device,
there is a parameter defining the maximum allowed key length. Also in
every application there is a defined minimum acceptable key size, and if
this min key size requirement is not met by either of the participants
in the (encryption) key size negotiation , then the application aborts
the negotiation and the encryption cannot be used. This is required due
to the possibility that a malicious device could force a lower
encryption setting to do harm.
References:
Bluetooth, The Bluetooth Specification, v.1.0B http://www.bluetooth.com/dev/specifications.asp
Müller T., Bluetooth Security Architecture, 1999-07-15
http://www.bluetooth.com/developer/download/download.asp?doc=174
Vainio J., Bluetooth Security, 2000-05-25
http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
InfoTooth Knowledge Base
http://www.palowireless.com/infotooth/knowbase.asp
Träskbäck M, Security in Bluetooth: An overview of Bluetooth
security, 2000-11-2
http://www.cs.hut.fi/Opinnot/Tik-86.174/Bluetooth_Security.pdf
Ullgren T. Security in Bluetooth: Key management in Bluetooth
http://www.cs.hut.fi/Opinnot/Tik-86.174/sectopics.html
