- •Contents
- •Preface
- •1 Introduction
- •1.1 Bluetooth system basics
- •1.1.1 Background
- •1.1.2 Trade-offs
- •1.1.3 Bluetooth protocol stack
- •1.1.4 Physical layer
- •1.1.5 Baseband
- •1.1.6 Link manager protocol
- •1.1.7 Logical link control and adaptation protocol
- •1.1.8 Host control interface
- •1.1.9 Profiles
- •1.2 Bluetooth security basics
- •1.2.1 User scenarios
- •1.2.2 Notions and terminology
- •References
- •2.1 Key types
- •2.2 Pairing and user interaction
- •2.3 Authentication
- •2.4 Link privacy
- •2.4.1 Protect the link
- •2.4.2 Encryption algorithm
- •2.4.3 Mode of operation
- •2.4.4 Unicast and broadcast
- •2.5 Communication security policies
- •2.5.1 Security modes
- •2.5.2 Security policy management
- •References
- •3 Bluetooth Pairing and Key Management
- •3.1 Pairing in Bluetooth
- •3.2 HCI protocol
- •3.3 LM protocol
- •3.4 Baseband events
- •3.4.1 Initialization key generation
- •3.4.2 Unit key generation
- •3.4.3 Combination key generation
- •3.4.4 Authentication
- •3.4.5 Master key generation
- •3.5 User interaction
- •3.6 Cipher key generation
- •3.7 Key databases
- •3.7.1 Unit keys generation requirements
- •3.7.2 Combination key generation requirements
- •3.7.3 Key databases
- •3.7.4 Semipermanent keys for temporary use
- •References
- •4 Algorithms
- •4.1 Crypto algorithm selection
- •4.1.1 Block ciphers
- •4.1.2 Stream ciphers
- •4.2 SAFER+
- •4.3 Encryption engine
- •4.4 Ciphering algorithm E0
- •4.4.1 Initialization
- •4.5 Implementation aspects
- •References
- •5 Broadcast Encryption
- •5.1 Overview
- •5.2 Preparing for broadcast encryption
- •5.3 Switching to broadcast encryption
- •References
- •6 Security Policies and Access Control
- •6.1 Objectives
- •6.1.1 Trust relations
- •6.1.2 Security levels
- •6.1.3 Flexibility
- •6.1.4 Implementation considerations
- •6.2 Security manager architecture
- •6.2.1 Overview
- •6.2.2 Device trust level
- •6.2.3 Security level for services
- •6.2.4 Connection setup
- •6.2.5 Database contents and registration procedure
- •Reference
- •7 Attacks, Strengths, and Weaknesses
- •7.1 Eavesdropping
- •7.2 Impersonation
- •7.3 Pairing
- •7.4 Improper key storage
- •7.4.1 Disclosure of keys
- •7.4.2 Tampering with keys
- •7.4.3 Denial of service
- •7.5 Unit key
- •7.6 Location tracking
- •7.6.1 Bluetooth device address and location tracking
- •7.6.2 Five different types of location tracking attacks
- •7.7 Implementation flaws
- •References
- •8 Providing Anonymity
- •8.1 Overview of the anonymity mode
- •8.2 Address usage
- •8.3 Modes of operation
- •8.4 Inquiry and paging
- •8.4.1 Connectable mode
- •8.4.2 Private connectable mode
- •8.4.3 General connectable mode
- •8.5 Alias authentication
- •8.6 Pairing
- •8.7 Anonymity mode LMP commands
- •8.8 Pairing example
- •References
- •9 Key Management Extensions
- •9.1 Improved pairing
- •9.1.1 Requirements on an improved pairing protocol
- •9.1.2 Improved pairing protocol
- •9.1.3 Implementation aspects and complexity
- •9.2 Higher layer key exchange
- •9.2.2 Higher layer key exchange with EAP TLS
- •9.3 Autonomous trust delegation
- •9.3.1 Security group extension method
- •9.3.3 Group extension method versus public key method
- •References
- •10 Security for Bluetooth Applications
- •10.1 Headset
- •10.1.1 Headset security model
- •10.1.2 Pass-key and key management
- •10.1.3 Example
- •10.2 Network access
- •10.2.1 Common access keys
- •10.2.2 Security architecture
- •10.2.3 Network service subscription
- •10.2.4 Initial connection
- •10.2.5 Subsequent access to NAcPs
- •10.3 SIM access
- •10.3.1 The SIM access profile
- •10.3.2 Securing SIM access
- •References
- •Glossary
- •List of Acronyms and Abbreviations
- •About the Authors
- •Index
Providing Anonymity |
129 |
|
|
8.4 Inquiry and paging
With respect to inquiry, there is no difference between anonymous and nonanonymous devices. A device can be either in discoverable or nondiscoverable mode. Devices in discoverable mode return their active device address (see Section 8.2) in the inquiry response message. This implies that anonymous devices return a random address, while nonanonymous devices return the fixed device address.
With respect to paging, a Bluetooth device can be either in nonconnectable mode or in connectable mode. We have slightly changed the latter mode of operation for anonymous units and split it into three new modes:
1.Connectable mode;
2.Private connectable mode;
3.General connectable mode.
We discuss the rationale behind these three modes in more detail below. Devices in nonconnectable mode never perform any page scans. Hence, it is not possible to initiate any connections with a nonconnectable device.
The page procedure consists of a number of steps. The procedure starts with the device trying to find the address of the device it wants to connect to. A device in anonymous mode can be paged based on two possible addresses, the active device address and the fixed device address. Since an anonymous device in discoverable mode returns the active address in the inquiry response message, the paging device can use the inquiry procedure to find the active address of discoverable devices nearby. If the devices have performed a private pairing (see Section 8.6), the paging device knows the fixed address of the other device. In this case, paging using the fixed device address of the other device is possible. The address of the paged device is used to determine the page hopping sequence. A device can choose whether it shall be reachable on the active address, the fixed address, or both the fixed and active addresses. This corresponds to the different connectable modes that we have defined for the anonymity mode.
8.4.1Connectable mode
When a standard Bluetooth device is in connectable mode, it periodically enters the page scan state. The device makes page scans using the ordinary fixed device address. Anonymous devices operating in connectable mode use the same principles but make page scans on the active device address, BD_ADDR. The device can use different types of page scanning schemes. The connection setup time
130 |
Bluetooth Security |
depends on the scanning interval and is a trade-off between power consumption, available bandwidth, and setup delay. Scan interval, scan window, and interlaced scan can be used to achieve the desired trade-off (see [2] for details). Three different page scan modes are defined in the Bluetooth specification, and they are called R0, R1, and R2, respectively. In R0, continuous scanning is used, while R1 uses a scan interval of at the most 1.28 sec and R2 a maximum of 2.56 sec. A device in connectable mode can use any of the available scan modes.
The connectable mode was introduced to allow any device to connect to an anonymous device. Typically, the active address is obtained through the inquiry procedure. Once the active address is known and the anonymous device is in connectable mode, it will be possible to connect to the device using a page on the active address.
8.4.2Private connectable mode
The private connectable mode needs to be introduced to allow a device to directly page another device. By direct we mean that the device does not need to first go through the inquiry procedure. The inquiry procedure can take a rather long time. Furthermore, a device would like to connect to another device without being forced to answer responses from unknown devices. Hence, when a Bluetooth device is in private connectable mode, it makes page scans using the Bluetooth fixed device address, BD_ADDR_fixed. Any of the three different page scanning modes, R0, R1, or R2 (see Section 8.4.1), can be used.
The private connectable mode allows direct establishment of connections between trusted devices. Ideally a device only shares the value of the fixed address with trusted devices. This means that this connection mode should only be used by a device when it expects connection requests from trusted devices. Thus, even if the fixed address is not a secret parameter in a strict sense, a device that cares about location privacy should be careful about spreading the fixed address. If the fixed address is compromised, there is a small risk that the device could be tracked using the paging attack described in Chapter 7. This threat can be avoided by never entering the nonanonymous or private connectable mode. On the other hand, that makes it impossible to set up direct connections between trusted devices.
Hence, to reduce this threat, a device shall always expect an alias authentication request (see Section 8.5) from the master after a response to a paging on the fixed address. If no alias is received or the setup fails before the connection state has been reached, we recommend a connection failure counter to be incremented. If the failure counter exceeds a threshold value, the host controller can then send a warning to the host. It is then up to the host to take proper action and perhaps warn the user that someone might try to track the movement using the paging attack.