trusted boot: use XMSS signatures instead of a SHA256 hash

[peterohanley]

Describe your changes

firmware.c now either checks that the blob has a valid signature with a given public XMSS key or checks that it has a given SHA256 hash, configurable at build time. The signature verification specs are fairly simple, the signature generation specs are more complicated but I did not continue this effort after a discussion with @spernsteiner about the applicability of XMSS to this part of the code. CN cannot handle many parts of the XMSS library (especially atomics, flexible array members, and unions) and so the code is not currently runnable.

My time log is in xmss.md

Issue ticket number and link

#125

Checklist before requesting a review

• I have performed a self-review of my code
• My code matches the coding standards and I have ran the appropriate linters
• I included documentation updates for my code
• I extended the test suite and the tests run by the CI to cover my code
• I assigned a Milestone to this PR
• I assigned this PR to a Project
• I assigned this PR appropriate Labels

[podhrmic]

Thanks for putting this together @peterohanley !
What was the reason you included the xmss library directly rather than adding it as a submodule? If CN cannot process it anyway, a submodule would be cleaner (unless you had to make many changes to the library).
Minor comments above and the CI still needs fixing.

[spernsteiner]

It doesn't look like public_key and xmss_signature are initialized anywhere, so won't this basically always return false?

[spernsteiner]

Having a hardcoded key makes sense, but having a hardcoded signature doesn't (if you're going to hardcode the XMSS signature of a particular input, you could just as well hardcode its SHA256 hash and save yourself a lot of trouble). I think it would make more sense for xmss_signature to be a local inside main/reset, initialized from part of the input (e.g. last N bytes are the signature and everything before that is the code being signed).

[peterohanley]

What was the reason you included the xmss library directly rather than adding it as a submodule? If CN cannot process it anyway, a submodule would be cleaner (unless you had to make many changes to the library).

In order to process it we need changes to many xmss headers. Specs could be in a local file that reaches into the submodule but many of the changes are intrusive (flexible array members especially)