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.

Parents
  • 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

  • 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.

  • You can start with testing the sample I uploaded. The "No IRK for 4B:0D:2B:0F:F4:26" message indicates that you have not stored the correct IRK.

    For this part, isn`t this picking the IRK correctly-

    00> 4[00:00:10.186,248] <dbg> bt_sdc_hci_driver: event_packet_process: LE Meta Event (0x0a), len (31)
    00> [00:00:10.186,279] <dbg> bt_hci_core: bt_recv: buf 0x20034464 len 33
    00> [00:00:10.186,401] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
    00> [00:00:10.186,401] <dbg> bt_hci_core: rx_work_handler: buf 0x20034464 type 1 len 33
    00> [00:00:10.186,431] <dbg> bt_hci_core: hci_event: event 0x3e
    00> [00:00:10.186,431] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0a
    00> [00:00:10.186,798] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: status 0x00 handle 0 role 1 peer 45:F5:1C:A9:63:AF (random) peer RPA 00:00:00:00:00:00
    00> [00:00:10.186,950] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: local RPA 00:00:00:00:00:00
    00> [00:00:10.187,133] <dbg> bt_keys: bt_keys_find_irk: 45:F5:1C:A9:63:AF (random)
    00> [00:00:10.187,164] <dbg> bt_sdc_crypto: bt_encrypt_le: key
    00>                                         8a 27 1e a7 92 2a f0 15  41 69 48 dd c0 7e dd f7 |.'...*.. AiH..~..
    00> [00:00:10.187,194] <dbg> bt_sdc_crypto: bt_encrypt_le: plaintext
    00>                                         1c f5 45 00 00 00 00 00  00 00 00 00 00 00 00 00 |..E..... ........
    00> [00:00:10.187,255] <dbg> bt_sdc_crypto: bt_encrypt_le: enc_data
    00>                                         a3 4a 70 29 4c 06 39 bd  a3 be ef 9b 2b 27 dd df |.Jp)L.9. ....+'..
    00> [00:00:10.187,438] <dbg> bt_keys: bt_keys_find_irk: No IRK for 45:F5:1C:A9:63:AF (random)
    00> [00:00:10.187,469] <dbg> bt_adv: bt_le_adv_resume: Host cannot resume connectable advertising (-12)
    00> [00:00:10.187,500] <dbg> bt_smp: bt_smp_accept: conn 0x20003e58 handle 0
    00> [00:00:10.187,530] <dbg> bt_smp: bt_smp_connected: chan 0x200042b0 cid 0x0006
    00> [00:00:10.187,805] <dbg> bt_keys: bt_keys_find_addr: 45:F5:1C:A9:63:AF (random)

  • You can start with testing the sample I uploaded. The "No IRK for 4B:0D:2B:0F:F4:26" message indicates that you have not stored the correct IRK.

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

    Copying the pairing info from nrf5SDk into NCS application will also remain the same with respect to encryption level?

  • Glad to hear that it worked.

    Yes, the same AES-CCM algorithm is used to encrypt the link regardless of the pairing method used to exchange the key. That said, the pairing_info->keys and pairing_info->flags values stored in the bond table must correspond with the pairing method used. For instance, the SMP_FLAG_SC bit should not be set if legacy pairing was used.

  • I just implemented the flow in nRF5SDK version code where I am saving the pairing info after peer_manager_init() and when I run bare application, its correctly stores the pairing info to the memory but when I am merging the application with the bootloader then the pm_peer_data_bonding_load starts throwing error of value 7 which points to the the peer_id being INVALID.
    Any view point on this one?

  • Did you ensure that the bonds were stored after adding the bootloader? The FDS/bond data goes from being placed at the end of the flash to placed below the bootloader when a bootloader is present.

Reply Children
  • Yes I have done that.
    Mostly the issue looks from the flash size only, not able to write these info without erasing and the main issue is erasing that particular region is not possible.

    Flash was defined from 0xf4000 to 0xf5000, I increased this to 0xf7000 ( 0xf4000-0xf7000), but was facing the above issue and when I reverted to the old settings then the bond info started showing but was not able to update those info onto the flash like storing on the address 0xf4050, needs erasing first and then update but erase will clean the complete page and this will delete the device information which is essential.

  • The FDS region has to be a minium of 2 flash pages (is 3 by default) as it reserves one page for garbage collection. Therefore, the span must be bigger than 0xf4000 to 0xf5000. 

  • 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-

  • 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
    

  • Did the existing bond have the LESC bit set?

Related