[signing] Support sphincs+ PreHashedSha256 mode

[cfrantz]

1. Redefine the config field of key_{ecdsa,sphicns_plus} rules to be
   a dictionary of parameters.
2. Allow setting parameters in the key nickname field of keyset rules
   (e.g. {"//key:label": "foo:domain=Pure"}).
3. When generating pre-signing artifacts, use only the public key to
   prevent opentitantool from immediately signing the artifact.
4. In the _local_sign and _hsmtool_sign helper functions, construct
   appropriate command line arguments considering the signing mode and
   byte-reversal settings.
5. Fix the image manifest update command to use the normal SHA256 byte
   ordering. Add a command line argument to reverse the hash to deal
   with existing implementations with a reversed hash.
6. Allow the spx sign|verify commands to optionally reverse their
   input.
7. Support verification of owner code using the SPHINCS+
   PreHashedSha256 mode. Since the OpenTitan HMAC peripheral
   produces hashes in "little-endian" order, reverse the bytes
   before verification so that the correct byte ordering is used.
8. Add a test for PreHashedSha256 mode using the fake app DEV key.

[jadephilipoom]

Is this debug print intended to be left in?

[cfrantz]

No, I forgot to remove it. Fixed.

[jadephilipoom]

How does the implementation now know, for example, to use SHA2 parameters instead of SHAKE? I've lost track of where this information comes from now.

[cfrantz]

On the host, the key files store the algorithm information. In the device, the key "algorithm" configuration encodes both the algorithm and domain.

$ cat ./sw/device/silicon_creator/lib/ownership/keys/fake/app_prod_spx.pub.pem
-----BEGIN RAW:SPHINCS+_SHA2_128s_simple PUBLIC KEY-----
J4pnFBeX/Xc3VvOIqL4XxdM9EXvi4rlcCFwfQuru5MY=
-----END RAW:SPHINCS+_SHA2_128s_simple PUBLIC KEY-----

enum ownership_key_alg {
  ...
  /** Key algorithm Hybrid P256 & SPX+ Prehashed SHA256: `H+S2` */
  kOwnershipKeyAlgHybridSpxPrehash = 0x32532b48,
}

FYI, the prior value of the "config" attribute in the bazel rules was unused - it was never used in a conditional, nor passed to any programs (like opentitantool or hsmtool). A set of key/value pairs indicating additional information that may be needed by the signer seemed like a better use of that field.

[vbendeb]

Nit:

Is supporting both digest byte orders necessary be able to keep building for ROM validation?

The command line argument name indicating 'correct' vs 'incorrect' byte order would be clearer.

[cfrantz]

Is supporting both digest byte orders necessary be able to keep building for ROM validation?

Yes - the ROM's implementation of pre-hashed validation erroneously uses the reversed byte-order Sha256 hash. In order to validate an SPX signed ROM_EXT using Prehashed mode, we need to reverse the byte order of the hash.

The command line argument name indicating 'correct' vs 'incorrect' byte order would be clearer.

I created #25870 to fix the byte ordering emitted and used by our tooling. Fixing that issue will deal with fixing and/or renaming flags.

[cfrantz]

Closed as these commits were submitted with #25872.