
- •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 |
133 |
|
|
8.6 Pairing
For anonymous devices, we would like the user to decide (at the pairing) whether to disclose the fixed hardware address or not. Higher location privacy is achieved if the fixed address is only disclosed to trusted devices. By this we mean devices that can be trusted for a long time. This is not true for all pairings, as trust relations might as well be quite temporary. Thus, at the pairing, anonymous devices need to distinguish between devices to which the fixed address should be given and other devices. This is done by setting the device to pairable or private pairable mode. In the first pairing mode, the fixed address is not disclosed, while it is in the second. This is different from standard Bluetooth units that only support two pairing modes: nonpairable and pairable.
When a device supporting the anonymity mode is in pairable mode, it accepts a request for pairing through the LMP command LMP in rand from a remote device. It also issues this command if authentication is requested and no link key for the corresponding device is known. The device does not exchange alias addresses or private addresses with the remote device. The device shall reject all fixed address exchange requests, since it will not give out its own fixed address.
When a device is in private pairable mode, it also accepts requests for pairing and initiates a pairing if authentication is requested and the link key is missing. The device uses the new LMP commands (see Section 8.7) to exchange alias and private addresses.
The behavior of a device supporting the new private pairing modes needs to be carefully specified in order to provide good interoperability. We do not give any details here, but in the next section we list a set of LMP commands that can be used by the devices to exchange private addresses and alias addresses and in Section 8.8 we give a private pairing example.
8.7 Anonymity mode LMP commands
A set of new LMP commands are needed in order to inform connected devices of an update of the active address and to exchange alias and private addresses. In all, we have identified the need for three different anonymity mode LMP commands:
•LMP active address;
•LMP alias address;
•LMP fixed address.

134 |
Bluetooth Security |
In the following sections we describe how these command work in more detail.
8.7.1Address update, LMP active address
Devices in anonymity mode maintain an active address that is changed frequently (see Section 8.2). The active address is used by the master to determine the hopping sequence and CAC used by the piconet. Hence, it is important for the master to inform the slaves of the new address whenever it is updated. Furthermore, a slave must also inform the master of updates to the active address. If this is not done, the master cannot directly reconnect (through paging) to the slave if the connection for some reason is broken or if a master-slave switch is required. The LMP command LMP active address can be used to inform other devices of active address updates as we now will describe.
When the master device decides to make a change to its active address, it informs all its slaves of the change. (See Section 8.2, where the updating rules are described in detail.) When a new LAP has been generated, the master should select a time instant that is far enough in the future that all slaves will have received the message and returned the LMP accepted. The master then needs to send the LMP active address PDU containing the new active address and the switching time to all slaves. When a slave receives the LMP active address PDU from the master, it shall return LMP accepted and start a timer to expire at the given time instant. The LMP PDU exchange sequence for a successful address exchange sequence is shown in Figure 8.2. When the switch instant is reached, the master shall change the active address, causing the hopping sequence, encryption, and CAC to change to values derived from the master’s new active address.
Similarly, when a slave device decides to change its active address, it shall generate a new active address and send it to the master in the LMP active address PDU, as shown in Figure 8.2. No timing information is needed in this case, and the change in active address can take place immediately.
8.7.2Alias address exchange, LMP alias address
As we described in Section 8.5, a device in anonymous mode needs to be authenticated based on a previously agreed-upon alias rather than on the
LMP active address
Initiating |
|
BD_ADDR, switch_instant |
Responding |
|
|
|
|
||
unit |
|
LMP accepted |
unit |
|
|
|
|
|
|
Figure 8.2 LMP sequence when informing a slave or master of a new active address.

Providing Anonymity |
135 |
|
|
BD_ADDR. The PDU LMP alias address can be used for this purpose. The PDU contains the alias address.
When a connection is being set up, either device may attempt to carry out the authentication using an alias. The initiating LM sends an
address PDU, which indicates an attempt to do authentication based on an alias. If the receiving LM knows of the specified alias, it replies with its own corresponding alias; otherwise it replies with LMP not accepted. The LMP PDU exchange sequence for a successful alias address exchange sequence is shown in Figure 8.3.
Once an alias has been established, subsequent authentications use the link key associated with the alias. When the connection is completed and encryption has been enabled, the master updates the alias address by generating a new alias address and sending it to the slave in an LMP alias address, which indicates a refresh of the BD_ADDR_alias. A special flag in the PDU is needed in order for the slave to be able to distinguish the alias address update case from the alias authentication case. The slave then replies with an update of its own corresponding alias according to the LM PDU exchange sequence in Figure 8.3. It is important that the alias address establishment or update messages are only sent on encrypted links; otherwise the anonymity might be compromised.
8.7.3Fixed address exchange, LMP fixed address
As we described in Section 8.6, if one device is in the private pairing mode, the device sends its BD_ADDR-fixed. This is done in order to allow the other device to directly page (i.e., without going through the inquiry procedure) the device when a connection shall be established. The PDU LMP fixed address is used for this purpose. When a device receives this PDU and it is prepared to allow private pairing, it replies with its own fixed address as shown in the LM exchange sequence in Figure 8.4 (successful exchange sequence).
|
|
LMP alias address |
|
||
|
|
BD_ADDR_aliasA |
|
||
Initiating |
Responding |
||||
|
|
|
|||
unit A |
|
LMP alias address |
unit B |
||
|
|
BD_ADDR_aliasB |
|
||
|
|
Figure 8.3 LMP sequence for successful exchange of alias addresses.
|
|
LMP fixed address |
|
||
|
|
BD_ADDR_fixedA |
|
||
Initiating |
Responding |
||||
|
|
|
|||
unit A |
|
LMP fixed address |
unit B |
||
|
|
BD_ADDR_fixedB |
|
||
|
|
Figure 8.4 LMP sequence for successful exchange of fixed addresses.