• State Verified Answer
  • Replies 3 replies
  • Subscribers 87 subscribers
  • Views 920 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 272838
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU keys update

PBeS

Hi,

I tried to update DFU keys via update on SDK-4.1 and I didin't to do it. Its possible to change DFU keys via upgrade. I did this process on SDK-2 and there was no validation of dfu key via Bootloader but not in SDK-4. 

My steps:

  1. Prepare key pair version 1
  2. Prepare key pair version 2
  3. Flash board with dfu keys ver 1
  4. Change public key dfu_public_key.c to ver 2
  5. Prepare DFU package SW v2 (signed by old key - ver1)
  6. Update with SW v2
  7. Prepare DFU package SW v3 (signed by new key - ver2)
  8. Update with SW v3

In step 8, after download image and reboot, bootloader fail new app on verification of signature.

Please, let me know if its possible to do DFU keys update on sdk-4.1ff

Thanks

Parents
  • +1

    Hi,

    Which DFU solution are you using? There is both the standard DFU bootloader solution from nRF5 SDK, and the particular solution for Thread Secure DFU. The latter can only be used for application updates, and so I assume that you are talking about the (serial) DFU bootloader from nRF5 SDK.

    For the one from nRF5 SDK, the DFU bootloader contains a public key, which is used for checking the signing. It will therefore accept any update signed with the corresponding private key.

    With key pairs 1 and 2, and bootloaders 1 and 2, the update will go like this:

    1. On SoC: Bootloader 1, compiled with public key 1.
    2. Bootloader 2 (compiled with public key 2) is put into an update package signed with private key 1.
    3. DFU is performed.
    4. Now on SoC: Bootloader 2, compiled with public key 2.
    5. New updates can be prepared and signed with private key 2.
    6. The SoC, now with bootloader 2, can accept those new updates.

    In your case, in 6, the bootloader claims the signing is wrong. This may be either because the old bootloader (with old key) is still on the SoC (i.e. the first update failed), or because there is something wrong with the update.

    Have you confirmed that the first bootloader update succeeded?
    Have you confirmed that the upgrade zip packet is working as expected if programming bootloader 2 directly first?

    Regards,
    Terje

Reply
  • +1

    Hi,

    Which DFU solution are you using? There is both the standard DFU bootloader solution from nRF5 SDK, and the particular solution for Thread Secure DFU. The latter can only be used for application updates, and so I assume that you are talking about the (serial) DFU bootloader from nRF5 SDK.

    For the one from nRF5 SDK, the DFU bootloader contains a public key, which is used for checking the signing. It will therefore accept any update signed with the corresponding private key.

    With key pairs 1 and 2, and bootloaders 1 and 2, the update will go like this:

    1. On SoC: Bootloader 1, compiled with public key 1.
    2. Bootloader 2 (compiled with public key 2) is put into an update package signed with private key 1.
    3. DFU is performed.
    4. Now on SoC: Bootloader 2, compiled with public key 2.
    5. New updates can be prepared and signed with private key 2.
    6. The SoC, now with bootloader 2, can accept those new updates.

    In your case, in 6, the bootloader claims the signing is wrong. This may be either because the old bootloader (with old key) is still on the SoC (i.e. the first update failed), or because there is something wrong with the update.

    Have you confirmed that the first bootloader update succeeded?
    Have you confirmed that the upgrade zip packet is working as expected if programming bootloader 2 directly first?

    Regards,
    Terje

Children
  • +1 in reply to tesc

    Hi Terje,

    Thanks for quick reaction. 

    I'm using Thread Secure DFU. You are right, I missed step when I update keys for bootloader (Is not required for SDK2, because there is no signature validation by bootloder). 

    I try to update like this (SDK4):

    1. Prepare keys pair 1 (let's call them pub1 and priv1) and pair 2 (pub2 and priv2)
    2. On SoC: Bootloader 1, Application 1, compiled with public key 1 (pub1), signed with private key 1 (priv1).
    3. Prepare bootlader dfu package (compiled with pub2, signed with priv1)
    4. DFU is performed
    5. Prepare application dfu package (compiled with pub2, signed with priv1)
    6. DFU is performed
    7. Now I have bootloader 2 and application 2
    8. Prepare application dfu package (compiled with pub2, signed with priv2)
    9. DFU is performed
      1. application is downloaded correctly
      2. reboot after DFU
      3. bootloader - signature error 

    In case 9.c I got bootloader error debug:

    <error> nrf_dfu_validation: Signature failed (err_code: 0x8542)

    Please let me know if my steps are ok.

    Regards 

    Piotr

Related
Terms of service