Connection using old pairing information saved

I am running an experiment to use a static keys for pairing information without breaking the existing flow of pairing/bonding.
What I am doing is I am storing the pairing info of my central device and storing it into a structure and then erasing the flash to remove those information, and after reset I am retrieving those bonding information and connecting again using the same central devices but I am getting "Peer removed bonding info" response on my phone.

void store_ltk_in_zephyr(void)
{
    int id, err;
    struct bt_keys pairing_info = {
    .addr = {
        .type = BT_ADDR_LE_PUBLIC,
        .a.val = {0x43,0x82,0x5E,0xC7,0xE8,0xF4,0xFD}
    },
    .irk = {0x8A, 0x27, 0x1E, 0xA7, 0x92, 0x2A, 0xF0, 0x15, 0x41, 0x69, 0x48, 0xDD, 0xC0, 0x7E, 0xDD, 0xF7},
    .ltk = {
        .val = {0xc0, 0xe6, 0x9a, 0x0a, 0xf7, 0x4b, 0xdc, 0xb7, 0x7d, 0x23, 0xf4, 0xb4, 0x89, 0x8d, 0x96, 0x02},
        .ediv = {0x00,0x00},
        .rand = {0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00},
      }
    };

    // Store the keys using the settings API
    err = bt_keys_store(&pairing_info);
    if (err) {
        printk("Failed to store keys (err %d)\n", err);
    } else {
        printk("Keys stored successfully\n");
    }
}

In main, I am calling like this to load the info onto the flash-

  settings_subsys_init();
  //smp_bt_register();
	bt_conn_auth_cb_register(&auth_cb_display);
  bt_conn_auth_info_cb_register(&conn_auth_info_callbacks);
	err = bt_enable(NULL);
	if (err) {
		printk("Bluetooth init failed (err %d)\n", err);
    k_sleep(K_MSEC(100));
		err = bt_enable(NULL);                                      //Trying one more time after this system reset
    if(err) NVIC_SystemReset();
	}
  store_ltk_in_zephyr();
  if (IS_ENABLED(CONFIG_SETTINGS)) {
    settings_load();
  }

And on connect I am using like this-

  bt_conn_set_security(conn, BT_SECURITY_L1|BT_SECURITY_FORCE_PAIR);

Do let me know, how can I connect with the same bonding info which I have made a copy of from the same bonding structure.

Top Replies

Vidar Berg 2 months ago in reply to Gaurav +1 verified

It may be overwritten by the nRF5 SDK bootloader during DFU if the data is outside of the reserved application data region. https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/lib_bootloader.…

Parents

0 Vidar Berg 3 months ago

Hello,

To troubleshoot this, I recommend you start by enabling CONFIG_BT_LOG_SNIFFER_INFO to have the keys printed on boot. This would help confirm us confirm if they keys were successfully stored or not.

Best regards,

Vidar
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Gaurav 3 months ago in reply to Vidar Berg

I am reading the pairing info using nrfjprog --memrd 0xfe000 -n 1024, as I know its taking the info from the settings page and the address of the page is this -

Not getting any logs related to bonding on boot using CONFIG_BT_LOG_SNIFFER_INFO.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Gaurav 3 months ago in reply to Vidar Berg

I have made this work now and saving in a memory address which after migration doesnt gets affected and I am able to read from the memory but somehow I am again to the start of the problem, getting "PEER removed pairing info".

Below is the implementations- I have read the memory and found its matching with the info stored.

static void pre_shared_bond_set(void)
{
	int err;
	int bond_num = 0;
	struct bt_keys *pairing_info;

	bt_foreach_bond(BT_ID_DEFAULT, bond_cb, &bond_num);

	if (bond_num) {
		return;
	}

	bt_addr_le_t addr = {
	    .type = BT_ADDR_LE_PUBLIC,
	    .a.val = {0x43,0x82,0x5E,0xC7,0xE8,0xF4}
	};

	struct bt_ltk ltk = {
	    .val = {0xcb, 0xea, 0xd5, 0xea, 0xe1, 0xab, 0x7c, 0x36, 0x91, 0x1b, 0xe7, 0xd3, 0x31, 0xd1, 0xf8, 0xbc},
	    .ediv = {0},
	    .rand = {0}		
	};

	struct bt_irk irk = {
		.val = {0xF7, 0xDD, 0x7E, 0xC0, 0xDD, 0x48, 0x69, 0x41, 0x15, 0xF0, 0x2A, 0x92, 0xA7, 0x1E, 0x27, 0x8A},
		.rpa.val = {0}		
	}; 

  /**Copying the retrieved values from the memory onto the relevant array to pass the pairing infos*/
  memcpy(addr.a.val,keys_addr,6);
  memcpy(irk.val,irk_val,16);
  memcpy(ltk.val,ltk_val,16);
  // memcpy(ltk.ediv,ltk_ediv,2);
  // memcpy(ltk.rand,ltk_rand,8);

	pairing_info = bt_keys_get_addr(0, &addr);
	if (pairing_info == NULL) {
		printk("Failed to get keyslot\n");
	}
  printk("LTK value \n");
  for(uint8_t i=0;i<16;i++)
  {
    printk(" %02x",ltk.val[i]);
  }
	memcpy(&pairing_info->ltk, &ltk, sizeof(pairing_info->ltk));
	memcpy(&pairing_info->irk, &irk, sizeof(pairing_info->irk));

	pairing_info->flags = 16; //SMP_FLAG_SC
	pairing_info->enc_size = 16;
	pairing_info->keys = BT_KEYS_IRK | BT_KEYS_LTK_P256;

	err = bt_keys_store(pairing_info);
    if (err) {
        printk("Failed to store keys (err %d)\n", err);
    } else {
        printk("Keys stored successfully\n");
    }

}

