• State Verified Answer
  • Replies 1 reply
  • Subscribers 73 subscribers
  • Views 475 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 280480
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

What are most common pairing steps?

StefXinet

Dear Nordic,

we are developing FW based on nRF52832, SDK 17.0.2. We have 2 devices:
BLE Central with SD S332 and BLE Peripheral with SD S112. The Peripheral is basically a sensor, the Central is a controller / data analyzer.

Our boards work in an environment with others, but we need to be sure that a specific Peripheral device is sending data to a specific Central device. That's why we need a pairing procedure.

Our 2 boards are very limited in user interface: each Peripheral and Central have only one push button and one rgb LED.

we need to develop a pairing procedure with these constrains:

- the Peripheral must accept connections only from our Central device (we must avoid that the sensor can be read for example by nRF connect APP or similar)

- a Peripheral must be connected to a single Central device. if the user needs to connect to another Central, He must pair the sensor with the other central device

Could you please help us better understand what steps we need to take to ensure this pairing?

Thanks!

Parents
  • +1

    Hello,

    There are many ways this can be done, all have various pros and cons.

    You can for instance provide the two peers with a pre-shared OOB key that is used when initially establishing connection to perform the bonding. Without this OOB key they would not be able to perform bonding, and either side can quickly disconnect the link to allow the next peer to connect that hopefully will have the correct OOB key to perform bonding. The advantage of using OOB key, is that it will follow a standard bonding procedure, so even if you do changes to your application (e.g. firmware update) it is very unlikely this will cause issues. Of course others may still be able to connect, but since they don't have the OOB key they will quickly be disconnected based on my above suggestion. The only way for anyone being able to get the OOB key would be an attacker with in-depth knowledge of your software and hardware, and that have physical access to both, so it may be a more theoretical issue than a realistic scenario, but I mention it in any case since using pre-shared keys are security weakness.

    I made an example here a few years ago on how to do bonding using pre-shared OOB keys:
    https://devzone.nordicsemi.com/f/nordic-q-a/66209/modify-pre-shared-oob-key-for-legacy-connection/270823#270823

    Hope it helps,
    Kenneth

Reply
  • +1

    Hello,

    There are many ways this can be done, all have various pros and cons.

    You can for instance provide the two peers with a pre-shared OOB key that is used when initially establishing connection to perform the bonding. Without this OOB key they would not be able to perform bonding, and either side can quickly disconnect the link to allow the next peer to connect that hopefully will have the correct OOB key to perform bonding. The advantage of using OOB key, is that it will follow a standard bonding procedure, so even if you do changes to your application (e.g. firmware update) it is very unlikely this will cause issues. Of course others may still be able to connect, but since they don't have the OOB key they will quickly be disconnected based on my above suggestion. The only way for anyone being able to get the OOB key would be an attacker with in-depth knowledge of your software and hardware, and that have physical access to both, so it may be a more theoretical issue than a realistic scenario, but I mention it in any case since using pre-shared keys are security weakness.

    I made an example here a few years ago on how to do bonding using pre-shared OOB keys:
    https://devzone.nordicsemi.com/f/nordic-q-a/66209/modify-pre-shared-oob-key-for-legacy-connection/270823#270823

    Hope it helps,
    Kenneth

Children
No Data
Related
Terms of service