Académique Documents
Professionnel Documents
Culture Documents
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.
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.
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: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.
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
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
7.
<.
+nfortunately, all services on a device are given the same security policy, other than
!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.
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
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.
/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.
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.
+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.
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
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
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.
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.
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