void retrieve_pairing_keys(void)
{
  const volatile uint32_t *ptr = (const volatile uint32_t *)(0xf5100); //Workaround to read back the pairing info from the old SDK
  memcpy(irk_val,((uint8_t*)ptr),16);
  memcpy(keys_addr,((uint8_t*)ptr+16+1),6);
  memcpy(ltk_val,((uint8_t*)ptr+16+6+1),16);
  //memcpy(ltk_ediv,((uint8_t*)ptr+16+6+16+1),2);
  //memcpy(ltk_rand,((uint8_t*)ptr+16+6+16+2+1),8);
  printk("Successfully copied pairing info from the memory\n");
}

Logs-

00> Watchdog is getting fed here : adv 0 and conn 1
00> Connected
00> [00:00:35.289,337] <dbg> bt_smp: smp_send_security_req: 
00> [00:00:35.289,520] <dbg> bt_keys: bt_keys_get_addr: F4:E8:C7:5E:82:43 (public)
00> [00:00:35.289,703] <dbg> bt_smp: smp_init: prnd 8ea5292745f0b134613f0187006f8a2e
00> [00:00:35.457,733] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x200042b0 conn 0x20003e58 handle 0 encrypt 0x00 hci status 0x06
00> Security failed: F4:E8:C7:5E:82:43 (public) level 1 err 2
00> [00:00:35.577,758] <dbg> bt_smp: bt_smp_disconnected: chan 0x200042b0 cid 0x0006
00> MTU exchange failed (err 14)[00:00:35.578,125] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
00> [00:00:35.578,308] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
00> Disconnected (reason 0x13)

This is the memory region of the flash-

0 Gaurav 3 months ago in reply to Gaurav

Getting this in the HCI log-

00> Bluetooth initialized
00> [00:00:00.042,877] <dbg> bt_id: set_random_address: D3:C4:88:DC:F4:8D
00> [00:00:00.042,877] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2005 param_len 6
00> [00:00:00.042,907] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20034930
00> [00:00:00.042,938] <dbg> bt_hci_core: bt_hci
00> [00:00:13.049,743] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x0a), len (31)
00> [00:00:13.049,774] <dbg> bt_hci_core: bt_recv: buf 0x200344e4 len 33
00> [00:00:13.049,896] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
00> [00:00:13.049,926] <dbg> bt_hci_core: rx_work_handler: buf 0x200344e4 type 1 len 33
00> [00:00:13.049,926] <dbg> bt_hci_core: hci_event: event 0x3e
00> [00:00:13.049,957] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0a
00> [00:00:13.050,323] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: status 0x00 handle 0 role 1 peer F4:E8:C7:5E:82:43 (public-id) peer RPA 6A:42:04:06:EF:A4
00> [00:00:13.050,567] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: local RPA 00:00:00:00:00:00
00> [00:00:13.050,598] <dbg> bt_adv: bt_le_adv_resume: Host cannot resume connectable advertising (-12)
00> [00:00:13.050,659] <dbg> bt_smp: bt_smp_accept: conn 0x20003e58 handle 0
00> [00:00:13.050,689] <dbg> bt_smp: bt_smp_connected: chan 0x200042b0 cid 0x0006
00> [00:00:13.050,964] <dbg> bt_keys: bt_keys_find_addr: F4:E8:C7:5E:82:43 (public)
00> Watchdog is getting fed here : adv 0 and conn 1
00> Connected
00> [00:00:13.051,788] <dbg> bt_smp: smp_send_security_req: 
00> [00:00:13.051,971] <dbg> bt_keys: bt_keys_get_addr: F4:E8:C7:5E:82:43 (public)
00> [00:00:13.052,185] <dbg> bt_smp: smp_init: prnd e41b32de696c8ba9106144bf66704065
00> [00:00:13.052,215] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2016 param_len 2
00> [00:00:13.052,246] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20034930
00> [00:00:13.052,276] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20034930 opcode 0x2016 len 5
00> [00:00:13.052,307] <dbg> bt_hci_core: process_events: count 2
00> [00:00:13.052,337] <dbg> bt_hci_core: process_events: ev->state 4
00> [00:00:13.052,337] <dbg> bt_hci_core: send_cmd: calling net_buf_get
00> [00:00:13.052,337] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
00> [00:00:13.052,368] <dbg> bt_hci_core: send_cmd: Sending command 0x2016 (buf 0x20034930) to driver
00> [00:00:13.052,368] <dbg> bt_hci_core: bt_send: buf 0x20034930 len 5 type 0
00> [00:00:13.052,398] <dbg> bt_sdc_hci_driver: hci_driver_send: 
00> [00:00:13.052,398] <dbg> bt_sdc_hci_driver: cmd_handle: 
00> [00:00:13.052,459] <dbg> bt_sdc_hci_driver: hci_driver_send: Exit: 0
00> [00:00:13.052,459] <dbg> bt_hci_core: process_events: ev->state 1
00> [00:00:13.052,490] <dbg> bt_sdc_hci_driver: event_packet_process: Command Status (0x2016) status: 0x00
00> [00:00:13.052,520] <dbg> bt_hci_core: bt_recv: buf 0x20034930 len 6
00> [00:00:13.052,551] <dbg> bt_hci_core: hci_cmd_status: opcode 0x2016
00> [00:00:13.052,551] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2016 status 0x00 buf 0x20034930

