Bluetooth Security

slurpslapoutΔίκτυα και Επικοινωνίες

20 Νοε 2013 (πριν από 3 χρόνια και 6 μήνες)

64 εμφανίσεις

Bluetooth Security

How security is implemented for
services running on Bluetooth
devices, and future security issues
for this technology

By Scott Anson


Security terminology.

Overview of the architecture pertaining
to security.

Description of the various modes of
security available.

Closer look at link
level security

Issues with Bluetooth security.

Security Threats

Disclosure Threat:
leaking of
information from a system to an
unwanted party. Confidentiality

Integrity Threat:
changes of information during

Denial of Service Threat:
blocked by malicious attacker.
Availablity violation.


: process of
determining the identity of another

: process of deciding if
device A has the access rights to
device B. Notion of “trusted”

Symmetric Key Security:

A trusts B if B can prove that it has
the same shared key that A does.

Wireless Versus Traditional


There is no centralized, trusted
third party for a wireless network

User Authentication becomes

Authentication must go across a
network without being cracked

Device uniqueness: low battery
denial of service attacks!

Bluetooth Overview

Ad Hoc Networks of Multiple Types of
Devices: PDAs, Laptops, Mobile Phones

: Small Clusters (Max Size
8) of Devices Forming an Ad Hoc
Network. Masters Determine the
Frequency. Piconet Example: Transfer
of Files Between Participants at a

: Larger Networks
Formed of up to 10 Piconets.

Device Architectural Overview

Mapping of Bluetooth Overview to
layer model (thanks to IEEE)

June 1999
Tom Siep, Texas Instruments
doc.: IEEE 802.15
Bluetooth and IEEE Structure
Physical Layer
Medium Access Layer
Logical Link Control
Data Link
IEEE 802
Transport Control Protocol (TCP)
Internet Protocol (IP)
X.400 and X.500 EMAIL
Link Manager: the DataLink layer

Link Manager’s involvement with
security depends on Bluetooth security
mode: only the strictest setting requires
that data link implement security.

Security for pairing, authentication and
encryption is implemented by both
software and hardware at this layer.

We will later look at the specifics.

Transport/ Session Layer


enforces the security policy for
up networking and other services relying
on a serial port. Supports emulation of
multiple serial ports between two devices.
Session Layer.


Logical Link and Adaption Protocol.
Manages the creation and termination of
virtual connections called
other devices. Negotiates and dictates
security parameters for channel
establishment. Network/Transport Layer

Security Manager

A service and a device data store

Answers access requests by protocol
implementations (e.g. L2CAPP) or
higher layers: R2COMM, applications.

Enforces authentication and
encryption if they are needed before
connecting to application

Initiates setting up “trusted” pairings
and gets PIN codes from users, saves
addresses of other devices.

Multiple Security Modes

Mode 1
: No security other than
against “casual eavesdroppers”

Mode 2
: Service Level Security:
established after creating the
channel, above datalink layer.

Mode 3
: Datalink Level Security:
security initiated before establishing
channel, by the Link Manager, as
well as by the Service Level.

Security Mode determines what stage
of connection does security

Communication from 60,000’


A device in a new environment will
automatically initiate an inquiry to discover what
access points are within its range. This will result in
the following events:

i.) All nearby access points respond with their

ii.) The device picks one out the responding devices.

a baseband procedure invoked by a
device which results in synchronization of the
device with the access point, in terms of its clock
offset and phase in the frequency hop, among
other required initializations. (see spec for details

master/slave issues here).

60,000 foot view continued…

3.) Link establishment:

The LMP will now
establish a link with the access point. If Security
Mode 3, then
Pairing (6)
begins at this layer.

4.) Service Discovery:

The LMP will use the
SDP(Service Discovery Protocol) to discover what
services are available.

5.) L2CAP channel created:

With information
obtained from SDP, a L2CAP channel is created.
This may be directly used by the application or by
another protocol (e.g. RFCOMM)

6.) Pairing

begins here if in Security Mode 2.

Pairing, the 60000’ view of security

Security Manager of access point is consulted:

checks security mode and service security
policy, if security is required, the access point
transmits a security request for “

pairing is only successful if the user knows the
pin of the access point

