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
Formed of up to 10 Piconets.

Device Architectural Overview
Mapping of Bluetooth Overview to
IEEE 7-layer model (thanks to IEEE)
June 1999
doc.: IEEE 802.15-99/014r8
Bluetooth and IEEE Structure
7 Application
X.400 and X.500 EMAIL
6 Presentation
Bluetooth
Submission
5
Session
4
Transport
3
Network
2
Data Link
1
Physical
ISO OSI
Layers
Slide 13
Transport Control Protocol (TCP)
Internet Protocol (IP)
Logical Link Control
(LLC)
Medium Access Layer
(MAC)
Physical Layer
(PHY)
Hardware
Software
IEEE 802
Standards
Tom Siep, Texas Instruments
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 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’
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

1.
2.

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-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/Bluetooth
_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 initialization keyPairing
2)
Authentication
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
XOR
Decrypted Word
Data Word
Linear-Feedback
Shift Register
Encrypted Word
Encryption in detail.


1.
2.
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




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-securitycritical 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.ht
m#Bluetooth
http://www.geocities.com has links to bluetooth tutorials