Preface: There are two types of paring base on BLE version:

•  LE Legacy Pairing (supported in Bluetooth 4.0 and 4.1)
• LE Secure Connections (introduced in Bluetooth 4.2)

Background: The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.

Do you think this is a fundamental problem or flaw in the product itself? I speculate this is not a new finding, maybe we have seen this problem in BLE before (see below):

A BLE device that wants to share secure data with another device must first pair with that device. The Security Manager Protocol (SMP) carries out the pairing.Responder (in the context of BLE Security Manager), who has already sent their commitment Sconfirm,
Sconfirm =presumably c1(TK, Srand, p1, p2) = AESTK[AESTK(Srand ⊕ p1) ⊕ p2], but who has not revealed their Srand, yet. Due to the lack of binding in c1, such a Responder can still arbitrarily change their “committed” passkey TK and labels p1, p2, since – as we have seen above – the correct Srand for any new value of (TK, p1, p2) can be trivially found by Eq. 2 while keeping the former Sconfirm still the same.

rand = AES-1TK [AES-1TK(C) ⊕ p2] ⊕ p1. (Eq. 2)

I speculate that the product is still using LE Legacy Pairing (supporting Bluetooth 4.0 and 4.1), so presumably this is the root cause.

Vulnerability details: CVE-2022-46400 The Microchip RN4870 module firmware 1.43 (and the Microchip PIC LightBlue Explorer Demo 4.2 DT100112) allows attackers to bypass passkey entry in legacy pairing.

Official announcement: For details, see the link – https://nvd.nist.gov/vuln/detail/CVE-2022-46400