Staging nitrokey git

[tlaurion]

This supersedes #1417, coauthoring commits since rebased on master + fixing (deleting) unrelated commits and adding needed repo change + blobs under coreboot module to use clevo_release dasharo fork + IASL url patch.

Please approve for merging @jans23

---

OLD:
This is Draft for @daringer to rebase #1417 on master, removing unneeded commits and take my latest one as a base for #1417 to be ready to merge.

The following commits can be deleted:

[ci: activate 'nitropad-nv41' + 'nitropad-ns50'](https://github.com/osresearch/heads/pull/1469/commits/f86e036afcda971d12cfcef48ebe82545c4c12ae)
[f86e036](https://github.com/osresearch/heads/pull/1469/commits/f86e036afcda971d12cfcef48ebe82545c4c12ae)
[CircleCI & Makefile: fixes needed for coreboot-git/cache reuse](https://github.com/osresearch/heads/pull/1469/commits/0db1be0dfb00f8a57e981f7142837f6dd10419cc)
[0db1be0](https://github.com/osresearch/heads/pull/1469/commits/0db1be0dfb00f8a57e981f7142837f6dd10419cc)
[Makefile: fix for multiple coreboot CI builds](https://github.com/osresearch/heads/pull/1469/commits/b73fc6c0b30267bf843e5c7ef53dbb3a9bbed193)
[b73fc6c](https://github.com/osresearch/heads/pull/1469/commits/b73fc6c0b30267bf843e5c7ef53dbb3a9bbed193)
[fake commit, circleci](https://github.com/osresearch/heads/pull/1469/commits/bdc08ae69e015134d969892077b271b599c5f1fb)
[bdc08ae](https://github.com/osresearch/heads/pull/1469/commits/bdc08ae69e015134d969892077b271b599c5f1fb)
[coreboot+coreboot patch+CircleCI config: adapt to have nv41/ns50 buil…](https://github.com/osresearch/heads/pull/1469/commits/b6cd52ff3e108759ff62f10565a0502437ba0d42)
[b6cd52f](https://github.com/osresearch/heads/pull/1469/commits/b6cd52ff3e108759ff62f10565a0502437ba0d42)

To match the files in this PR.

[tlaurion]

Note that hotp version bump was tested successfully on other boards so all here is related to nv41/ns50.
Also note that this PR changes default of oem-factory-reset to use EC p256 algo by default on those board at eg: https://github.com/osresearch/heads/pull/1469/files#diff-15afe4b741eb85edd66b8661bfff49fd8b53459a47cf8ed3b91d3fea67a86f6cR44

This is a business decision since RSA3072 cannot be supported by NK3 secure element as of now.
This PR is simply making #1417 build and points to Dasharo/coreboot clevo_release and adds IASL patch on top of @JonathonHall-Purism work to be able to not share coreboot-git directories as before and be able to point to coreboot buildstack that can be shared across forks (none right now: disaster for CircleCI builds but will try to improve on that).

[tlaurion]

This comment deserves an answer as well #1417 (comment)

the change is simply changing this one to p256

So this is from the "any other changes" category, not required to this board at all? Maybe those should go into separate PRs?

Regarding the use of the elliptic curves in general:

* yes, this is cool, for example I would like to have a possibility to WRITE DOWN the private key on paper and have it on paper "HSM" only. It is possible with EC, since they are small.

However:

* I don't see people using NIST curves with GPG often (which may or may not be a bad thing)

* Most people prefer ed25519 but this is problematic with GPG since there is an ongoing war of standards how to do it in OpenPGP, also there are some pitfalls with it, like having to specify "eddsa" flag with a private key or else it tries ECDSA(!)

* Most importantly, this would mean we would use ECDSA. I am not sure how reliable is random number generation under heads, it might be hard to guarantee the uniqueness of the _k_ semi-private key. libgcrypt [seems to have a "rfc6979" flag](https://www.gnupg.org/documentation/manuals/gcrypt/Cryptographic-Functions.html#Cryptographic-Functions) but I have no idea whether GnuPG uses it/can use it and how.

[tlaurion]

This PR was brought to my attention this morning. Crosslinking

[tlaurion]

@daringer it is to be noted that outside of nv41/ns50 that will change RSA3076 to EC p256 for those board owners, the rest of Heads users currently buying NK3 or planning to buy NK3 to be supported under Heads are currently left behind.

People are starting to ask questions over traditional Heads channels, which is normal. I tried to answer with the best of my knowledge

[tlaurion]

@daringer maybe NK3 support PR should be worked out seperately so that OEM-factory-reset/Re-Ownership wizard acts upon NK3 detection until Nitrokey/trussed-se050-backend#1 (comment) is ready for production?

One way to do so could be to probe for the usb security dongle that is to be factory-resetted and switch programmatically what would be the algo used for key generation with a warning or something? Since Heads is integrating the support and not responsible for what the USB security dongle supports, this puts Heads in a weird situation.

How do we do this cleanly?
What I mean is that NK3 owners, not only nv41/ns50 owners + NK3 owners should be able to use their NK3 keys with Heads. Unfortunately, with current codebase, this is not the case.

[daringer]

ok ok,

• cherry-picked the commits from this PR, can you please re-open: add Nitropad NV41/NS50 TPM2 boards #1417 means this can be closed.
• extracted the Nitrokey 3 support into: Nitrokey 3 support #1483 let's discuss details there

[tlaurion]

Replaced by #1485 and #1483 (merged)

Closing this