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 loo at lin !level security "ssues with Bluetooth security.

Security #hreats
Disclosure Threat: lea ing of information from a system to an unwanted party. Confidentiality violation. Integrity Threat: unauthori$ed changes of information during transmission. Denial of Service Threat: resources bloc ed by malicious attac er. Availablity violation.

#erms

Authentication% process of determining the identity of another user. Authorization% process of deciding if device A has the access rights to device B. &otion of 'trusted( Symmetric Key Security: generally, A trusts B if B can prove that it has the same shared ey that A does.

)ireless *ersus #raditional Security

#here is no centrali$ed, trusted third party for a wireless networ +ser Authentication becomes harder Authentication must go across a networ without being crac ed Device uni,ueness% low battery

Bluetooth Overview
Ad Hoc &etwor s of .ultiple #ypes of Devices% /DAs, 0aptops, .obile /hones

Piconets% Small Clusters 1.a2 Si$e 34 of Devices 5orming an Ad Hoc &etwor . .asters Determine the 5re,uency. /iconet 62ample% #ransfer of 5iles Between /articipants at a .eeting.

Scatternets% 0arger &etwor s

Device Architectural Overview

.apping of Bluetooth Overview to "666 9!layer model 1than s to "6664

June 1999 doc.: IEEE 802.15-99/014r8

Bluetooth and IEEE Structure

# $ % & ' ( ) B lu e to o th
A ! ! lic a t io n P re s e n ta t io n " e s s io n ra n s ! o rt N e tw o r k T r a n s p o r t C o n t r o l P ro t o c o l (T C P ) In te r n e t P r o to c o l ( IP ) L o g ic a l L in k C o n tro l (L L C ) M e d iu m A c c e s s L a y e r (M A C ) P h y s ic a l L a y e r (P H Y ) X .4 0 0 a n d X . 5 0 0 E M A IL

D a t a L in k

H a rd w a re S o ftw a re

P h y s ic a l

*" + + " * L a y e rs
Slide 13

*, , , - . ( " ta n d a rd s
Tom Siep, Texas Instruments

Submission

0in .anager% the Data0in layer

0in .anager:s involvement with security depends on Bluetooth security mode% only the strictest setting re,uires that data lin implement security. Security for pairing, authentication and encryption is implemented by both software and hardware at this layer. )e will later loo at the specifics.

#ransport; Session 0ayer

RFCO : enforces the security policy for dial!up networ ing and other services relying on a serial port. Supports emulation of multiple serial ports between two devices. Session 0ayer. !"CAPP: 0ogical 0in and Adaption /rotocol. .anages the creation and termination of virtual connections called channels with other devices. &egotiates and dictates security parameters for channel establishment. &etwor ;#ransport 0ayer

Security .anager
A service and a device data store Answers access re,uests by protocol implementations 1e.g. 0<CA//4 or higher layers% =<CO.., applications. 6nforces authentication and encryption if they are needed before connecting to application "nitiates setting up 'trusted( pairings and gets /"& codes from users, saves addresses of other

.ultiple Security .odes

o#e $% &o security other than against 'casual eavesdroppers( o#e "% Service 0evel Security% established after creating the channel, above datalin layer. o#e %% Datalin 0evel Security% security initiated before establishing channel, by the 0in .anager, as well as by

Communication from >8,888:

$&' In(uiry: A device in a new environment will automatically initiate an in,uiry to discover what access points are within its range. #his will result in the following events% i.4 All nearby access points respond with their addresses. ii.4 #he device pic s one out the responding devices.

"&4 Paging% a baseband procedure invo ed by

a device which results in synchroni$ation of the device with the access point, in terms of its cloc offset and phase in the fre,uency hop, among other re,uired initiali$ations. 1see spec for details?master;slave issues here4.

>8,888 foot view continued@

%&' !in) esta*lishment: #he 0./ will now
establish a lin with the access point. "f Security .ode A, then Pairing +,' begins at this layer.

-&' Service Discovery: #he 0./ will use

the SD/1Service Discovery /rotocol4 to discover what services are available.

.&' !"CAP channel create#: )ith

information obtained from SD/, a 0<CA/ channel is created. #his may be directly used by the application or by another protocol 1e.g. =5CO..4

,&' Pairing begins here if in Security

/airing, the >8888: view of security

Security .anager of access point is consulted% !!chec s security mode and service security policy, if security is re,uired, the access point transmits a security re,uest for '/airing0 !!pairing is only successful if the user nows the pin of the access point !!the /"& is not transmitted over the wireless channel but another ey generated from it is used, so that the /"& is not compromised.

Device Security 0evels

