• State Verified Answer
  • Replies 6 replies
  • Subscribers 65 subscribers
  • Views 258 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328367
Options

Restricting some GATT characteristics to a bonded device

BillB

Hi,

I'm implementing a BLE GATT peripheral that has no display but it does have a button.

I'd like to make some characteristics only available to devices that are BONDED but all of the docs I've read so far talk about pairing, or what I think are equivalent words like "encryption" or "authentication".

E.g. I've found flags like BT_GATT_PERM_WRITE_LESC|BT_GATT_PERM_WRITE_ENCRYPT and some doc about whitelisting, but the descriptions of both suggest they're only looking at the current connection, not whether the connection is to a device from the bond list. And I can't add BT_GATT_PERM_WRITE_AUTHEN because it's got no display.

Anyone have any pointers how to do this? Or am I just misunderstanding the doc?

Seems like I should say why, in case there's another way to do a similar thing.

I don't actually care about MITM for this - it's a wearable and I really only want to make it harder for some random to flatten the battery. Sure MITM could do that but it'd be noticed and they'd have to follow the person constantly.

So really I only care whether whether I'm currently connected to the phone (or potentially MITM) the nRF was bonded to. Plan is to use JustWorks but only allow a bonding to occur for a short period after the button was pressed.

But let's say I've already been through the bonding process with some phone but that phone's now out of range and disconnected. If another device comes along I believe it could initiate a pair and create a link with encryption (but not authentication) but stop before bonding without the user even knowing it happened. It sounds like this would be a gap in the security, even though it doesn't seem actual phones do this.

Thanks,

Bill

Parents
  • 0

    Hi Bill,

    So really I only care whether whether I'm currently connected to the phone (or potentially MITM) the nRF was bonded to. Plan is to use JustWorks but only allow a bonding to occur for a short period after the button was pressed.

    But let's say I've already been through the bonding process with some phone but that phone's now out of range and disconnected. If another device comes along I believe it could initiate a pair and create a link with encryption (but not authentication) but stop before bonding without the user even knowing it happened.

    I am a little confused why you don't limit connection establishment and pairing entirely, but just bonding.

    Also, can you not also setup the device to ask for user's explicit permission before accepting a pairing request?

    A GATT characteristic permission can only limit read/write access on the basis of whether pairing has happened or not, and what level of security such pairing achieves. It doesn't care if the paired peer is also bonded.

    If your device really needs to allow that scenario where a rogue device can pair with it, then perhaps you can see if you can reject an attempt to read/write an attribute based on whether the device is in the list of bonded device or not.

    I haven't checked to be sure, but you can try using the read and write callbacks field when declaring your Characteristic with BT_GATT_CHARACTERISTIC.

    Refer to LBS implementation: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/subsys/bluetooth/services/lbs.c 

    Hieu

Reply
  • 0

    Hi Bill,

    So really I only care whether whether I'm currently connected to the phone (or potentially MITM) the nRF was bonded to. Plan is to use JustWorks but only allow a bonding to occur for a short period after the button was pressed.

    But let's say I've already been through the bonding process with some phone but that phone's now out of range and disconnected. If another device comes along I believe it could initiate a pair and create a link with encryption (but not authentication) but stop before bonding without the user even knowing it happened.

    I am a little confused why you don't limit connection establishment and pairing entirely, but just bonding.

    Also, can you not also setup the device to ask for user's explicit permission before accepting a pairing request?

    A GATT characteristic permission can only limit read/write access on the basis of whether pairing has happened or not, and what level of security such pairing achieves. It doesn't care if the paired peer is also bonded.

    If your device really needs to allow that scenario where a rogue device can pair with it, then perhaps you can see if you can reject an attempt to read/write an attribute based on whether the device is in the list of bonded device or not.

    I haven't checked to be sure, but you can try using the read and write callbacks field when declaring your Characteristic with BT_GATT_CHARACTERISTIC.

    Refer to LBS implementation: https://github.com/nrfconnect/sdk-nrf/blob/v2.6.1/subsys/bluetooth/services/lbs.c 

    Hieu

Children
No Data
Related