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
June 1999 doc.: IEEE 802.15-99/014r8

Bluetooth and IEEE Structure

7 Application X.400 and X.500 EMAIL

6 Presentation

5 Session

4 Transport Transport Control Protocol (TCP)

3 Network Internet Protocol (IP)

Logical Link Control

(LLC) Hardware
2 Data Link
Medium Access Layer
(MAC)
Software
Physical Layer
1 Physical
(PHY)

Bluetooth ISO OSI IEEE 802

Layers Standards

Submission Slide 13 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.
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: RFCOMM, 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.
Communication in the range
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
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 and Range 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,

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 Pairing
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
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. Device that has the
most Memory 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.