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

look for sample code for reconnect to bonded devices and share the encryption keys.

Hi, I am looking for sample code that can reconnect to bonded devices and share the encryption keys with DFU-OTA. 

I have worked using DFU-OTA (JUST_WORKS option); I question is:

1. My device does not have a keyboard to inter passkey; is there any other way that I can do?

2. After I connect and bounded the device; how do I share the encryption key to DFU; and restart without rebound this device?

I am using nRF52840-DK; Windows 10; Embedded Studio SD: s140_nrf52_6.0.0_softdevice SDK 15.0.0

Please help.

Donald

Parents
  • Hi Donald,

    our Secure Bootloader supports bond sharing, i.e. the application will share the bonding information about the peer that initiated DFU through the DFU service that the application has in its GATT table. So there is no need to share any encryption keys, this is handled automatically by the application and bootloader if you have configured them to support bond sharing, i.e. 

    Set NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS to 1 in the applicaiton's sdk_config.h file.

    Set NRF_DFU_BLE_REQUIRES_BONDS to 1 in the bootloader's sdk_config.h file.

    The DFU process itself uses a private-public key pair for ECDSA validation. First, you as the developer will generate a private key that you keep secret, then you generate a public key from the private key. The public key is compiled into the bootloader and the private key is used to sign a hash of the firmware image intended for the device. Using the public key it is possible to verify if the hash was signed by the private key it self was derived from. 

    The private key can not be derived from the public key, so there is no harm in the public key being known. 

    Best regards

    Bjørn

Reply
  • Hi Donald,

    our Secure Bootloader supports bond sharing, i.e. the application will share the bonding information about the peer that initiated DFU through the DFU service that the application has in its GATT table. So there is no need to share any encryption keys, this is handled automatically by the application and bootloader if you have configured them to support bond sharing, i.e. 

    Set NRF_DFU_BLE_BUTTONLESS_SUPPORTS_BONDS to 1 in the applicaiton's sdk_config.h file.

    Set NRF_DFU_BLE_REQUIRES_BONDS to 1 in the bootloader's sdk_config.h file.

    The DFU process itself uses a private-public key pair for ECDSA validation. First, you as the developer will generate a private key that you keep secret, then you generate a public key from the private key. The public key is compiled into the bootloader and the private key is used to sign a hash of the firmware image intended for the device. Using the public key it is possible to verify if the hash was signed by the private key it self was derived from. 

    The private key can not be derived from the public key, so there is no harm in the public key being known. 

    Best regards

    Bjørn

Children
No Data
Related