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

[BillB]

Hi Hieu,

I really appreciate your time, thank you.

Some of this isn't adding up with experience I've had in other protos (I'm new to BLE, but have just enough experience with crypto to be skeptical/terrified of everything ;-) )

Anyway I tried out pairing_accept() and it seems to do roughly the right thing, so I think I'm going hope this is all implemented correctly and close this ticket off for now.

Then later in the project I'll decide if I care enough and if so do the deep dive, if I find anything I can post again.

Cheers!

P.S. the things still scaring me are:

• In my mind there's a huge difference between a MITM attacker injecting themselves in possibly controlled conditions during the bond procedure (which I agree can't be helped in JustWorks) vs the attacker following the victim around 24/7 to keep up the charade (which could be detected as soon as they screw up)
  So the question is "Would it be detected?" and I think the answer might turn out to be "only if the stack enforces Diffie-Hellman and does some additional checks"
• Right now I don't think the attacker needs the IRK to connect - they can just try connecting to every device in range - but there could be a detail in the proto I'm missing
• It's hard to be sure that the stack is always going to call the API hooks in the right way no matter what tricks they're pulling, need to read the code