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

Error OOB static key NRF connect

Hi all,

I'm using the "ble_app_hrs_paring_nfc" example to setup a static OOB key for pairing with a static longer more secure key. I use this key copied from the example:

#define OOB_AUTH_KEY                 {                            \
                                    {                         \
                                      0xAA, 0xBB, 0xCC, 0xDD, \
                                      0xEE, 0xFF, 0x99, 0x88, \
                                      0x77, 0x66, 0x55, 0x44, \
                                      0x33, 0x22, 0x11, 0x00  \
                                    }                         \
                                 }

And I added this in the on_ble_evt

		case BLE_GAP_EVT_AUTH_KEY_REQUEST:
		PRINTF("BLE:\t OOB Key request\n");

		err_code = sd_ble_gap_auth_key_reply(p_ble_evt->evt.gap_evt.conn_handle, BLE_GAP_AUTH_KEY_TYPE_OOB, m_oob_auth_key.tk);
		APP_ERROR_CHECK(err_code);
		break;

But when I put in the key "AABBCCDDEEFF99887766554433221100" in the NRF connect screen below it fails and gives this status:

"Authentication failed with status BLE_GAP_SEC_STATUS_CONFIRM_VALUE"

image description

Does anyone know what kind of data the NRF connect expects in this screen?

Thanks in advance!

Kind regards,

Michael

Parents
  • Hi Michael,

    my answer comes a little bit late, but I still ran into the same problem and after some testing and good guesses I've managed to deconstruct the issue here. I was using the nRF Connect v3.3.0 app to connect to the nRF52 DK which was using a hardcoded OOB key.

    The OOB value for nRF Connect in hex is: h1h2 .. h16|h17 .. h32 (16 byte)

    The bug causes the software to discard the last 8 bytes h17-h32 and interprets the first 16 hex values as byte values. Also, little endian is applied which leads to the following corresponding TK (again in hex):

    0x0|h16|0x0|h15|..|0x0|h2|0x0|h1

    Further is every hex value a-f interpreted as 0 (letters are always 0). Therefore, we can deduce that you cannot input your chosen key. If you take

    0x05, 0x04, 0x03, 0x02, \

    0x01, 0x00, 0x09, 0x08, \

    0x07, 0x06, 0x05, 0x04, \

    0x03, 0x02, 0x01, 0x00

    instead (note that for the TK you need change the little endian format again), the corresponding OOB key in the Connect app would be 5432109876543210|0 .. 0 but in fact the 0 .. 0 string can be any value.

    I hope this will help everyone who is struggling at this point and hopefully this will get fixed soon, after already 3 years.

    Best regards

    Tobias Moser

Reply
  • Hi Michael,

    my answer comes a little bit late, but I still ran into the same problem and after some testing and good guesses I've managed to deconstruct the issue here. I was using the nRF Connect v3.3.0 app to connect to the nRF52 DK which was using a hardcoded OOB key.

    The OOB value for nRF Connect in hex is: h1h2 .. h16|h17 .. h32 (16 byte)

    The bug causes the software to discard the last 8 bytes h17-h32 and interprets the first 16 hex values as byte values. Also, little endian is applied which leads to the following corresponding TK (again in hex):

    0x0|h16|0x0|h15|..|0x0|h2|0x0|h1

    Further is every hex value a-f interpreted as 0 (letters are always 0). Therefore, we can deduce that you cannot input your chosen key. If you take

    0x05, 0x04, 0x03, 0x02, \

    0x01, 0x00, 0x09, 0x08, \

    0x07, 0x06, 0x05, 0x04, \

    0x03, 0x02, 0x01, 0x00

    instead (note that for the TK you need change the little endian format again), the corresponding OOB key in the Connect app would be 5432109876543210|0 .. 0 but in fact the 0 .. 0 string can be any value.

    I hope this will help everyone who is struggling at this point and hopefully this will get fixed soon, after already 3 years.

    Best regards

    Tobias Moser

Children
No Data
Related