**1. Introduction**

As part of my bachelor’s thesis published in 2020 in information technology, I investigated a largely unknown weakness in a Bluetooth Low Energy (BT-LE) pairing process and developed a concept to prove it in practice. This concept could be tested with software that was also developed during the bachelor’s thesis.

The basis for this is a document[1] by Mr. Tomáš Rosa, who claims that a mathematical function for calculating confirmation parameters can be bypassed. He refers to the corresponding “Confirm value generation function”, which was first defined in the Bluetooth Core Specs. v.4.0 with BT-LE. It serves to ensure the authentication of both participants during the pairing of two BT devices. Unfortunately, the document is very compact and there is no comprehensive mathematical proof or practical evidence to support his thesis.

According to some research, this issue in particular has not been addressed by anyone since the publication of Rosa’s document in 2013. This is confirmed by all BT specifications that have been published since then, as the function and its parameters for calculating and checking confirmation parameters defined with the PassKey-Entry pairing method have remained unchanged. There is also no practical proof, tool or entry in the CVE database for this vulnerability. This gave rise to the idea of working through his findings and making them the subject of my thesis.

In the blog post, I present the results of my thesis in short form. In the end, the vulnerability was practically exploited and all tested devices of all BT-LE versions (v4.0-v5.1) are affected. As soon as a device supports the pairing method PassKey-Entry in the master role, the attack is possible.

## 2. Basics

### 2.1 PassKey-Entry Pairing

This is a pairing method for BT that establishes a authenticated connection between two BT-LE devices. The following picture shows the pairing sequence:

Pairing-Steps (After negotiation of the pairing method):

- Master and slave create a random value each (Master his M
_{rand}; Slave his S_{rand}). - The master creates a TK (PIN e.g. ‘123456’) and presents it on his display.
- The slave must see the PIN to enter it on his device and set it as his TK (If so, both use the same TK for the following steps.).
- Both now create an independent confirm value under the usage of the following formula (3). (Master his M
_{confirm}; Slave his S_{confirm})

(1) ??????? = ?1(??,?,????,????,???,???,??,??)

(2) ?1 = ???_{??}[???_{??}( ? ⊕?1)⊕?2]

(3) (?|?)??????? = ???_{??}[???_{??}( (?|?)???? ⊕?1)⊕?2]

The parameters p1 and p2 are known on both sides after the initial “Pairing-Feature-Exchange”.

- As you can see in the flowchart, the parameters are exchanged as shown.
- M
_{confirm}form master to slave - S
_{confirm}from slave to master - M
_{rand}from master to slave

- M
- Now the slave can check whether it has the same PIN as the master. The slave checks it with formula (3) and compare it with the received M
_{confirm}.

(3) ???????? ?= ???_{??}[???_{??}(????? ⊕?1)⊕?2]

If the comparison is true, the pairing continues.

- The slave now sends his S
_{rand}to the master. - Now the master can check whether it has the same PIN as the slave. The master check it with formula (3) and compare it with the received S
_{confirm}.

(3) S??????? ?= ???_{??}[???_{??}(S???? ⊕?1)⊕?2]

If the comparison is true, the pairing continues.

- Now the pairing and authentication between master and slave is finished.

### 2.2 The “Confirm-Value-Generation” Function

The “Confirm-Value-Generation” Function (c1, formula (2)) is used to calculate the M|S_{confirm} parameters during the pairing process. The confirm-values are needed to check whether both sides have the same TK (PIN). Only if the slave sees the PIN on the master’s display, he can set the right TK on his device. With this, the authentication between master and slave is done. At first glance, it is not possible to change the equation so that we can calculate S_{rand}. Why S_{rand}? Let’s assume we (as an attacker) are the responder (the slave) of the pairing.

- To successfully bypass the authentication, we need TK. For the simple reason that we need the parameter to calculate the STK after the pairing for the following data encryption.
- We can’t calculate TK until we have received M
_{rand}and M_{confirm}. - After we received M
_{confirm}we have to send S_{confirm}. But we can’t calculate a valid S_{confirm}without TK ☹. - After we received M
_{rand}, we can calculate the missing TK with formula (3). We brute-force any possible value for TK (‘000000’ – ‘999999’), until the equation gives a true statement. (Max. 10^{6 }calculations, ~<3s runtime with simple C code) - Now we have the right TK, but we sacrificed a wrong S
_{confirm}to get the M_{rand}☹. **The only chance we have is to manipulate the S**. If it fails, the master will break the pairing._{rand}parameter to affect the confirm-value check on the master’s side

This is where the **vulnerability **becomes important:

It’s possible to calculate S_{rand} with the parameters S_{confirm} (that we had to choose randomly) and TK (that we had brute-forced) so that the equation:

S??????? ?= ???_{??}[???_{??}(S???? ⊕?1)⊕?2]

gives a true statement on the master’s side.

## 3. Exploit

As mentioned in chapter 2.2, the “Confirm-Value-Generation” function can be misused to bypass the pairing authentication.

The problem is, that the equation can be changed to the parameter S_{rand} so that the following applies:

????? = ???_{??}^{−1}[???_{??}^{−1}(????????)⊕?2]⊕?1

### 3.1 Procedure of the Attack

The following flowchart shows the attack process graphically.

**Please note:**

Formula 1 is:

(1) S??????? = ???_{??}[???_{??}(S???? ⊕?1)⊕?2]

Formula 2 is:

(2) ????? = ???_{??}^{−1}[???_{??}^{−1}(????????)⊕?2]⊕?1

The exploit goes as follows:

- The attacker poses as an inconspicuous BT device (e.g., a BT speaker) and offers this inconspicuous service to the devices within range.
- It now waits until a victim wants to pair with the attacker’s device.
- The pairing runs as defined for the victim of the connection and he sends his calculated M
_{confirm}to the attacker. - Next, the attacker can only send a random S
_{confirm}to the victim, but this does not harm the success of the pairing. - Now the victim sends his random value M
_{rand}to the attacker. - The attacker can now calculate the PIN (TK), which is still unknown to him, by brute-forcing and using the formula (1) and the known parameters M
_{confirm}, M_{rand}, p1 and p2. - The attacker can now calculate a value for S
_{rand}using the calculated TK and formula (2). For the parameter S_{confirm}he uses his S_{confirm}, which he chose randomly and sent to the victim in the fourth point. - The attacker now sends the calculated S
_{rand}to his victim. - The victim will now check whether the S
_{confirm}obtained in point four is valid. To do this, he calculates its own value for S_{confirm}using the formula (1), the known parameters p1 and p2, and the value S_{rand}just received from the attacker. - If the formula (2) is correct, both values will be identical for S
_{confirm}and the victim will accept the value and continue the pairing.

It turns out that the formula (1) can be changed to formula (2) as suspected and thus the exploit is executable.

Using this procedure, authentication can be completely bypassed during PassKey-Entry pairing.

### 3.2 A software for Exploiting

As part of the practical proof, I developed a C program, which can be used to prove and test the vulnerability.

Now an attacker would have access to all BT-LE services that explicitly require authentication during pairing.

[1] *Cryptology ePrint Archive* von https://eprint.iacr.org/2013/309.pdf

- Bypass PassKey-Entry Authentication in BT-LE - 26. May 2021