Specify a password table for the pair

I'm using nrf52832 developing my application.

In the past I used sd_ble_opt_set() to set a static pairing code for pairing.

But now a new requirement has emerged, I need to write a set of 20 6-bit ASCII character passwords from uart/nus into a static pairing code, and when the Bluetooth connection is paired, any password input by the peer end can pass the verification and enter the pairing success event.

I'm not sure if nrfSDK17 support.Or maybe I can find a BLE event handler that compare passkeys,so that I can add the way to arrive it?

Parents
  • Hi,

    Bluetooth only use a 6 digit passkey, and this is per specification and cannot be changed (other than that you can opt to not use a pass key or use numeric comparison, which is still 6 digits). As wha tyou describe is not part of BLE, it would have to be implemented entierly in the applicaiton layer (it would then not be linked to pairing/bonding, but a separate layer tat you add). I cannot provide any specific recomendations, but I would say that in general making your own security is complex and prone to errors, so this requiers carefull consideration on your end on how to design and implement this (and if it is a good idea in the first place).

    PS: As you describe static passkey being used originally I sould also add that static passkey in Bluetooth can be easily brute forced, and does not contirbute to security. In ordre for passkey to provid esecurity (protect againt main in the middle attacks), you needs to generate a new random passkey every pairing attempt.

Reply
  • Hi,

    Bluetooth only use a 6 digit passkey, and this is per specification and cannot be changed (other than that you can opt to not use a pass key or use numeric comparison, which is still 6 digits). As wha tyou describe is not part of BLE, it would have to be implemented entierly in the applicaiton layer (it would then not be linked to pairing/bonding, but a separate layer tat you add). I cannot provide any specific recomendations, but I would say that in general making your own security is complex and prone to errors, so this requiers carefull consideration on your end on how to design and implement this (and if it is a good idea in the first place).

    PS: As you describe static passkey being used originally I sould also add that static passkey in Bluetooth can be easily brute forced, and does not contirbute to security. In ordre for passkey to provid esecurity (protect againt main in the middle attacks), you needs to generate a new random passkey every pairing attempt.

Children
No Data
Related