Bluetooth LE pre-pairing for Windows

[CY]

Hi,

Recently, I am studying the blog as the link below:

https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/bluetooth-prepairing

We would like to do pre-paired in factory.

As you might see from the website, it has mentioned that as peripheral it is required to follow the rule.

Peripheral

• Bluetooth LE
• Store for Device ID (hashed from Bluetooth Address) & TK value
• Custom Advertisement (defined below)

I am unclear about the Device ID description.

DeviceID: uniquely identify a supporting device and should be 8 bytes in length to avoid device conflicts.

From the description it said it should be 8 bytes, but the BT address should be 6 bytes  (0xC7BB9B6D8833).

 I suppose I am misunderstanding. Could you give me some guide?

And I would like to know whether I could check and set the the Device ID as well as the temporary key (SMP TK)?

If there is any API, could you help me to indicate?

Thanks.

[Susheel Nuguru]

As far as I could understand, you can use the device address that you can read from NRF_FICR->DEVICEADDR[] which is of 48 bits length (6 bytes) and prepend 2 bytes of zeros (0s) and this seems to fit the requirement for DeviceID mentioned in the link your mentioned

[CY]

Hi Susheel,

Now I am confused that why it is different from I checked from the OS.

 

Do you know how to command that by nrfjpro.

How about TK? Where could I check and set?

Thanks.

[Susheel Nuguru]

From the description it said it should be 8 bytes, but the BT address should be 6 bytes  (0xC7BB9B6D8833).

Well  0xC7BB9B6D8833 is same as 0X00C7BB9B6D8833 which is valid 8 byte to store in UCHAR DeviceId[BTHLE_PREPAIRING_DEVICE_ID_SIZE]; in the link you mentioned. So please ignore my initial response on bit shifting. This should be a valid ID to save in your case. Even 0x1 can be saved as a valid 8 byte device id.

[CY]

Hi Susheel,

Thanks for the explanation.

So how about TK, how could I check the temporary key in my device?

[Susheel Nuguru]

If it is not a static TK, then I think it is no way to do it without editing the peer_manager.

in security_dispatcher.c you can see that link_secure_central_encryption will fetch the LTK from the peer manager before requesting the encryption procedure with the peer.

You can create another function that will request the LTK from peer manager for the connection handle without requesting the bonding procedure.

[CY]

I suppose to meet the pre-paired function, it should be static TK.

So will it be the same way to achieve the key? Or other function instead of link_secure_central_encryption?

And I just confused with the "Central".

If my device is peripheral device, could it worked?

[CY]

I just found the related location as below:

ble_gap.h

/**@brief GAP LE Secure Connections OOB data. */
typedef struct
{
ble_gap_addr_t addr; /**< Bluetooth address of the device. */
uint8_t r[BLE_GAP_SEC_KEY_LEN]; /**< Random Number. */
uint8_t c[BLE_GAP_SEC_KEY_LEN]; /**< Confirm Value. */
} ble_gap_lesc_oob_data_t;

peer_manager_types.h

/**@brief Data associated with a bond to a peer.
 */
typedef struct
{
    uint8_t           own_role;    /**< @brief The BLE role of the local device during bonding. See @ref BLE_GAP_ROLES. */
    ble_gap_id_key_t  peer_ble_id; /**< @brief The peer's Bluetooth address and identity resolution key (IRK). */
    ble_gap_enc_key_t peer_ltk;    /**< @brief The peer's long-term encryption key (LTK) and master ID. */
    ble_gap_enc_key_t own_ltk;     /**< @brief Locally generated long-term encryption key (LTK) and master ID, distributed to the peer. */
} pm_peer_data_bonding_t;

How could I change the BT address and TK value?

[CY]

Hi Susheel,

I just reviewed the nfc_pairing sample for finding the clue of OOB.

Since that OOB must use the below information:

I supposed it is possible to set a static TK in nRF52 because the below image:

 

But not sure where could I set, I cannot not link to the definition of TK.