Restricting some GATT characteristics to a bonded device

RE: Restricting some GATT characteristics to a bonded device

BillB — Wed, 19 Jun 2024 08:19:16 GMT

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

RE: Restricting some GATT characteristics to a bonded device

Hieu — Tue, 18 Jun 2024 12:43:21 GMT

Hi Bill,

[quote user="BillB"]What's harder to fake (especially in LE secure connections) is the actual encryption key in use, but I haven't read anything that says the stack is checking that key matches the one in the bond list and the links you've given don't have a way for me to check that in my own app.[/quote]

But if your device is advertising with Resolvable Random Private Address, then only the bonded peer with the agreed Identity Resolving Key can identify it and initiate a connection.

[quote user="BillB"]I.e. I can't see anything that would prevent an attacker (that wasn't present at the initial bonding) from just spoofing the MAC and then negotiating a new key for the session.[/quote]

Using Just Works, there is also nothing stopping a MITM from getting the agreed key. They don't even have to fake being the device and getting a new key.

At the end of the day, vulnerability to MITM is an inherent issue when you use Just Works pairing. There is simply no way around it. Some secrets must be agreed on a different physical channel to defend against the MITM.

I discussed some alternatives in a recent ticket: Using Just Works mode with MITM protection.

RE: Restricting some GATT characteristics to a bonded device

BillB — Mon, 17 Jun 2024 03:50:51 GMT

Hi Hieu,

E.g. I've been experimenting with struct bt_conn_auth_cb but not sure which is the best
It actually seems like the best option to me.

Just that there's a lot of callbacks in the structs and which ones are set seems to determine the IO capabilities and therefore the auth procedure and I find the wording in the doc a but vague on the implications.

I think maybe pairing_accept() is the right one, but pairing_confirm() seems interesting too?
And then there's the BT_CONN_CB_DEFINE() ones, if I can rely on only one device being connected at a time.

Anyway I'll do some more experiments in the next couple of days and get back to you.

but does it have any other IO capabilities for an Out-of-Band method

Nothing obvious that I can see, e.g. there's no NFC or other way to talk to a phone except something crazy like pointing the phone camera at a LED. But I'll have a think.

You can check if the current peer address is in the list of bonded devices.

But that's the key question that's driving this - the doc is only talking about addresses, which can be faked easily.
What's harder to fake (especially in LE secure connections) is the actual encryption key in use, but I haven't read anything that says the stack is checking that key matches the one in the bond list and the links you've given don't have a way for me to check that in my own app.
I.e. I can't see anything that would prevent an attacker (that wasn't present at the initial bonding) from just spoofing the MAC and then negotiating a new key for the session.

The only thing I can think of is that key negotiation is probably considered a "pair" and might still trigger one or more of the bt_conn_auth_cb calls even in JustWorks, and it those calls are _not_ triggered when a bonded device reuses the bond key (i.e. if a previously bonded device coming back in range is not a "pair") then we might be OK. But the doc isn't explicit on this so I'll still be nervous about it even if my experiments look good.

I might end up having to read the full BLE spec, stack source, and maybe pentesting it, but it just feels like what I'm trying to do here must have been done before and that if it was actually a problem there'd be papers written on it already. I mean the UI is basically the BLE equivalent of one of the Bluetooth Classic dongles or hands-free and those _do_ have issues but I thought BLE was supposed to have fixed them?

RE: Restricting some GATT characteristics to a bonded device

Hieu — Thu, 13 Jun 2024 21:14:28 GMT

Hi Bill,

[quote user="BillB"]Well I thought that would also prevent a previously bonded device from reconnecting, e.g. if it was out of range and comes back?
This is why I was looking at whitelisting, but best I can tell that's only looking at the MAC, which is spoofable (IRK doesn't prevent that).[/quote]

Right, if you want the bonded peer to always be able to reconnect, it's best to have white-list advertising after the "pairable" window.

[quote user="BillB"]I can tell that's only looking at the MAC, which is spoofable (IRK doesn't prevent that).[/quote]

Yes, this is true but only with Just Works pairing. You mentioned the device not having a display, but does it have any other IO capabilities for an Out-of-Band method? Refer to Bluetooth spec, Vol 3, Part H, Section 2.3.5.1, Selecting key generation method:

[quote user="BillB"]Definitely open to trying ideas like this though - what is the usual way to block all pairing?
E.g. I've been experimenting with struct bt_conn_auth_cb but not sure which is the best option.[/quote]

It actually seems like the best option to me. Do you find something unfitting about it?

[quote user="BillB"]Yeah, I wondered if there might be a way to check the connection state (is it bonded) during the callback, I'll look into it some more.[/quote]

There is. You can check if the current peer address is in the list of bonded devices.

See:

https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/zephyr/connectivity/bluetooth/api/connection_mgmt.html#c.bt_conn_get_dst
https://docs.nordicsemi.com/bundle/ncs-2.6.1/page/zephyr/connectivity/bluetooth/api/gap.html#c.bt_foreach_bond

RE: Restricting some GATT characteristics to a bonded device

BillB — Thu, 13 Jun 2024 00:01:18 GMT

Hi Hieu,

Thanks for the response. Yes I did wonder if I was overthinking this, seems like something that should be solved already.

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

Well I thought that would also prevent a previously bonded device from reconnecting, e.g. if it was out of range and comes back?
This is why I was looking at whitelisting, but best I can tell that's only looking at the MAC, which is spoofable (IRK doesn't prevent that).

Definitely open to trying ideas like this though - what is the usual way to block all pairing?
E.g. I've been experimenting with struct bt_conn_auth_cb but not sure which is the best option.

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

Well there's no display or other output that seems usable to inform the user that there's a pairing request.
So ideally I'd like to let the bonded device back in without user interaction.

try using the read and write callbacks

Yeah, I wondered if there might be a way to check the connection state (is it bonded) during the callback, I'll look into it some more.

RE: Restricting some GATT characteristics to a bonded device

Hieu — Wed, 12 Jun 2024 21:29:37 GMT

Hi Bill,

[quote user=""]

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.

[/quote]

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