Bluetooth SecurityHow 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 ThreatsDisclosure 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 TraditionalSecurity

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)

J u n e 1 99 9

T om S iep , T exas Ins trum e ntsS lide 13

d oc .: IE E E 8 02 .15 -9 9 /01 4r8

S ubm iss ion

B luetoo th and IE E E S truc tu re

B lu e to o th

Physica l Layer(PH Y)

Med ium Access Layer(M AC)

Logica l Link C on tro l(LLC)

Phys ica l

Da ta L ink

N e twork

Transport

S ession

P resen ta t ion

App lica tion7

6

5

4

3

2

1

IS O O S IL a ye rs

IE E E 8 0 2S ta n d a rd s

Hardw are

Softw are

Transport Contro l P rotoco l (TC P)

In te rnet Pro toco l (IP )

X .400 and X .500 E M AIL

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 securitySecurity 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 key2) Authentication 3) Generation of link key4) Link key exchange5) 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: claimantBasically 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

RANDA 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-FeedbackShift Register

Data Word

Encrypted Word

XOR

Linear-FeedbackShift 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_Specifications_Book.pdf

Träskbäck M, Security in Bluetooth: An overview of Bluetooth security, 2000-11-2http://www.cs.hut.fi/Opinnot/Tik86.174/Bluetooth_Security.pdf

Vainio J., Bluetooth Security, 2000-05-25http://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.asphttp://www.palowireless.com/bluearticles/cc2_security2.asphttp://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