4. Information security regulations applicable to Bluetooth

1. History of Bluetooth development 

Originating from Ericsson's technical solution in 1994, when the inventor wanted to create a set of the same rules (standardized protocols) for inter-device communication, so as to achieve low-power, low-cost wireless communication connections. When in May 1998, five famous manufacturers such as Ericsson, Nokia, Toshiba, IBM, and Intel proposed the Bluetooth technology during the joint standardization activities of short-range wireless communication technology. On May 20, 1999, these five manufacturers established the Bluetooth 'Special Interest Group' (SIG), the predecessor of the Bluetooth Technology Alliance, so that Bluetooth technology could become the wireless communication standard in the future. Intel, the chip king, was responsible for the development of semiconductor chips and transmission software, Ericsson was responsible for the development of wireless radio frequency and mobile phone software, and IBM and Toshiba were responsible for the development of laptop interface specifications. In the second half of 1999, Microsoft, Motorola, Samsung, Lucent, and the Bluetooth SIG jointly established the Bluetooth Technology Promotion Organization, thus bringing Bluetooth into the global wireless communication wave at the beginning of the 21st century. By April 2000, the SIG members exceeded 1500 and continued to grow rapidly. The Bluetooth 1.0 standard was also released in July 1999, which included the following:

On October 13, 2006, Lenovo replaced IBM to become the founding member of the Bluetooth SIG organization. Here is a brief list of the evolution process of Bluetooth versions:

2. Overall introduction of Bluetooth architecture 

Taking the Bluetooth 4.0 architecture as an introduction, as shown below:

Or, we can also approximately use the following figure:

Among them:

1. HW layer: The essence of the Bluetooth chip layer, which includes

(1) RF(radio): The radio frequency layer, which sends local Bluetooth data to the remote device through radio frequency and receives data from the remote Bluetooth device through radio frequency

(2) BB(BASEBAND): The baseband layer, which performs the mutual conversion between radio frequency signals and digital or voice signals

(3) LMP (LINK MANAGER PROTOCOL): Link Management Protocol, responsible for managing communication between Bluetooth devices, and realizing link establishment, verification, and link configuration operations.

(4) HCI (HOST CONTROLLER INTERFACE): Host Controller Interface Layer, the HCI layer exists in both the chip and the protocol stack. The HCI at the chip level is responsible for processing the data of the protocol stack, converting it into internal actions of the chip, and receiving data from the remote end.

(5) BLE PHY: BLE Physical Layer

(6) BLE LL: BLE Link Layer

2. Transport Layer: This part implements the interaction between the hardware interface UART/USB/SDIO and the HOST and controller, and there are several sub-protocols:

(1) H2: For USB type

(2) H4: For UART type

(3) H5: For UART type

(5) BCSP: For UART type

3. HOST Layer, This layer is the protocol stack

(1) HCI is HOST controller interface, the main responsibility of which is to send the data of the protocol stack to the Bluetooth chip through transport and receive data from the Bluetooth chip.

(2) L2CAP (Logical Link Control and Adaptation Protocol): Logical Link Control and Adaptation Protocol, which exchanges ACL data packets into data packets suitable for high-level applications, and provides protocol multiplexing and service quality exchange functions.

(3) SDP (SERVICE DISCOVERY PROTOCOL): Service Discovery Protocol

(4) RFCOMM (Serial Port Emulation): Serial port emulation protocol, upper protocol Bluetooth phone, Bluetooth transparent SPP

etc. functional modules

3. Typical Security Measures for Bluetooth Network 

3.1 Basic Encryption Strategy

When it comes to Bluetooth security features, first see the following figure:

As mentioned above, Bluetooth security measures can protect communication between mobile phones and laptops, while IEEE802.11 provides WLAN connection security issues from the router to the laptop. In addition, it is not within the scope of the above protection. The Bluetooth standard mainly specifies three basic security services:

Authentication: Based on the Bluetooth device address, verify the identity of the device that is communicating. Bluetooth does not provide a native user authentication mechanism.

Confidentiality: Ensure that only authorized devices can access and view the transmitted data to prevent information leakage caused by eavesdropping.

Authorization: Allow control over resources by ensuring that the device is authorized before it is allowed to use a service.