the PIN is not transmitted over the wireless
channel but another key generated from it is
used, so that the PIN is not compromised.

Encryption will be invoked if secure mode is

Device Security Levels

Trust level of the device determines which
services that device has access to.

Trusted Device
: The device has been
previously authenticated, a link key is stored
and the device is marked as "trusted" in the
Device Database.

Untrusted Device
: The device has been
previously authenticated, a link key is stored
but the device is not marked as "trusted" in
the Device Database

Unknown Device
: No security information is
available for this device, e.g.

Mode 1: No Security

Only security at this level is by the nature of the
connection: data
hopping and short

Bluetooth devices transmit over the unlicensed
2.45GHz radio band, the same band used by

microwave ovens and cordless phones.(FHSS)

All Bluetooth devices employ “data
hopping”, which
entails skipping around the radio band up to 1600
times per second, at 1MHz intervals (79 different

Most connections are less than 10 meters, so there is
a limit as to eavesdropping possibilities

Mode 2: Service Level Security

Service Access depends on device:

Trusted devices have unrestricted access to all
services, fixed relationship to other devices

Untrusted devices generally have no permanent
relationship and services that it has access to
are limited.

Unfortunately, all services on a device
are given the same security policy,
other than application layer add

Mode 2 Service Security Levels

Services can have one of 3 security

Level 3:

Requires Authentication and
Authorization. PIN number must be

Level 2:

Authentication only, fixed PIN

Level 1:
Open to all devices, the default
level. Security for legacy applications,
for example.

Mode 3: Link level security

Security is implemented by symmetric
keys in a challenge
response system.

Security implementations in Bluetooth
units are all the same, and are publicly

Critical ingredients:PIN, BD_ADDR,
RAND(), Link and Encryption Keys

Security Entities

: up to 128 bit number, can be
fixed (entered in only one device), or
can be entered in both devices. If
fixed, much lower security.

: Bluetooth device address,
unique 48 bit sequence. (IEEE).
Devices must know the address of
devices it wants to communicate with.
Addresses are publicly available via
Bluetooth inquiries.

level entities continued…

Private Authentication Keys, or
Link Keys
bit random numbers used for
authentication purposes. Paired devices
share a link key.

Private Encryption Key
: varying length key
128 bits), regenerated for each
transmission from link key

: frequently changing 128
bit random
number generated by the device (in
software). Common input for key generation.

All Bluetooth devices have this random
number generator.


Needed before two secure devices can
communicate. 5 parts:

Generation of initialization key


Generation of link key

Link key exchange

Generation of encryption key in both

Conclusion: link is either built or aborted


Generation of initialization key

Initialization key generation only occurs when
two devices have not yet communicated

Highest security demands PIN be entered by
both users. Two devices with fixed pins
cannot talk securely (mode 3).

This key used to secure the process of
generating a shared link key between the

Initialization key creation cont.

