Encrypt connection without pairing

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
MiBi_4539931
Level 1
Level 1
5 replies posted 5 questions asked First question asked

Hi,

We have developed application on nrf chip that is in production now. We want now port it to Cypress CYW20819 chip. I want to make as least changes as possible in application logic to make this porting smooth process.

For nrf chip it was possible to encrypt connection without executing pairing process - instead of initiating pairing central was starting encrypting connection with a hardcoded key. It make sense to do that because we want only connect to our own devices, skipping pairing is faster and we don't have to care about flash used for many different devices.

So far I was trying modify Heart Rate client example to do that but no success so far. I created a custom key record and used hrc_save_link_keys to to save it in flash on application startup. I also tried to replace hrc_read_link_keys to always respond with my hardcoded key. In both cases I then tried to call wiced_bt_dev_set_encryption on connection start instead of wiced_bt_dev_sec_bond. That doesn't seem to work as I am getting an error.

I would assume that key thing is to fill p_event_data->paired_device_link_keys_request with proper data after BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT is generated. I should then be able to just call wiced_bt_dev_set_encryption  but I was wondering if there is maybe more into this?

Is what I am doing even possible for Cypress CYW20819 chip? If so can you guide me a bit?

Michał

0 Likes
1 Solution

Hi Michał,

The regular steps to encrypt a link are:

  1/ Authenticate the connection (verify that both devices have the same LinkKey).

       1a/ If there is no LinkKey (in NVRAM), a new LinkKey must be create via the Pairing process

       1b/ If there is already a LinkKey (in NVRAM), it I used to Authenticate the connection.

  2/ Once a connection is Authenticated, the Connection can be Encrypted.

If the peer device is a ‘regular’ device (e.g. Phone, computer, etc.), then you have to follow this mechanism.

But, if you implement the two devices, you may ‘hack’ the steps and bypass the Pairing step (and use an hardcoded LinkKey).

Note that this connection will not be secured (a hacker will probably be able to hack your system).

The Wiced SDK exposes two APIs:

  - wiced_bt_dev_sec_bond: This API will initiate the Pairing (aka Bonding).

  - wiced_bt_dev_set_encryption: This API, which supposes that a LinkKey exists, will initiate the Pairing.

So, if you do not call wiced_bt_dev_sec_bond  but call wiced_bt_dev_set_encryption (as soon an a BLE device is connected), the BT stack will ask for the LinkKey (BTM_PAIRED_DEVICE_LINK_KEYS_REQUEST_EVT event).

Upon reception of this event, your application will have to fill the p_data-> paired_device_link_keys_request.key_data field/structure with your hardcoded data.

Notes:

  - The same values must be used of both devices.

  - The key_data field/structure is a bit complex (many fields, bitfields, etc.). I recommend to use the regular Pairing and

     dump the key_data field/structure received in the BTM_PAIRED_DEVICE_LINK_KEYS_UPDATE_EVT to understand how it works.

Thanks,

Patrick

View solution in original post

8 Replies