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
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!
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.
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.
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.
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 "188.8.131.52 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.
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.
Any news on this?
I'm thinking of filing a CVE, since this looks like a security issue to me...
We have forwarded your query to concerned team and will update once we get a response on the same.
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.
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:
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: