LESC Static OOB?

RE: LESC Static OOB?

Emil Lenngren — Sun, 10 Nov 2024 14:19:52 GMT

You skip the Security Manager Protocol entirely and install the LTK directly. I'm not super familiar with the SDK here but it seems you can use the `bt_keys_store` function, which is otherwise used by the SMP module when pairing finishes. See https://github.com/nrfconnect/sdk-zephyr/blob/main/subsys/bluetooth/host/keys.h#L188. You can do your ECDH exchange over some custom GATT characteristic or L2CAP CoC.

See https://devzone.nordicsemi.com/f/nordic-q-a/112415/connection-using-old-pairing-information-saved/491888 for an example. Note that you should simulate (mark) that the key was generated using LESC, so set the `keys` field to `BT_KEYS_LTK_P256`, `flags` to `BT_KEYS_SC`, `enc_size` to `BT_SMP_MAX_ENC_KEY_SIZE` and ediv and rand to 0.

RE: LESC Static OOB?

Jeremy — Sun, 10 Nov 2024 13:52:39 GMT

That first suggestion makes sense conceptually, but how would that be implemented with NCS? Would you just make a new simplified security manager to handle that process and set up the connection, or is there a way to use the SDK's 'smp' module and set your own LTK?

RE: LESC Static OOB?

Emil Lenngren — Sat, 09 Nov 2024 13:05:46 GMT

If you control both sides, why don't you just skip the standard BLE pairing step altogether and generate LTK in your own way?

If the two devices initially share a 16 byte secret S (as I assume they do from your question), you can generate an LTK by first performing ECDH resulting in shared secret E, then let the LTK be for example HMAC(S, E). That way you get forward secrecy.

Another way would be to use standard LESC numeric comparison. You can encrypt the 6 digits that are supposed to be shown on the display with your shared key and some AEAD cipher, send it over BLE characteristic to the other device. After decrypting it, accept if correct. Same in the other direction. Just make sure the Additional Data is different for every direction to avoid reflection attack.

RE: LESC Static OOB?

Jeremy — Fri, 08 Nov 2024 20:09:48 GMT

'bt_le_oob_get_local' fetches the bt_le_oob object generated behind the scenes, and if BT_TESTING and BT_OOB_DATA_FIXED are set it overrides that random generation with a fixed value, but a 'bt_le_oob' is both a random value, and a confirm value that is related to the random value and the generated public key.

'Local' and 'Remote' are cross wired so even if only one piece of OOB data is being exchanged, it is local to one device, and remote to the other, and for the remote device the expected confirm value is the one based on the peer public key, not the one internally generated. Even if both devices are running DATA_FIXED to see the same random value, they will have different confirm values that are not interchangeable.

If you were to push that example to escalate the connection to security level 4, I believe it would fail validation of the OOB data even if the random value matches. At least that was my experience until I started generating the confirm values using the remote public key.

My example is fully working, it just requires changes to the SDK that will get a bit more complicated if I ever need to handle more then one connection.

RE: LESC Static OOB?

Hung Bui — Thu, 07 Nov 2024 09:23:11 GMT

Update: I see your previous replied that you mentioned it couldn't work. I will have to check it out but we don't have a NFC reader to test with the central_nfc_pairing so it can be difficult. My suspicion is that you may need to make sure it's only one way communication and on the other side you need to set the random value to 0.

RE: LESC Static OOB?

Hung Bui — Thu, 07 Nov 2024 09:09:30 GMT

Hi Jeremy,
Sorry for the late reply.
I did a quick test here with the peripheral_nfc_pairing sample and I can see that I have the same local random oob (1 2 3 4 5 ...) as expected from the code in smp.c :

here is where I printed it out:

I simply added this in to prj.conf:

CONFIG_BT_OOB_DATA_FIXED=y

CONFIG_BT_TESTING=y

My assumption is that having a hardcoded r value is all it need to be able to do the static OOB ? And you don't have to calculate the sc key on your own in the application as you showed in the last reply ?

RE: LESC Static OOB?

Jeremy — Mon, 04 Nov 2024 21:46:35 GMT

Got it working!

Tested a bit and I believe that 'LOCAL_ONLY' will only work if the other side is expecting the connection to be 'REMOTE_ONLY', which still requires some transfer of data between the two devices. In the hids example for instance, one part of the setup is to copy the random/confirm values from the central device.

However, before the OOB data check, both devices do exchange public keys, and all you need to generate a 'confirm' value is a public key and the right 16 'random' bytes.

I did need to poke two holes into smp.c; one to fetch the locally generated public key for local confirmation, and one for the remote public key associated with the current connection for the remote confirmation. Currently my remote fetch code is cheating a bit and blindly fetching index 0 from the smp pool, but currently I have 'CONFIG_BT_MAX_CONN' set to 1 so this works.

smp.c hacks:

const uint8_t *bt_smp_get_sc_public_key(void)
{
    return sc_public_key;
}

uint8_t *bt_smp_get_pkey(uint8_t smp_index)
{
	return (uint8_t*)&bt_smp_pool[smp_index].pkey;
}

Updated 'oob_data_request' handler. Identical for both sides:

#include "crypto/bt_crypto.h"

// Hacked into the SDK smp.c to fetch the local 'sc_public_key' value
extern const uint8_t *bt_smp_get_sc_public_key(void);
// Hacked into the SDK smp.c to fetch the remote public key for the current connection
extern uint8_t *bt_smp_get_pkey(uint8_t smp_index);

static struct bt_le_oob_sc_data oob_local;
static struct bt_le_oob_sc_data oob_remote;
static const uint8_t static_r[16] = {
    0x01, 0x23, 0x45, 0x67, 0x89, 0xAB, 0xCD, 0xEF,
    0x10, 0x32, 0x54, 0x76, 0x98, 0xBA, 0xDC, 0xFE
};


static void oob_data_request(struct bt_conn *conn, struct bt_conn_oob_info *info)
{
	printk("OOB data requested\n");

    if (info->type != BT_CONN_OOB_LE_SC) {
        printk("OOB type not LE SC, rejected\n");
        return;
    }

	if (info->lesc.oob_config != BT_CONN_OOB_BOTH_PEERS) {
		printk("LESC OOB config not supported (oob_config=%d)\n", info->lesc.oob_config);
		return;
	}

	int err;
	uint8_t * pkey = bt_smp_get_pkey(0);

	// Compute oob_remote 'confirm' value using pkey from the smp_public_key message
	memcpy(oob_remote.r, static_r, 16);
	err = bt_crypto_f4(pkey, pkey, &oob_remote.r, 0, &oob_remote.c);
	if (err) {
		printk("Error generating remote OOB confirm value: %d\n", err);
		return;
	}

	// Computer oob_local 'confirm' value using the public key generated locally for this connection
	memcpy(oob_local.r, static_r, 16);
	err = bt_crypto_f4(bt_smp_get_sc_public_key(), bt_smp_get_sc_public_key(), &oob_local.r, 0, &oob_local.c);
	if (err) {
		printk("Error generating local OOB confirm value: %d\n", err);
		return;
	}

	err = bt_le_oob_set_sc_data(conn, &oob_local, &oob_remote);
	if (err) {
		printk("Error while setting OOB data: %d\n", err);
	}
}

Is there any more elegant way to accomplish this? Or is there some way to infer 'bt_smp_pool' index based on the 'conn' passed into the 'oob_data_request' callback? I could extend the callback to send additional details back, but I'm trying to limit my SDK changes.

Thanks,
Jeremy

RE: LESC Static OOB?

Hung Bui — Mon, 04 Nov 2024 13:00:00 GMT

Hi Jeremy,

We would need to check if the OOB communication is both way or one way only. Normally on our board it's usually BT_CONN_OOB_LOCAL_ONLY meaning the OOB data r&c is to be offered from the nRF52 and being read by the peer.
Could you take a look at this ticket: Factory-pairing two nRF52840

I think it's very similar to what you want to achieve. Please take a look at the peripheral_hids_keyboard.
Could you try to test that example with CONFIG_BT_OOB_DATA_FIXED ?

RE: LESC Static OOB?

Jeremy — Sun, 03 Nov 2024 10:13:53 GMT

So I've done some more digging, and think I'm missing something more basic. I've removed my own attempts to inject a static 'r' value and instead just set CONFIG_BT_TESTING and CONFIG_BT_OOB_DATA_FIXED to 'y' in 'prj.conf'. This appears to effectively do what I was trying to do, only with a fixed-in-the-SDK static value ... and is still failing the same as before.

The new simplified code implemented on both central and peripheral now is:

static struct bt_le_oob oob_local_full;

static void oob_data_request(struct bt_conn *conn, struct bt_conn_oob_info *info)
{
	int err;
	
    if (info->type != BT_CONN_OOB_LE_SC) {
        printk("OOB type not LE SC, rejected\n");
        return;
    }

    printk("OOB data requested\n");
	
	err = bt_le_oob_set_sc_data(conn, &oob_local_full.le_sc_data, NULL);
	if (err) {
		printk("Error while setting OOB data: %d\n", err);
	}
}


int main(void)
{
	...
	
	bt_le_oob_get_local(0, &oob_local_full);

	...
}

With debugging I can confirm this leads to identical 'r' values being seeded onto both devices and being supplied in smp->oodb_local, but they are still returning status 0xB. Any help would be appreciated.

Thanks,
Jeremy