Bluetooth devices can implement four different security modes

1. Insecure:Bluetooth devices do not activate any security measures.

2. Mandatory Security Mode:Two Bluetooth devices can establish an insecure ACL link. When a logical link control and adaptation protocol (L2CAP) connection-oriented (CO) or L2CAP lightweight (CL) channel request is made, the security process, i.e., authentication, authorization, and optional encryption, will be initiated.

3. Link-level enforced security mode:After the ACL link is established, the security process will be initiated.

4. Security mode enforced by service level:This mode is similar to mode 2, but it is only available for Bluetooth devices that use SSP, that is, only Bluetooth 2.1 + EDR or higher version devices can use this security mode. Bluetooth uses a secure and fast encryption routine + (SAFER +) with a 128-bit key as the authentication and key generation algorithm in the highest 3.0 + HS (High Speed) Bluetooth version, while Bluetooth 4.0 (i.e., low power Bluetooth) replaces SAFER + with a more secure 128-bit Advanced Encryption Standard (AES). SAFER + was developed by Massey et al. In 1998, it was submitted as a candidate for the AES competition but was not selected as a finalist.

SAFER + is a block cipher with the following main features. It has a block size of 128 bits and three different key lengths (128, 192, and 256 bits). SAFER + consists of nine stages (eight identical rounds and an output transformation) and a key scheduling algorithm (KSA), which is as follows. The KSA generates 17 different 128-bit subkeys. Each round uses two subitems and one 128-bit input word from the previous round to compute a 128-bit word, which is the new input word for the next round. The last subkey is used for the output transformation, which is a simple bitwise XOR between the output of the last round and the last subkey. After the evaluation process of the AES competition, AES was released by the National Institute of Standards and Technology (NIST) in 2001. Rijndael was the winner of the competition, and NIST selected it as the AES algorithm. AES is a symmetric block cipher designed to replace the Data Encryption Standard (DES) as the recognized standard for widespread applications, but this process will take many years. NIST expects that in the foreseeable future, at least in the case of government use in the United States, the Triple Data Encryption Standard (3DES) will still be the approved algorithm. AES encryption consists of 10-14 rounds, where the data block is processed step by step in the following manner (except for the last round; it is worth noting that AES decryption is symmetric to AES encryption) 1. Byte substitution: Byte substitution uses the S-box to perform block-by-block substitution. 2. Row shifting: Row shifting is a simple permutation. 3. Column mixing: Column mixing is an arithmetic substitution over GF(2^8). The Galois field GF(2^8) is a finite field with 256 elements, which can be represented by an 8-bit string or hexadecimal notation. 4. Round key addition: Round key addition is a simple bitwise XOR between the current block and part of the expanded key. The last round of AES encryption (and AES decryption) is slightly different.

• 1. Byte Substitution
• 2. Row Shifting
• 3. Round Key Addition

AES is considered secure, it is very fast and compact (about 1 kB of code), its block size is a multiple of 32 (usually 128 bits), and its key length is also a multiple of 32 (usually 128, 192, or 256 bits), and it has a very neat algebraic description.

The 48-bit BD_ADDR is divided into three parts: 16-bit non-effective address part (NAP), 8-bit high address part (UAP), and 24-bit low address part (LAP). The first three bytes of BD_ADDR (NAP and UAP) are the manufacturer of the Bluetooth chip, representing company_id. The last three bytes of BD_ADDR (LAP) (known as company_assigned) are used more or less randomly in different Bluetooth device models.

When a Bluetooth device connects for the first time, an initialization key (Kini t) is generated, which is used to protect the generation of other more secure 128-bit keys, which are generated in the next stage of the event security chain.

K_init is a 128-bit key generated from pseudo-random number IN_RAND, L-byte PIN code, and BD_ADDR, and the generation of IN_RAND must be placed in a high-security environment.

The output of a certain key generation function can be represented by the function itself and its input. Here, the generation of K_init uses K_init = Encrypt(PIN', L', IN_RAND).

Before sending the PIN code and its length L to the Encrypt function, modify it to two different quantities called PIN' and L'. If the PIN is less than 16 bytes, increase the PIN by adding bytes from the device's BD_ADDR until the total length of the PIN reaches 16 bytes or the entire BD_ADDR is appended, whichever comes first.

K_ini t is used to encrypt 128-bit pseudo-random numbers (RAND or LK_RAND), as shown in K_A = Encrypt2(BD_ADDR_A, RAND_A); as shown, device A can encrypt K_A with K_init, for example K_A xor K_init, and then send it to device B; device B gets K_A with Kinit; here, both device A and B have A's key.

Bluetooth devices using a unit key have only one key that can be used for all their connections. This means that the same key is shared with all other trusted Bluetooth devices. In addition, any trusted Bluetooth device using the same unit key can eavesdrop on any traffic between the two other Bluetooth devices that share the same unit key. Moreover, any trusted Bluetooth device using the same unit key can simulate the target device simply by copying its BD_ADDR.

Here, the encryption method provided by the above method is only used in lower-tiered models.

A more common combination key K_AB will be more widely used with K_AB = Encrypt2(BD_ADDR_A, RAND_A) xor Encrypt2(BD_ADDR_B, RAND_B). Or K_AB = K_A xor K_B.

Next, let us introduce the challenge-response authentication mechanism.

The preliminary key exchange process of the above authentication process is as follows: Initially, device A encrypts LK_RAND_A with K and releases it to B (regardless of whether K is K_A, K_B, or K_AB); B uses the same key K to obtain the random number LK_RAND_A, the process is (LK_RANDA ⊕ K) ⊕ K; and B can encrypt LK_RAND_B with K and transmit it to A, where A decrypts it using K, so that (LK_RANDB ⊕ K) ⊕ K = LK_RANDB, thus generating K_B.

Both can generate composite keys such as K_AB in different ways.

The process of challenge-response authentication involves checking the applicant's knowledge of the secret link key, as described in the figure above. During each authentication, the system uses a new 128-bit pseudo-random number AU_RAND to exchange unencrypted through the air. A 32-bit result (SRES, signature response) and a 96-bit result (ACO, authentication password offset) are generated in both devices through the E1 (AU_RANDA, BD_ADDRB, link key) function, where the link key is KA or KAB. The SRES value generated by A is propagated to the verification device B in an unencrypted form. The verifier compares the generated SRES value with the received SRES value, and if these values match (0), the authentication is successfully completed. When generating the encryption key, ACO will be used in the next stage of the event security chain.

3.2. Data Encryption Part

ACO, the current link key (KA or KAB) and 128-bit pseudo-random number EN_RAND are the inputs of the encryption key generation function E3 used to generate the encryption key (KC). The master device A generates EN_RAND and sends it to device B in an unencrypted form through the air, while K_C is generated by the following function: KC = E3(EN_RANDA, ACO, K_A or K_AB). Here, the key stream generator function E0 makes symmetric encryption possible by generating the same cipher bit stream or key stream (also known as running key) in both devices.

The input of the E0 function is KC, the host's BD_ADDR (BD_ADDRA) and the 26-bit (CLK26-1) real-time clock of the host. The key stream is generated by the E0 (KC, CLK26-1, BD_ADDRA) function, which is re-initialized for each new transmitted or received baseband data packet. This means that the input of the E0 function will never be longer than the lifetime of a baseband data packet, so a new key stream is generated for each new baseband data packet.

The sender encrypts the plaintext by performing an XOR operation with the key stream (i.e., Plaintext ⊕ Keystream = Ciphertext) and then sends the generated ciphertext to the recipient. The recipient decrypts the ciphertext by performing an XOR operation with the same key stream.

It is noteworthy that only the payload of the Bluetooth baseband data packets is encrypted (not the access code or header), so the attacker cannot use the access code and the rules of the visitor to repeat the information (the attacker is easy to guess) to perform cryptanalysis on the password.

3.3. One way of MITM

MITM is called Man-In-The-Middle Attack, colleagues interested can consider the following story:

1. Alice sends her public key to Bob, but Mallory can intercept it. Mallory sends his own public key to Bob and provides a matching private key for it. Now Bob mistakenly believes that he has Alice's public key.

