Bluetooth Security

slurpslapoutNetworking and Communications

Nov 20, 2013 (3 years and 7 months ago)

67 views

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
Tom Siep, Texas Instruments
Slide
13
doc.: IEEE 802.15
-
99/014r8
Submission
Bluetooth and IEEE Structure
Bluetooth
Physical Layer
(PHY)
Medium Access Layer
(MAC)
Logical Link Control
(LLC)
Physical
Data Link
Network
Transport
Session
Presentation
Application
7
6
5
4
3
2
1
ISO OSI
Layers
IEEE 802
Standards
Hardware
Software
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


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


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/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 key

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


Pairing

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

XOR

Linear
-
Feedback

Shift Register

Data Word

Encrypted Word

XOR

Linear
-
Feedback

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:

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.ht
m#Bluetooth


http://www.geocities.com

has links to bluetooth tutorials