F( PIN, sizeof( PIN), RAND, BD_ADDR)
produces 128 bit initialization key via shifting
and xors (Linear feedback shift registers,
whose output is combined by a state

Device A and B now share the initialization
key, which they use as their temporary link
key while deciding on what kind of link key
they will use for data transmission.

This key is discarded once they agree on a
link key.


Does not always need to be mutual,
specified by app

If it is mutual, then both act as verifiers,
one after the other

Device A: verifier

Device B: claimant

Basically determines if both have same
shared key (ACO generated at this time
as well for encryption)

Authentication continued…

A issues challenge c to B, generated by its

A and B both run the RAND thru same function:

E1(c, BD_ADDR of B, current link key)

B sends its response to A, who checks to see
that they match. If failure, start exponential
waiting with a limit set on number of possible

On success, the BD_ADDR of other device is
stored in the Device Database by the Service

Generation of Link Key

Unit key does not change, it was made
when device was installed.

Application decides which device will
provide its unit key as a link key (favors
the device with less memory).

Shared initialization key is used to protect
the transaction: it is XORed with the new
link key.

Link Key Exchange

After the unit key is stored on the other
device, the initialization key is discarded.

Higher security: combination key is used
rather than the unit key, and this is formed
by F( unit key, RAND, BD_ADDR) on both A
and B.

slave communications use Master link
key. A slave gets a master link key when first
connected to Master and then changes it
when prompted by Master


Encryption requires an authenticated
link with an established link key

Devices must agree on an encryption
key to communicate.

Packet payloads are encrypted (not the
packet headers or access codes).

Devices negotiate on what size
Encryption key they need, typically
around 64 bits. Range is 1
16 bytes.

Encryption Modes

Encryption Mode depends on the shared key:

If unit or combination key, then point
traffic is not encrypted. Individual traffic may or may
not be encrypted (app specific)

If a master key is used, there are three possible

Mode 1, nothing is encrypted.

Mode 2, broadcast traffic is not encrypted, but the
individually addressed traffic is encrypted with the
master key.

Mode 3, all traffic is encrypted with the master key.

Encryption Implementation

Encryption of payloads is effected with
a stream cipher called E0 that is
resynchronized for every payload

A Software implementation is linked
from references section.

E0 consists of three parts:

The initializer (generates the payload key)

The key stream bits generator

The encryption or decryption circuit

Simplified Encryption Circuitry



Shift Register

Data Word

Encrypted Word



Shift Register

Encrypted Word

Decrypted Word

Encryption in detail.

Key = E3( COF, RAND, LinkKey). Variable
size design due to internationalization issues

COF: Ciphering Offset Number, determined
by type of link key:

Combination/Unit Link Key: equal to ACU
from initialization This was obtained during
the initialization key generation process and
saved in the Security Manager.

Master Link Key: Concatenation of the
master BD_ADDR and the slave BD_ADDR

Wrap up: Bluetooth Keys

Encryption Key
is not a Link Key but is derived
from either the Unit, Combination, or Master Key.
Can be shorter than the 128
bit link keys.

4 Link Keys:

Ki : initialization key
, protects initialization
parameters. Formed from combo of RAND, PIN, and
BD_ADDR. This is discarded after channel
establishment, at which point the others are used.

Kab: combination key
, derived from paired devices
when additional security needed. Memory? Device
that has the most has to store the combo key.

Link Key wrap
up continued

unit key
, generated in installation of a device,
stored in nonvolatile memory. Unit and combo keys
generated with the same function, different inputs.

Unit Key cannot change!

If it does, then the entire
piconet is compromised and must be re

Km: master key
, used when the master device
wants to transmit to multiple devices at once.
Overrides current link keys for one session.

Master Key is the most typical link key, but for
scatternet communication (multiple masters), the
unit key or combination key is always used.

General Problems

Device versus User authentication. Bluetooth
authenticates devices, not users. This is not
always appropriate. Depends on app

Device versus Service specific security. You
must implement the same security policy
(mode) on all services on the device.

Dependence on addresses, shared keys.
Fixed PINs also pose a problem.

General problems continued

Legacy applications do not use the
Service Manager (need adapter kits).

Cannot enforce unidirectional traffic

Once connection established, assumed
permanently secure. (unless called by
Master to renegotiate, which rarely
occurs in most implementations.)

Specific Problems

PIN number is the only truly secret key, and this is
up to the user. 0000 is not good! Solution: force
longer pins, combo of entered pin and stored pin

Battery draining denial of service attack!

Spoofing due to shared keys: A talks to B, over.
Then A talks to C. Now B can masquerade as A to C
by faking A’s device address, and can then lay off
and eavesdrop.

Privacy issues? Device’s unique address is associated
with a user.


Inadequate for serious security: money
transfers. Better: WLAN

Additional security must be added at
the higher layers. This keeps Bluetooth
an economical solution to non
critical interactions.

Most hackers don’t want to sit nearby.
Bluetooth works great for PANs.

Security By Obscursion! Not elegant.



Träskbäck M, Security in Bluetooth: An overview of
Bluetooth security, 2000

Vainio J., Bluetooth Security, 2000

Knowledge Base on Bluetooth:

References continued…

Cathal McDaid:

Saarinen M
J, A Software Implementation of the BlueTooth
Encryption Algorithm E0;

tutorials on both Bluetooth Overview and Close up
on Bluetooth Security

Other bluetooth links:

has links to bluetooth tutorials