2. Bob sends his public key to Alice, but Mallory can intercept it. Mallory sends his own public key to Alice and provides a matching private key for it. Now Alice mistakenly believes that she has Bob's public key.

3. Alice sends a message encrypted with Mallory's public key to Bob, but Mallory is able to intercept it. Mallory decrypts the email with his private key and keeps a copy of the email, re-encrypts the email with Bob's public key, and then sends the message to Bob. Now Bob mistakenly believes that the message is directly transmitted from Alice.

4. Bob sends a message encrypted with Mallory's public key to Alice, but Mallory is able to intercept it.

Mallory decrypts the message with his private key and keeps a copy of the email, re-encrypts the email with Alice's public key, and then sends the message to Alice. Now, Alice mistakenly believes that the message is directly transmitted from Bob.

Or you can view the following picture:

Bluetooth versions 2.1 + EDR, 3.0 + HS, and 4.0 have added new specifications for the pairing process, namely SSP. Its main goal is to improve the security of pairing by providing protection against passive listening and Man-in-the-Middle (MITM) attacks.

SSP uses the elliptic curve Diffie-Hellman (ECDH) public key encryption technology, rather than using (usually short key) as the only entropy source for constructing the link key. To construct the link key, the device uses a public-private key pair, multiple random numbers, and the device's Bluetooth address. SSP can effectively prevent passive eavesdropping.

To provide protection against MITM attacks, SSP uses out-of-band (OOB) channels (such as Near Field Communication, NFC) or seeks user assistance: for example, when both devices have displays and keyboards, the user is required to compare two six-digit numbers. This comparison can also be considered as an OOB channel not controlled by MITM. If the values used during the pairing process have been tampered with by MITM, the six-digit integrity checksum will differ with a probability of 0.999999.

SSP uses four association models. In addition to the two association models mentioned earlier, OOB and numeric comparison models named PasskeyEntry and Just Works are also used.

If a device has input functionality but does not have a screen that can display six-digit numbers, the 'key input association' model is used. On devices with output functionality, a six-digit checksum is displayed to the user, and the user is required to enter this checksum on the device with input functionality. If both devices have input functionality but no output functionality, the 'key input' association model can also be used. In this case, the user selects a six-digit checksum and enters it into both devices. Finally, if at least one device has neither input nor output capabilities and cannot use OOB.

Finally, regarding SSP, it mainly consists of six stages:

1. Capability exchange: For devices that have never thought of pairing for some reason, the first step is to exchange their input/output (IO) capabilities to determine the correct association model to use.

2. Public key exchange: Devices generate their public-private key pairs and send each other their public keys. They also calculate the Diffie-Hellman key.

3. Authentication stage 1: The protocol running in this stage depends on the association model. One of the goals of this stage is to ensure that there is no MITM communication between devices. This is achieved by using a series of random numbers, commitments to the random numbers, and a final check for integrity through out-of-band (OOB) channels or checksums performed with user assistance.

4. Authentication stage 2: In this stage, the protocol running depends on the association model. One of the goals of this stage is to ensure that there is no MITM communication between devices. This is achieved by using a series of random numbers, commitments to the random numbers, and a final check for integrity through out-of-band (OOB) channels or checksums performed with user assistance.

5. Link key calculation: Both parties use their Bluetooth addresses, the values previously exchanged, and the Diffie-Hellman key constructed in stage 2 to calculate the link key.

6. LMP authentication and encryption: In this stage, an encryption key is generated, which is the same as the final pairing step in Bluetooth versions below 2.0 + EDR.

4. Information security regulations applicable to Bluetooth

In the information security regulations issued by Qingji in December 2020, the following standards apply to Bluetooth:

General Technical Requirements for Vehicle Information Security

Technical Specification for Information Security Evaluation and Testing Technology of Intelligent Networked Vehicles

Information Security Technology Requirements and Experimental Methods for Onboard Information Interaction Systems

Information Security Technology Requirements for Onboard Network Devices (Information Security Technology)

Information Security Technology Requirements for Onboard Information Security of Intelligent Networked Vehicles (TCSAE101-2018)

Road Vehicle Software Update Management Standard (ISO 24089)

Guidelines for Bluetooth Security in Information Security Technology (GB/T 386480-2020)