Tr st le!el of t"e de!#ce deter$#nes w"#c" ser!#ces t"at de!#ce "as access to. Tr sted %e!#ce/ he de0ice has 1een !re0iously authenticated2 a link key is stored and the de0ice is marked as 3trusted3 in the De0ice Data1ase4 &ntr sted %e!#ce/ he de0ice has 1een !re0iously authenticated2 a link key is stored 1ut the de0ice is not marked as 3trusted3 in the De0ice Data1ase &n'nown %e!#ce/ No security in5ormation is a0aila1le 5or this de0ice2 e4g4 ntr sted

.ode 7% &o Security

Only security at this level is by the nature of the connection% data!hopping and short! distance Bluetooth devices transmit over the unlicensed <.BCDH$ radio band, the same band used by microwave ovens and cordless phones.15HSS4 All Bluetooth devices employ 'data!hopping(, which entails s ipping around the radio band up to 7>88 times per second, at 7.H$ intervals 19E different fre,uencies4 .ost connections are less than 78 meters, so there is a limit as to eavesdropping possibilities

.ode <% Service 0evel Security

Service Access depends on device%

#rusted devices have unrestricted access to all services, fi2ed relationship to other devices +ntrusted devices generally have no permanent relationship and services that it has access to are limited.

7.

<.

+nfortunately, all services on a device are given the same security policy, other than

.ode < Service Security 0evels

Services can have one of A security levels%

!evel %: =e,uires Authentication and Authori$ation. /"& number must be entered. !evel ": Authentication only, fi2ed /"& o . !evel $: Open to all devices, the default level. Security for legacy applications, for e2ample.

.ode A% 0in level security

Security is implemented by symmetric eys in a challenge! response system. Security implementations in Bluetooth units are all the same, and are publicly available% http%;;www.bluetooth.com;pdf;Bluetoot

Critical ingredients%/"&, BDFADD=, =A&D14, 0in and 6ncryption Geys

Security 6ntities

PI1% up to 7<3 bit number, can be fi2ed 1entered in only one device4, or can be entered in both devices. "f fi2ed, much lower security. 2D3ADDR% Bluetooth device address, uni,ue B3 bit se,uence. 1"6664. Devices must now the address of devices it wants to communicate with. Addresses are publicly available via Bluetooth in,uiries.

0in !level entities continued@

/rivate Authentication Geys, or !in) Keys% 7<3!bit random numbers used for authentication purposes. /aired devices share a lin ey. Private 4ncry/tion Key% varying length ey 13!7<3 bits4, regenerated for each transmission from lin ey RA1D% fre,uently changing 7<3!bit random number generated by the device 1in software4. Common input for ey generation. All Bluetooth devices have this random number generator.

"nitiali$ation
&eeded before two secure devices can communicate. C parts% 74 Deneration of initiali$ation/airin ey <4 Authentication g A4 Deneration of lin ey B4 0in ey e2change C4 Deneration of encryption ey in both devices. Conclusion% lin is either built or aborted

Deneration of initiali$ation ey

"nitiali$ation ey generation only occurs when two devices have not yet communicated before. Highest security demands /"& be entered by both users. #wo devices with fi2ed pins cannot tal securely 1mode A4. #his ey used to secure the process of generating a shared lin ey between the devices.

"nitiali$ation ey creation cont.

51 /"&, si$eof1 /"&4, =A&D, BDFADD=4 produces 7<3 bit initiali$ation ey via shifting and 2ors 10inear feedbac shift registers, whose output is combined by a state machine4 Device A and B now share the initiali$ation ey, which they use as their temporary lin ey while deciding on what ind of lin ey they will use for data transmission. #his ey is discarded once they agree on a lin ey.

Authentication
Does not always need to be mutual, specified by app "f 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 ey 1ACO generated at this time as well for encryption4

Authentication continued@
A issues challenge c to B, generated by its =A&D A and B both run the =A&D thru same function% 671c, BDFADD= of B, current lin ey4 B sends its response to A, who chec s to see that they match. "f failure, start e2ponential waiting with a limit set on number of possible attempts. On success, the BDFADD= of other device is stored in the Device Database by the Service .anager.

Deneration of 0in Gey

+nit ey does not change, it was made when device was installed. Application decides which device will provide its unit ey as a lin ey 1favors the device with less memory4. Shared initiali$ation ey is used to protect the transaction% it is HO=ed with the new lin ey.

0in Gey 62change

After the unit ey is stored on the other device, the initiali$ation ey is discarded. Higher security% combination ey is used rather than the unit ey, and this is formed by 51 unit ey, =A&D, BDFADD=4 on both A and B. .aster!slave communications use .aster lin ey. A slave gets a master lin ey when first connected to .aster and then changes it when prompted by

6ncryption

6ncryption re,uires an authenticated lin with an established lin ey Devices must agree on an encryption ey to communicate. /ac et payloads are encrypted 1not the pac et headers or access codes4. Devices negotiate on what si$e 6ncryption ey they need, typically around >B bits. =ange is 7!7>

6ncryption .odes

6ncryption .ode depends on the shared ey% "f unit or combination ey, then point!to! multipoint traffic is not encrypted. "ndividual traffic may or may not be encrypted 1app specific4 "f a master ey is used, there are three possible modes% .ode 7, nothing is encrypted. .ode <, broadcast traffic is not encrypted, but the individually addressed traffic is encrypted with the master ey. .ode A, all traffic is encrypted with the master ey.

6ncryption "mplementation

6ncryption of payloads is effected with a stream cipher called 68 that is resynchroni$ed for every payload A "o5tware im!lementation is linked 5rom re5erences section4 68 consists of three parts%

#he initiali$er 1generates the payload ey4 #he ey stream bits generator

Simplified 6ncryption Circuitry

Linear-Feedback Shift Register XOR Data Word Encrypted Word

Linear-Feedback Shift Register XOR Encrypted Word Decrypted Word

6ncryption in detail.

7.

<.

Gey I 6A1 CO5, =A&D, 0in Gey4. *ariable si$e design due to internationali$ation issues CO5% Ciphering Offset &umber, determined by type of lin ey% Combination;+nit 0in Gey% e,ual to AC+ from initiali$ation #his was obtained during the initiali$ation ey generation process and saved in the Security .anager. .aster 0in Gey% Concatenation of the master BDFADD= and the slave

)rap up% Bluetooth Geys

4ncry/tion Key is not a 0in Gey but is derived from either the +nit, Combination, or .aster Gey. Can be shorter than the 7<3!bit lin eys. - !in) Keys: Ki : initialization )ey, protects initiali$ation parameters. 5ormed from combo of =A&D, /"&, and BDFADD=. #his is discarded after channel establishment, at which point the others are used. Ka*: com*ination )ey, derived from paired devices when additional security needed.

0in Gey wrap!up continued

Ku: n#t 'e(2 generated in installation o5 a de0ice2 stored in non0olatile memory4 6nit and com1o keys generated with the same 5unction2 di55erent in!uts4 &n#t )e( cannot c"an*e+ *5 it does2 then the entire !iconet is com!romised and must 1e re7initiali8ed Km: master )ey, used when the master device wants to transmit to multiple devices at once. Overrides current lin eys for one session. .aster Gey is the most typical lin ey, but for scatternet communication 1multiple masters4, the unit ey or combination ey is always used.

Deneral /roblems

Device versus +ser authentication. Bluetooth authenticates devices, not users. #his is not always appropriate. Depends on app!specific fi2es. Device versus Service specific security. Kou must implement the same security policy 1mode4 on all services on the device. Dependence on addresses, shared eys. 5i2ed /"&s also pose a problem.

Deneral problems continued

0egacy applications do not use the Service .anager 1need adapter its4. Cannot enforce unidirectional traffic Once connection established, assumed permanently secure. 1unless called by .aster to renegotiate, which rarely occurs in

Specific /roblems

/"& number is the only truly secret ey, and this is up to the user. 8888 is not goodSolution% force longer pins, combo of entered pin and stored pin Battery draining denial of service attac Spoofing due to shared eys% A tal s to B, over. #hen A tal s to C. &ow B can mas,uerade as A to C by fa ing A:s device address, and can then lay off and eavesdrop. /rivacy issuesJ Device:s uni,ue address is associated with a user.

Conclusions

"nade,uate for serious security% money transfers. Better% )0A& Additional security must be added at the higher layers. #his eeps Bluetooth an economical solution to non!security!critical interactions. .ost hac ers don:t want to sit nearby. Bluetooth wor s great for /A&s. Security By Obscursion- &ot

=eferences

H, "P,C/ htt!/99www41luetooth4com9!d59Bluetooth:)):"!eci5ica tions:Book4!d5 r;sk1;ck M2 "ecurity in Bluetooth/ An o0er0iew o5 Bluetooth security2 (...7))7( htt!/99www4cs4hut45i9+!innot9 ik-$4)#&9Bluetooth:"ecuri
<ainio =42 Bluetooth "ecurity2 (...7.%7(% htt!/99www4niksula4cs4hut45i9>?iit091luesec4html @nowledge Base on Bluetooth/ htt!/99www4!alowireless4com9in5otooth9know1ase4as!

=eferences continued@
Cathal .cDaid% http%;;www.palowireless.com;bluearticles;cc7Fsecurity7.as p http%;;www.palowireless.com;bluearticles;cc<Fsecurity<.as p http%;;www.palowireless.com;bluearticles;cc<FsecurityA.asp Saarinen .!L, A Software "mplementation of the Blue#ooth 6ncryption Algorithm 68M http%;;www.cc.Nyu.fi;OmNos ;e8.c www.2ilin2.com tutorials on both Bluetooth Overview and Close up on Bluetooth Security www41luetooth4com Other bluetooth lin s% http%;;www.practicallynetwor ed .com;tools;wirelessFarticles.htmPBluetooth http%;;www.geocities.com has lin s to bluetooth tutorials