Bluetooth Security

How security is implemented

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

By Scott Anson
Agenda
 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
violation.
Integrity Threat: unauthorized
changes of information during
transmission.
Denial of Service Threat:
resources blocked by malicious
attacker. Availablity violation.
Terms
 Authentication: process of
determining the identity of another
user.
 Authorization: process of deciding
if device A has the access rights to
device B. Notion of “trusted”
 Symmetric Key Security:
generally, A trusts B if B can prove
that it has the same shared key
that A does.
Wireless Versus Traditional
Security
 There is no centralized, trusted
third party for a wireless network
 User Authentication becomes

harder
 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

 Piconets: 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 Meeting.

 Scatternets: Larger Networks

Device Architectural
Overview
Mapping of Bluetooth Overview
to IEEE 7-layer model (thanks to
IEEE)
June 1999 d o c .: IE E E 8 0 2 .1 5 -9 9 /0 1 4 r 8

B lu e to o th a n d IE E E S tru c tu re
7 A p p lic a tio n X .4 0 0 a n d X .50 0 E M A IL

6 P re s en ta tio n

5 S es sion

4 T ra ns p ort T ra n s p o rt C o n tro l P ro to c o l (T C P )

3 N e tw o rk In te rn e t P ro to c o l (IP )

L o gica l Link C on tro l

(L L C ) H a rd w a re
2 D a ta L in k
M e d iu m A c c es s L ay e r
(M A C )
S o ftw a re
P h ysica l La ye r
1 P h ys ica l
(P H Y )

B lu e to o th IS O O S I IE E E 8 0 2
L a y e rs S ta n d a rd s

S u b m is sio n S lid e 1 3 T om S iep , T ex as Instru m e nts

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
 RFCOMM: enforces the security policy for
dial-up networking and other services
relying on a serial port. Supports
emulation of multiple serial ports between
two devices. Session Layer.
 L2CAPP: Logical Link and Adaption
Protocol. Manages the creation and
termination of virtual connections called
channels with 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
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
Communication from 60,000’
1.) Inquiry: 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
addresses.
ii.) The device picks one out the responding
devices.
2.) Paging: 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”
--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
used.
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. untrusted

Mode 1: No Security
 Only security at this level is by the nature of the
connection: data-hopping and short-distance
 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 frequencies)
 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:
1. Trusted devices have unrestricted access to
all services, fixed relationship to other
devices
2. 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-ons.
Mode 2 Service Security
Levels
 Services can have one of 3
security levels:
Level 3: Requires Authentication
and Authorization. PIN number
must be entered.
Level 2: Authentication only, fixed
PIN ok.
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 available:
http://www.bluetooth.com/pdf/Blueto
oth_11_Specifications_Book.pdf
 Critical ingredients:PIN,
BD_ADDR, RAND(), Link and
Encryption Keys
Security Entities
 PIN: 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.
 BD_ADDR: 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.
Link-level entities
continued…
 Private Authentication Keys, or Link Keys:
128-bit random numbers used for
authentication purposes. Paired devices
share a link key.
 Private Encryption Key: varying length
key (8-128 bits), regenerated for each
transmission from link key
 RAND: 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.
Initialization

Needed before two secure devices can

communicate. 5 parts:
1) Generation of initializationPairin
key
2) Authentication g
3) Generation of link key
4) Link key exchange
5) Generation of encryption key in both
devices.
Conclusion: link is either built or aborted
Generation of initialization
key
 Initialization key generation only occurs
when two devices have not yet
communicated before.
 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
devices.
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 machine)
 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.
Authentication

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
RAND
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 attempts.
On success, the BD_ADDR of other device
is stored in the Device Database by the
Service Manager.
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.
 Master-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
 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-to-
multipoint traffic is not encrypted. Individual
traffic may or may not be encrypted (app specific)
 If a master key is used, there are three possible
modes:
 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
Linear-Feedback
Shift Register
XOR Encrypted Word

Data Word

Linear-Feedback
Shift Register
XOR Decrypted Word

Encrypted 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:
1. Combination/Unit Link Key: equal to ACU
from initialization This was obtained
during the initialization key generation
process and saved in the Security
Manager.
2. 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
 Ku: 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-initialized
 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-specific fixes.
 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.
Conclusions
 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-security-critical interactions.
 Most hackers don’t want to sit
nearby. Bluetooth works great for
PANs.
 Security By Obscursion! Not elegant.
References
THE SPEC:
http://www.bluetooth.com/pdf/Bluetooth_11_Specifica
tions_Book.pdf
Träskbäck M, Security in Bluetooth: An overview of
Bluetooth security, 2000-11-2
http://www.cs.hut.fi/Opinnot/Tik86.174/Bluetooth_Sec
urity.pdf
Vainio J., Bluetooth Security, 2000-05-25
http://www.niksula.cs.hut.fi/~jiitv/bluesec.html
Knowledge Base on Bluetooth:
http://www.palowireless.com/infotooth/knowbase.asp
References continued…
Cathal McDaid:
http://www.palowireless.com/bluearticles/cc1_security1.asp
http://www.palowireless.com/bluearticles/cc2_security2.asp
http://www.palowireless.com/bluearticles/cc2_security3.asp
Saarinen M-J, A Software Implementation of the BlueTooth
Encryption Algorithm E0; http://www.cc.jyu.fi/~mjos/e0.c
www.xilinx.com tutorials on both Bluetooth Overview and
Close up on Bluetooth Security
www.bluetooth.com
Other bluetooth links: http://www.practicallynetworked
.com/tools/wireless_articles.htm#Bluetooth
http://www.geocities.com has links to bluetooth tutorials