Preshared Keys for Secure Connection OOB Pairing


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 ( 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.


Best regards

Tobias Moser

Parents Reply Children