I have a question regarding the Secure Connection (SC) OOB pairing procedure of the softdevice 132. As I'm currently trying to implement a secure pairing (Eavesdropping/MITM) between two devices in which the user has only access to one of them, I stumbled across the OOB pairing using preshared keys (devzone.nordicsemi.com/.../122101). If I use Legacy Pairing for OOB it's straight forward to pass a shared secret to the softdevice, using the sd_ble_gap_auth_key_reply function. However, I would rather use SC Pairing to end up in security mode 1 level 4. The OOB data of SC consists of the address, confirm value and a secret of a device. If I still take advantage of the Diffie-Hellman (DH) key exchange, I run into problems. The confirm value is based on the exchanged public key and must be updated after the DH key exchange, making the check of the confirm values obsolete (as I'm not able to exchange them in-band). Also, the address needs to be updated to the address of the current connecting device, leaving the random value apparently my only choice to insert preshared values. Every device which uses the same random value succeeds the pairing process. But a MITM can compromise the shared secret by following the pairing procedure until he gets the DHKey Check value (Ea/Eb). As all other parameters are known by the MITM at this point and the random value is part of the AES CMAC calculation, he can recover the random value and can successfully connect to the device on the second try.
Is Secure Connection OOB not suited for using preshared keys?
If so, is Legacy Pairing my only option in that case if I want to use the softdevice? It looks like Numeric Comparison does not provide an advantage against MITM if the user has only access to one device and for SC Passkey Entry it is also possible for a MITM to recover a preshared PIN after the commitments are exchanged.
You may find this thread useful:https://devzone.nordicsemi.com/f/nordic-q-a/35856/questions-about-lesc-mitm-and-passkey
I think as long as you don't have access to both peers there will always be a chance of MITM attack if an attacker wants to.
I had a look into your suggested threads. After playing around with the implementation, I successfully managed to setup a pre-shared key pairing for OOB Legacy Pairing. This only accomplishes security mode 1 level 3, which is also fine for my current implementation.
I would be still interested, if a similar approach can be made for the Secure Connection Pairing if the parameters are chosen wisely. But I assume the OOB pairing was not really designed for such purposes.
Thank you for the support.
TobiasM said:I would be still interested, if a similar approach can be made for the Secure Connection Pairing if the parameters are chosen wisely. But I assume the OOB pairing was not really designed for such purposes.
Not that I am aware of no. However it is possible to increase the security mode/level on an already bonded connection, so you may shortly after established security mode 1 level 3, then bond again using LESC, thereby achieve level 4.
That might be a neat workaround. I'll have a look into that.