0 Vidar Berg 3 months ago in reply to Gaurav

Did the existing bond have the LESC bit set?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

0 Gaurav 3 months ago in reply to Vidar Berg

I just reversed to the old state of ours where things actually worked and stopped the new bonding from populating in the structure and strangely that part is also not working now.

Gaurav said:
It worked Vidar. Reversing the IRK,LTK was the main culprit.

This part here.

Vidar Berg said:
Did the existing bond have the LESC bit set?

this is the config used-

//BLE_SEC
#define SEC_PARAM_BOND                      1                                       /**< Perform bonding. */
#define SEC_PARAM_MITM                      0                                       /**< Man In The Middle protection not required. */
#define SEC_PARAM_LESC                      0                                       /**< LE Secure Connections not enabled. */
#define SEC_PARAM_KEYPRESS                  0                                       /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES           BLE_GAP_IO_CAPS_NONE                    /**< No I/O capabilities. */
#define SEC_PARAM_OOB                       0                                       /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE              7                                       /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE              16                                      /**< Maximum encryption key size. */

0 Gaurav 3 months ago in reply to Gaurav

SO In the previous build where it was connecting, I made the phone to rebond and saved the LTK in the structure that you have shared and after this it started connecting. I think LTK changes with every paired connection and this was causing the issue for the connection to not go through in the old setup.

Need to check for the setup I am taking the keys from memory shared from the nRF5 SDK.
Do share if you get some insight from the above shared logs.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Reply

0 Gaurav 3 months ago in reply to Gaurav

SO In the previous build where it was connecting, I made the phone to rebond and saved the LTK in the structure that you have shared and after this it started connecting. I think LTK changes with every paired connection and this was causing the issue for the connection to not go through in the old setup.

Need to check for the setup I am taking the keys from memory shared from the nRF5 SDK.
Do share if you get some insight from the above shared logs.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel

Children

0 Vidar Berg 3 months ago in reply to Gaurav

The LTK changes if you re-pair, but it does not change across connections.

Gaurav said:
this is the config used-

You were previously testing with LESC bonding. As mentioned earlier, you should not set the SC bit in NCS if you use legacy pairing. I also believe you need to store the EDIV and Rand.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Gaurav 3 months ago in reply to Vidar Berg

So what should be the flag value and config for security in my applciation?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Gaurav 3 months ago in reply to Gaurav

I have changed the flag to SMP_FLAG_SC for pairing_info->flags = 5 and also copied EDIV and RAND values to the structures now, but still same issue.

Vidar Berg said:
You were previously testing with LESC bonding. As mentioned earlier, you should not set the SC bit in NCS if you use legacy pairing. I also believe you need to store the EDIV and Rand.

Should I enable CONFIG_BT_SMP_SC_PAIR_ONLY and remove bt_conn_set_security(conn, BT_SECURITY_L2) for my connection?
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Gaurav 3 months ago in reply to Gaurav

Gaurav said:
Should I enable CONFIG_BT_SMP_SC_PAIR_ONLY and remove bt_conn_set_security(conn, BT_SECURITY_L2) for my connection?

I have specifically disabled this config CONFIG_BT_SMP_SC_PAIR_ONLY=n but still stuck in the same state of "Peer removed info" error.

I have tested with pairing_info->flags = 3 also but still same result.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Vidar Berg 3 months ago in reply to Gaurav

From the description of the CONFIG_BT_SMP_SC_PAIR_ONLY symbol you can see that it forces sec. level 4 and is disabled by default.

Gaurav said:
I have tested with pairing_info->flags = 3 also but still same result.

pairing_info->flags should be '0' for legacy pairing. Also, I mistook the SMP_FLAG_SC for BT_KEYS_SC. They have the same value, but the latter should be the correct one.

params_info->keys is also different for legacy bonds. It looks like it shoul be 'BT_KEYS_LTK'.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel