Cross checking nrfutil boot_validation_signature for VALIDATE_ECDSA_P256_SHA256 with openssl command line

RE: Cross checking nrfutil boot_validation_signature for VALIDATE_ECDSA_P256_SHA256 with openssl command line

Wendel — Wed, 09 Dec 2020 01:38:17 GMT

Hi Richard,

Thanks for the clarification. It really helps a lot.

RE: Cross checking nrfutil boot_validation_signature for VALIDATE_ECDSA_P256_SHA256 with openssl command line

Richard R — Tue, 08 Dec 2020 14:23:00 GMT

Hi Wendel,

Not directly, no. The answer from Turbo J is correct.

nrfutil stores the ecdsa signature as {r,s} value pairs (32-byte each) in little endian {r_le, s_le}. See nrfutil/dfu/signing.py for lines like this:

return signature[31::-1] + signature[63:31:-1]

I ended up creating a variant of that function that can return the big-endian format.

I can't find a simple openssl CLI to cross-check, so I end up using pyca/crytography library (https://cryptography.io/en/latest/index.html) which uses openssl as a back-end for testing.

RE: Cross checking nrfutil boot_validation_signature for VALIDATE_ECDSA_P256_SHA256 with openssl command line

Wendel — Tue, 08 Dec 2020 07:26:07 GMT

Hi Richard

Have you got the method to cross check signature with openssl command line?

Thanks.

RE: Cross checking nrfutil boot_validation_signature for VALIDATE_ECDSA_P256_SHA256 with openssl command line

Turbo J — Tue, 14 Jul 2020 20:41:49 GMT

I cannot provide OpenSSL commands, but there are two important things missing:

ASN.1 encoding
big endian byte order

The nrfutil.sign file is smaller because it is not ASN.1 encoded. OpenSSL expects signatures to be ASN.1 encoded in order to provide meta information (e.g. which algorithm to use).

The encoded data is expected to be in network byte order (= big endian). The nrfutil program generates signatures in little endian, since that matches the endianess of the NordicSemi Cortex-M chips - and thus no byte order swapping needs to be done when checking the signature in the bootloader.

In summary, for OpenSSL to be useful one needs to swap byte order (reverse bytes), and then encode the result properly as ASN.1 data. Not sure if this is possible with the command line tool only.