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.
Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.
How security is implemented for services running on Bluetooth devices, and future security issues for this technology
By Scott Anson
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.
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.
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.
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
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).
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.
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.
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
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.
Needed before two secure devices can communicate. 5 parts:
Conclusion: link is either built or aborted
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)
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.
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:
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
Other bluetooth links: http://www.practicallynetworked.com/tools/wireless_articles.htm#Bluetooth
http://www.geocities.com has links to bluetooth tutorials