Pairing Random half zeros

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MaPr_2402061
Level 1
Level 1

Hi,

I'm using CySmart 1.3 with the CySmart BLE 4.2 USB Dongle (FW 1.2.2.32 / HW 2.0.0.0).
I'm pairing with different peripheral devices (JustWorks, LE Legacy Pairing) and sniffing the connection with BTLEjack.

I have found that the "Pairing Random" sent by the Master (the CySmart Dongle) does contain only 8 bytes of presumably random data. The other 8 bytes are zero.

e.g.: Random Value: 58dcabe6d25e32760000000000000000

Do you have any idea what caused this behaviour?

Even though the Random Value is not important when using the JustWorks Method, I still find this behaviour strange...

EDIT:

This also happens when pairing in Secure Connections Mode (ECDH)

EDIT2:

This also happens when using the CySmart BLE 4.1 USB Dongle (FW 1.2.1.21 / HW 1.0.0.0)

cheers,

Matthias

0 Likes
9 Replies
GyanC_36
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

The hardware generates a random number on start of the pairing procedure which will be used in later stages of pairing ( calculating CONFIRM values).  This is just  a number generated by hardware and nothing related to pairing methods ( Just work or anything ).

Do you see any pairing failure issues ?

For more details on pairing procedure , please refer BLE core specification - https://www.bluetooth.com/specifications/bluetooth-core-specification

-Gyan

0 Likes

Hi Gyan,

I'm not talking about the RNG of the BLE-Controller. I'm also not talking about the HCI-Functionality.

I'm referring to the SMP "Pairing Random" Command (Bluetooth 5 Core Spec, Vol. 3: Core System Package [Host Volume], Part H: Security Manager Specification, 3.5.4 Pairing Random).

It's used for the Commitment Scheme during LE Legacy Pairing (Not very important for "JustWorks", but quite important for PassKey pairing), and for the DH Key Check during LE Secure Connections Pairing.

I'll try to deliver more evidence after the weekend, but If you can get one of your engineers to recreate my "setup" and sniff what's being sent over the air during pairing, that would be great.

Maybe there's a way to catch the HCI traffic to the CySmart BLE USB Dongle? It should be easier to sniff the SMP Packets there instead of grabbing them off the air.

Thanks for the quick reply, though!

Matthias

0 Likes

Hello Matthias,

    I understood what do you mean by 'Pairing Random' command in LE Legacy pairing. I am not sure from where are you referring that "Not very important for "JustWorks", but quite important for PassKey pairing), and for the DH Key Check during LE Secure Connections Pairing".

For all the pairing methods in Legacy pairing ( Just work, passkey, OOB)  , this random value ( Mrand/Srand) is generated / exchanged  by both master and slave devices and used to calculate the CONFIRM values in both sides.

                                         Airlogs.PNG

                                            JustWork.PNG

                                            PassKey.PNG

                                            

The only thing which changes in different LE Legacy pairing is TK ( Temporary Key) which is either Passkey or OOB key.

In Secure Connection Na/Nb are the random number generated by Master and Slave device.

Please let me know if it makes sense for you or you are thinking otherwise.

-Gyan

0 Likes

Hi Gyan,

thanks for the detailed answer - I think we're mostly on the same page

I'll stick to LE Legacy Pairing for the sake of simplicity now:

The Commitment Scheme consisting of the exchange of the Confirmation Values and the subsequent exchange of Mrand/Srand serves as a method for both sides to confirm that they know the TK without disclosing it. This should prevent a MITM attack, but requires Mrand/Srand to be unpredictable by an attacker.

Simple example:

I'm a malicious Slave device, trying to get the Master pair with me instead of the real Slave device.
If I can predict the Mrand, I can recover the TK after having received Mconfirm and proceed a successful, authenticated pairing.

Now, this doesn't matter with JustWorks, since the TK is known anyway and there's no actual need for the PairingConfirm/PairingRandom exchange, from a security point of view. The randomness of Mrand/Srand is not important here.

If the PassKey Pairing is used for authentication, a predictable [M/S]rand can enable an attacker to calculate the TK and impersonate the real device.

But apart from all the cryptographic theory: The Spec states under "2.3.5.5 LE Legacy Pairing Phase 2":

The initiating device generates a 128-bit random number ( Mrand ).

Why is the CySmart Software only using a 64-bit random number instead?
Even if this is just for debugging and evaluation, I find this quite confusing.

Thanks!

0 Likes

Hi,

I'm sorry if I haven't been clear enough, but this question is still in my mind.

Why is one half of the pairing random value zero?
You have even underlined it in your Frontline screenshot.

Kind Regards,

Matthias

0 Likes

Any news on this?
I'm thinking of filing a CVE, since this looks like a security issue to me...

0 Likes

Hello Matthias,

   We have forwarded your query to concerned team and will update once we get a response on the same.

-Gyan

0 Likes

Any news?

It looks to me as if your BLE Stack has a security issue, namely the pairing random value being just 64 bits instead of 128 bits long.
This compromises the BLE security of every device with your BLE ICs.

I consider this a serious security issue.

0 Likes

Any  news on this?

It seems as the RNG used for the pairing random values of your CySmart Dongle's BLE Stack is broken.

I haven't seen this issue with your actual PSoCs BLE Component yet.

In any case, it would be nice if you could at least properly respond to this security issue.

Just to be very clear:

Please refer to this (your) screenshot:

Airlogs.PNG

Half of the (underlined) random number is zero. I can confirm this with the CySmart Dongle I have here.

This is a security issue and a violation of the Bluetooth Specification.


There hasn't been a FW upgrade since March 2018, according to this site:
https://www.cypress.com/documentation/software-and-drivers/cysmart-bluetooth-le-test-and-debug-tool

0 Likes