STB: Use deterministic ECDSA for reproducible builds

[hlandau]

AFAICT Skiboot is now reproducible, except for the STB container. This is due to use of openssl dgst -sign, which doesn't support deterministic ECDSA (which is unfortunate anyway, as it's now a best practice). It looks like the OpenSSL APIs don't support deterministic ECDSA either, so might need to find an alternative.

[ghost]

Is there a way to do deterministic ECDSA that'd be comepatible with the existing verification code?

If not, I guess the STB headers are going to be something that we'll have to skip in doing checks of reproducible builds (at least for the time being).

[hlandau]

Deterministic ECDSA doesn't affect verification code, just how signatures are generated.

(The background is that ECDSA signature generation relies on generating a nonce. If you sign, with a given key, more than one thing with the same nonce, the private key is deducible. (See the famous PS3 hack, in which it turned out the developers had chosen a constant nonce of 3.)

So long as the nonce is a long, random integer generated from a high-quality entropy source, there's no problem, since the likelihood of a nonce collision is low. But modern consensus has been moving in favour of deterministic ECDSA, in which the nonce is a hash of the data being signed, in order to mitigate the catastrophic key leak impact of an entropy failure. Of course, as a convenient byproduct, it also makes outputs reproducible for a given signing key, hence why adopting it is the easiest way to make the STB header reproducible.)