Bluetooth Security

1. Bluetooth Security How security is implemented for services running on Bluetooth devices, and future security issues for this technology By Scott Anson

2. 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.

3. 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.

4. 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.

5. 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!

6. 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.

7. Device Architectural Overview

8. Mapping of Bluetooth Overview to IEEE 7-layer model (thanks to IEEE)

9. 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.

10. 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

11. 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.

12. 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

13. 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).

14. 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.

15. 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.

16. 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

17. 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 bymicrowave 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

18. Mode 2: Service Level Security • Service Access depends on device: • Trusted devices have unrestricted access to all services, fixed relationship to other devices • 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.

19. 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.

20. 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

21. 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.

22. 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.

23. Initialization Needed before two secure devices can communicate. 5 parts: • Generation of initialization key • Authentication • Generation of link key • Link key exchange • Generation of encryption key in both devices. Conclusion: link is either built or aborted Pairing

24. 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.

25. 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.

26. 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)

27. 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.

28. 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.

29. 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

30. 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.

31. 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.

32. 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

33. Simplified Encryption Circuitry Linear-Feedback Shift Register XOR Encrypted Word Data Word Linear-Feedback Shift Register XOR Decrypted Word Encrypted Word

34. 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: • Combination/Unit Link Key: equal to ACU from initialization This was obtained during the initialization key generation process and saved in the Security Manager. • Master Link Key: Concatenation of the master BD_ADDR and the slave BD_ADDR

35. 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.

36. 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.

37. 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.

38. 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.)

39. 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.

40. 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.

41. 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

42. 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.htm#Bluetooth http://www.geocities.com has links to bluetooth tutorials