This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Writing OOB Pin to softdevice

Theoretically, if I were to expose a GATT service to let a central write a 128 bit PIN to my characteristic, would I then be able to persist this PIN somewhere in the softdevice so that all other services could starting using OOB as their security level? If so, where? What other settings need to change to support OOB once this is done?

Edit (Jul-1-14): As suggested below, I should throw in that I'm also trying to validate the demand for a way to deliver an OOB PIN to an SoC. (@Ulrich - Thanks for the tip)

Parents
  • Could you expand a bit on the use-case for this? Do you have a device that only support OOB pairing or something?

    1. If you write a static passkey over a connection established by a lesser security level, this passkey will only be as secure as the channel you sent it on (theoretically).

    2. The Bluetooth spec does not distinguish MITM and OOB (aka. "Authenticated Pairing") when it comes to security modes, so it is not currently possible to automatically (i.e. in the stack) deny peers that have paired with MITM access to the attributes protected with Security Mode 1 - Level 3. You can however fail any pairings where the peer does not set the OOB flag, or use read/write authorization and application-based security to look-up if a given bond was created with OOB or not.

    When that is said, very few central devices actually support OOB at the time being. It is meant to be used with actual out-of-band technologies like NFC or USB, as the input sequence is quite bothersome to type in on both devices. Both the S110 and S120 support OOB however, so your theoretical scheme would work, but it might not be as secure as you expected.

Reply
  • Could you expand a bit on the use-case for this? Do you have a device that only support OOB pairing or something?

    1. If you write a static passkey over a connection established by a lesser security level, this passkey will only be as secure as the channel you sent it on (theoretically).

    2. The Bluetooth spec does not distinguish MITM and OOB (aka. "Authenticated Pairing") when it comes to security modes, so it is not currently possible to automatically (i.e. in the stack) deny peers that have paired with MITM access to the attributes protected with Security Mode 1 - Level 3. You can however fail any pairings where the peer does not set the OOB flag, or use read/write authorization and application-based security to look-up if a given bond was created with OOB or not.

    When that is said, very few central devices actually support OOB at the time being. It is meant to be used with actual out-of-band technologies like NFC or USB, as the input sequence is quite bothersome to type in on both devices. Both the S110 and S120 support OOB however, so your theoretical scheme would work, but it might not be as secure as you expected.

Children
No Data
Related