5 SECURITY OVERVIEW
5.1 Securitybuild
The Bluetooth security model contains5Unique security features：Pairing, bonding, device authentication, encryption and message integrity.
Pairing: Creates one or more shares.keyscourse of action
Bonding:The operation of storing keys created during the pairing process for use in subsequent connections to form trusted device pairs
Device authentication: verify that both devices have the same key
Encryption: message confidentiality
Message integrity: preventing message forgery
The Bluetooth core security architecture has evolved over time. In the beginning, pairing was done using the SAFER + based E21 or E22 algorithms. This version of pairing is referred to as "BR / EDR legacy pairing". Device authentication was initially based on the E1 algorithm, which is also based on SAFER +. Encryption utilizes the E0 algorithm obtained from the Massey-Rueppel algorithm. There is also no provision for the integrity of the encrypted message. Note that while CRC provides some integrity protection, it is not considered to provide cryptographic integrity since it can be easily forged.
Version 2.1+ EDR of the Core Specification introduces Secure Simple Pairing, which utilizes FIPS-approved algorithms (SHA-256, HMAC SHA-256, and P-192 elliptic curves) and introduces four correlation models: Just Works, Numeric Comparison, Password Entry, and Out-of-Band (see Section 5.2). Device authentication and encryption remain unchanged with the introduction of Secure Simple Pairing.
Version 3.0+ HS of the core specification adds support for AMP (see Section 5.5).
Version 4.0 adds the entire safety model for low energy consumption (see Section 5.4), but does not change any of the safety features of BR / EDR or AMP.
Version 4.1 adds Secure Connectivity to the BR / EDR physical transport, which upgrades Secure Simple Pairing to utilize P 256 elliptic curves, using FIPS-approved algorithms (HMAC-SHA-256 and AES-CTR) for device authentication. Secure Connect also adds message integrity (AES-CCM).
Version 4.2 adds Secure Connection to the LE physical transport, which upgrades LE pairing to utilize FIPS-approved algorithms (AES-CMAC and P-256 elliptic curves) and adapts the numerical comparison correlation model for use with Bluetooth LE physical transports. It also includes provisions for the use of secure connection-generated keys on either physical transport to preclude the need for users to pair a second time on the other physical transport. LE pairing as defined in Bluetooth Core Specifications 4.0 and 4.1 is referred to as LE legacy pairing.
The security key hierarchy for BR / EDR and AMP is shown in Figure 5.1. The key hierarchy will vary depending on whether the physical link is using a secure connection or an older version of the security process and algorithm.
The LE security key hierarchy is shown in Figure 5.2. The key hierarchy will vary depending on whether the physical link uses LE secure connections or LE old-style pairing processes and algorithms.
5.2 BR/EDR SECURE SIMPLE PAIRING
The primary goal of Secure and Simple Pairing is to simplify the pairing process for users. A secondary goal is to maintain or improve the security of Bluetooth wireless technology. Since high-level security and ease of use are often at opposite ends of the spectrum in many technologies and products, many steps have been taken to maximize security while minimizing complexity from the end-user's perspective.
5.2.1 Security Goals
Secure Simple Pairing has two security goals: protection against passive eavesdropping and protection against man-in-the-middle (MITM) attacks (active eavesdropping). "The goal of Secure Simple Pairing is to exceed the maximum level of security provided by the use of a 16-digit alphanumeric PIN and the pairing algorithms used in Bluetooth Core Specification version 2.0 + EDR and earlier. Note that many Bluetooth devices compliant with Bluetooth Core Specification 2.0 + EDR and earlier versions use either a 4-digit PIN or a fixed PIN with a known value, which greatly limits the security of the link.
5.2.2 Passive Eavesdropping Protection
In order to protect users from passive eavesdropping, a strong link key must be combined with a strong encryption algorithm. The strength of the link key is based on the amount of entropy (or randomness) in its generation that is not known to the attacker. With traditional pairing, the only source of entropy is the PIN, which in many use cases is usually a four-digit number chosen by the user or fixed for a given product. Thus, if the pairing process and an authentication exchange are recorded, a very exhaustive search can be performed on common computing hardware to find the PIN in a very short time. using secure simple pairing, the recording attack becomes much more difficult because the attacker has to solve a difficult problem in public-key cryptography in order to derive the linking key from the recorded information. This protection is independent of the length of the key or other numeric values that the user must deal with. Secure Simple Pairing is resistant to recording and passive eavesdropping attacks, even if the user does not need to perform any action.
Secure Simple Pairing uses Elliptic Curve Diffie Hellman (ECDH) public key cryptography to block passive eavesdropping attacks. ECDH provides a very high level of strength against passive eavesdropping attacks, but it may be vulnerable to MITM attacks, but in practice it is much harder than passive eavesdropping attacks (see Section 5.2.3).
Using the security protocol in Bluetooth Core Specification version 2.0 + EDR and earlier and a 16-digit PIN yields approximately 53 bits of entropy, whereas using a 16-alphanumeric-letter, case-sensitive PIN yields approximately 95 bits of entropy when using the entire 62-character set ([0,... 9, 'A', ...' Z', 'a', ...' z']). For devices that do not support the Secure Connection feature (introduced in Core Specification v4.1), using the FIPS-approved P-192 elliptic curve, Secure Simple Pairing has approximately 96 bits of entropy that is at least as good as the entropy in Bluetooth Core Specification 2.0 + EDR and earlier versions, using a 16-character, alphanumeric For devices that do support the Secure Connect feature, Secure Simple Pairing has about 128 bits of entropy using the FIPS-approved P-256 elliptic curve. ECDH encryption was chosen over the standard Diffie Hellman (often referred to as DH76) because it is computationally less complex and is unlikely to exceed the low computational power found in common Bluetooth controllers.
5.2.3 Man-In-The-Middle Protection
Man-in-the-middle (MITM) attacks occur when a user wants to connect two devices, but they unknowingly connect to a third (attacking) device that they don't want to be directly connected to each other, and the third device plays the role of the device they are trying to use with. The third device then relays information between the two devices, thus giving the illusion of a direct connection. The attacking device can even eavesdrop on the communication between the two devices (known as active eavesdropping) and is able to insert and modify information on the connection. In this type of attack, all information exchanged between the two devices is corrupted, and the attacker may inject commands and messages into each device, potentially damaging its functionality. Devices that are victims of an attack are only able to communicate when an attacker is present. If the attacker is inactive or out of range, the two victimized devices will not be able to communicate directly with each other and the user will notice it.
To prevent MITM attacks, Secure Simple Pairing provides two user-assisted numeric methods: numeric comparison or PIN entry. If Secure Simple Pairing will use 16 decimal digits, the usability will be the same as if it were using an older pairing with a 16 decimal digit PIN. In this case, MITM's chance of successfully inserting its own link key is 1 in 10 to the 16th power = 2 to the 53rd power of the pairing instance, which is unnecessarily low probability.
"Secure Simple Pairing" protects the user from MITM attacks with the goal of making the probability of a successful MITM attack 1 in 1,000,000. The strength of the MITM protection was chosen to minimize the impact on the user by using a six-digit number for numerical comparisons and entering a password. This level of MITM protection was chosen because in most cases it alerts the user to the potential presence of a MITM attacker when the connection process fails due to a failed MITM attack. Although most users believe that a 4-digit key is sufficient for authentication (i.e., bank card PINs) as long as they do not break their passwords, the use of 6-digits allows for secure simple pairing that is FIPS compliant and is considered to have a virtually non-significant usability impact.
5.2.4 Association Models
Secure Simple Pairing uses four association models called Numerical Comparison, Just Works, Out-of-Band, and Key Input. Each of these association models is described in more detail in the following sections.
The association model will be determined based on the I/O functions of the two devices.
5.2.4.1 Numeric Comparison
The Numeric Comparison Association Model is designed for scenarios where both devices can display 6 numbers and both support user input of 'yes' or 'no'. Typical of this model is the cell phone - PC scenario
A six-digit number (from "000000" to "999999") is shown to the user on both displays and the user is asked if the number is the same on both devices. If "Yes" is entered on both devices, the pairing is successful.
The numerical comparison serves two purposes. First, because many device names are not unique, it confirms to the user that the correct devices are connected to each other. Second, the numerical comparison prevents MITM attacks (see Section 5.2.3).
Note that from a cryptographic point of view, there are significant differences between the Digital Comparison and the PIN entry model used in the Bluetooth Core Specification and earlier versions. In the numeric comparison association model, as in the Bluetooth security model, the six digits are artifacts of the security algorithm, not inputs. Knowing the digits displayed is of no benefit in decrypting the encoded data exchanged between two devices.
5.2.4.2 Just Works
The Just works association model is designed for this scenario: at least one of the devices does not have a display capable of displaying six digits, nor does it have a keyboard capable of entering six decimal digits. A good example of this model is the cell phone/mono headset scenario, in which most headsets do not have displays.
The Just Works correlation model uses a numeric comparison protocol, but never displays the numbers to the user; the application may simply ask the user to accept the connection (the exact implementation depends on the final product manufacturer).
The Just Works association model provides the same protection against passive eavesdropping as the "numerical comparison" association model, but does not provide protection against MITM attacks.
Compared to today's experience with fixed PIN headsets, the Just Works correlation model offers a much higher level of security because of the high level of protection achieved against passive eavesdropping.
5.2.4.3 Out of Band
The Out-of-Band (OOB) association model is primarily designed for the following scenarios: the out-of-band mechanism is used for device discovery as well as for exchanging or transferring the cryptographic numbers used during the pairing process. To be effective from a security point of view, out-of-band channels should provide different properties in terms of security compared to Bluetooth radio channels. The out-of-band channel shall be resistant to MITM attacks. If not, security may be compromised during authentication.
The user experience depends on the out-of-band mechanism. For example, with a near field communication (NFC) solution, the user will first touch two devices and then have the option of pairing the first device with the other. If "yes" is entered, the pairing is successful. This is a touch experience where exchanged information is used in both devices. The exchanged information includes discovery information (e.g., Bluetooth device address) and passcode information. One device will use the Bluetooth device address to establish a connection with the other device. The rest of the exchanged information is used during authentication.
The OOB mechanism can be implemented as read-only or read/write. If one side is read-only, one-way authentication is performed. If both sides are read/write, two-way authentication is performed.
The OOB protocol is selected only if a previous exchange of OOB information has activated the pairing process and one (or both) of the devices has given OOB as an IO function. This protocol uses the exchanged information and only requires the user to confirm the connection.
The OOB association model supports any OOB mechanism that can exchange passcode information and Bluetooth device addresses. The OOB association model does not support solutions where the user has activated a Bluetooth connection and only wants to use OOB for authentication.
5.2.4.4 Passkey Entry
The password input association model is primarily designed for situations where one device has input capability, but not the ability to display six digits, and the other device has output capability. The PC and keyboard scheme is a good example of this model.
A six-digit number (from " 000000" to " 999999") is displayed for the user on the device with the display, and then the user is asked to enter the number on another device. If the value entered on the second device is correct, the pairing is successful. Note that from a password perspective, there are significant differences between the Password entry and the PIN entry model used in Bluetooth Core Specification 2.0 + EDR and earlier versions. In the Passkey Entry association model, as in the 2.0 + EDR security model, the six-digit number is independent of the security algorithm, not its input. Knowing the input number has no benefit in decrypting the encoded data exchanged between the two devices.
5.2.4.5 Association Model Overview
The following figure describes secure simple pairing from the point of view of discovery techniques and then describes the different association possibilities.
5.3 SECURE CONNECTIONS ONLY MODE
When a device requires that only FIPS-approved algorithms be used on the BR/EDR physical transport, it should enter "secure connection only" mode on the BR/EDR physical transport. Secure Connection Only mode is sometimes referred to as "FIPS mode". This mode should be used when it is more important for a device to have a high level of security than to maintain backward compatibility with devices that do not support secure connections. The host will force the use of P-256 elliptic curves during the pairing process, the use of secure authentication sequences, and encryption using AES-CCM.
When a device requires that only FIPS approved algorithms be used on the LE physical transport, it shall enter "secure connection only" mode on the LE physical transport. Secure Connection Only mode is sometimes referred to as "FIPS mode". This mode should be used when it is more important for the device to have a higher level of security than to maintain backward compatibility with devices that do not support LE secure connections. In this mode, the host will force the use of P-256 elliptic curves during the pairing process.
If the BR / EDR / LE device is configured for Secure Connection Only mode, both the BR / EDR and LE transmitters will be in Secure Connection Only mode.
5.4 LE SECURITY
The pairing mechanism introduced in the Bluetooth Core Specification v4.0 (called LE Old Style Pairing) has some differences in the security aspects of BR / EDR security features such as Secure Simple Pairing. From the user's point of view, the association model is similar to BR / EDR Secure Simple Pairing and has the same name, but the quality of the protection provided differs.
5.4.1 Association Models
Bluetooth LE uses four association models called Just Works, numeric comparison, out-of-band, and key entry. LE old-style pairing has no equivalent numeric comparison.
In LE old-style pairings, each of these association models is similar to the BR / EDR secure simple pairing, with the following exceptions.
Just Works and Passkey Entry do not offer any passive eavesdropping protection. This is because Secure Simple Pairing uses Elliptic Curve Diffie-Hellman, while LE Traditional Pairing does not.
In the LE secure connection pairing, the four association models are functionally equivalent to the BR / EDR secure connection.
The use of each association model is based on the I/O capabilities of the device.
5.4.2 Key Generation
Key generation in Bluetooth LE is performed by the host on each LE device independently of any other LE device. By performing key generation in the host, the key generation algorithm can be upgraded without changing the controller. Note: Key generation in BR / EDR is performed in the controller.
The Bluetooth LE uses multiple keys, each with a specific purpose, as shown below:
-Confidentiality of data and device authentication
-Authentication of unencrypted data
-Device identity
In LE, keys for providing confidentiality and authentication are generated by combining the contributions of each device during pairing.
5.4.3 Encryption
Encryption in Bluetooth LE uses AES-CCM encryption. As with BR / EDR, LE encryption is performed in the Controller.
5.4.4 Signed Data
Bluetooth LE supports the ability to send authenticated data over an unencrypted ATT bearer between two devices with a trust relationship. This can be accomplished by signing the data using a Connection Signature Resolution Key (CSRK). The sending device places a signature after the data PDU. The receiving device verifies the signature and if the signature is verified, the data PDU is assumed to be from a trusted source. The signature consists of a message authentication code generated by the signature algorithm and a counter. The counter is used to prevent replay attacks and is incremented on each signed data PDU sent.
5.4.5 Privacy Feature
Bluetooth LE supports a feature that reduces the ability to track LE devices over time by frequently changing the Bluetooth device address.
In order for a device using the privacy feature to reconnect to a known device, the device address (called a private address) must be resolvable by other devices. The private address is generated using the resolved identity key (IRK) of the device exchanged during the binding process.
There are two variants of the privacy feature. In the first variant, the private address is resolved and generated by the host. In the second variant, the controller resolves and generates the private address without involving the host after the host provides the controller device identity information. Alternatively, the second variant may involve the host when the resolution list in the controller is unable to store all the device identity resolution keys required to bind the device.
There are two modes of privacy: device privacy mode and network privacy mode. A device in device privacy mode is only concerned with the privacy of the device and will accept advertisement packets from a peer device that contains its identification address as well as from a peer device that contains a private address, even if the peer device has distributed its IRK in the past . In network privacy mode, the device will only accept advertisement packets from peer devices that contain private addresses. By default, network privacy mode will be used when the controller resolves and generates private addresses.
Hosts maintain resolution lists by adding and removing device identifiers. The host can provide the controller with the complete resolution list or a subset of the resolution list. The device identity consists of the peer's identity address and the local and peer IRK pairs.
When the Controller performs address resolution and the host needs to refer to a peer device included in the resolution list, it will use the identifying address of that peer device. Similarly, all incoming events from the Controller to the host will use the peer's device identification, provided the peer's device address is resolved. If the controller is unable to resolve the peer's device identification address in an advertisement, it passes the event to the host for resolution in the host.
Device filtering is possible when performing address resolution in the Controller, as it is possible to resolve the identity address of a peer device before checking if it is in the whitelist.
Figure 5.4 shows a logical representation of the relationship between controller resolution lists and controller whitelists. Following this model does not require an actual implementation of parsing lists and whitelists. The parsing list can be independent of the whitelist.
Note: Not all devices in the whitelist are device identification addresses.
If address resolution is performed only in the host, the device may increase power consumption because device filtering must be disabled.
5.5 AMP SECURITY
AMP security does not change the user experience as it utilizes the same Secure Simple Pairing association model introduced in the Bluetooth 2.1 + EDR Core Specification. From the user's perspective, all radios are "paired" in one process.
AMP security begins during the "Secure Simple Pairing" process. The BR/EDR link key is generated in phase 4 of "Secure Simple Pairing". A 256-bit Generic AMP Link Key (GAMP_LK) is generated from the BR/EDR Link Key. After the pairing is completed, the Generic AMP Link Key is stored in the security database together with the BR / EDR Link Key.
AMP security does not affect BR / EDR link keys, so backward compatibility is maintained for devices that support Generic AMP functionality as well as devices that do not support Generic AMP functionality.
The first time AMP is used, a dedicated AMP key is created by AMP Manager for that AMP type using the new Secure Simple Pairing feature h2 and the KeyID of the AMP type. The length of the dedicated AMP link key depends on the AMP type. If paired master keys already exist as a result of a previous connection, no AMP link key is created and the stored key is reused.
Dedicated AMP link keys are sent to PALs during the physical link creation process. Each PAL is responsible for using dedicated AMP link keys during the security phase of the physical link creation process. Note that the dedicated AMP link key is used for multiple sessions on the same AMP.
The Generic AMP Link key is updated each time a dedicated AMP key is successfully created. This is performed via the h2 function and KeyID 'gamp'.
5.6 KEY GENERATION BETWEEN BR/EDR AND LE PHYSICAL
TRANSPORTS
When two BR / EDR / LE devices support secure connections on both transports, keys for both transports can be generated in a single pairing process. The ability to convert keys from one transport to the other avoids the need to pair twice, providing a better user experience.
The BR/EDR Link Key generated during Phase 4 of the "Secure Simple Pairing" on the BR/EDR physical transport can be converted to a Long Term Key (LTK) for use on the LE transport. Similarly, the LTK generated during Phase 2 of the pairing on the LE physical transport can be converted to a BR/EDR link key for use on the BR/EDR physical transport.