Signing and verifying with OpenSSL vs. nrfutil

[LLTMBeahan]

The issue I'm having is signature verification failing when I sign my firmware package and perform a DFU. I've generated signing key pairs with the nrfutil CLI tool, signed a package, and performed a DFU successfully (following the bootloader example).

Instead of signing the firmware package with nrfutil, I want to sign my package with a third party (a server). I know that the server's source code uses the `cryptography` Python library to sign and verify, which piggy backs off of OpenSSL. I was careful to make sure the signature is in the right byte order, but DFU is still failing during prevalidation because of the signature verification.

I checked that the server signature is little-endian and NOT ASN.1 encoded, is there something else I'm missing?

Also, I checked Nordic documentation and saw that I should be able to generate keys, sign, and verify with OpenSSL. What commands do I need to use to check the signature? Are there equivalent commands for the nrfutil tool?

Is there a DFU example for using OpenSSL instead of nrfutil?

Thanks

[Vidar Berg]

Hello,

Unfortunately, we do not have any samples demonstrating how you can sign the DFU init packet with openssl. The SDK documentation only explains how you can create the keypair with openssl. Did you use the https://github.com/NordicSemiconductor/pc-nrfutil/blob/master/nordicsemi/dfu/signing.py implementation from nrfutil as a reference? 

This thread may also be relevant: AWS Key Management System - DFU Package Signing 

Best regards,

Vidar

[LLTMBeahan]

Hi Vidar,

Thanks for your reply!

I have a feeling the issue is a matter of byte order.

I did use the nrfutil repo (signing.py) as a reference while looking into nrfutil and OpenSSL. I ended up writing a short script to test the Python library that nrfutil uses (ecdsa) and the Python library our server uses (cryptography). I wanted to make sure without a doubt that it's possible to sign an Init packet with one library and verify the signature with the other. After a first attempt to sign something with nrfutil, I noticed it was failing its own verification! This is when I realized that the ecdsa Python library likely expects big-endian data, but for Nordic, the signature needs to be stored in the Init packet as little-endian. As long as the signature is in the right format, both libraries are able to verify the signatures.

I'm not sure if it matters, but I know when we make the API call to the server, the server response is base 64 encoded.

I've tried the byte order both ways for the signature and both ways still fail signature verification. Do you have any recommendations? Also, is the nrfutil verify function an accurate representation of the verification process that happens in the Bootloader during a DFU?

Thanks

[Vidar Berg]

Hi, please let me know if you have made any progress on this. I have not had enough time to investigate this further. Regarding endianess, at least the public key is split into R and S in the code. This is relevant if you need to swap the byte order of that key:  RE: ECDSA with nrfutil generated key