-
Notifications
You must be signed in to change notification settings - Fork 295
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate if OpenSSL (libcrypto) vendored in here can be FIPS certified #586
Comments
Is it worth trying to use a really old openssl for FIPS certification any more? 140-3 with openssl 3 looks like a much better option, surely? |
Yes, if it works... Note upgrade to 1.1.0 got reverted due to production secureboot certs being rejected by new openssl thus failing to boot things validly signed. And it seems nobody is looking to upgrade the vendored openssl and/or fixup openssl to still work. |
We probably need to figure out how to get to a newer openssl regardless. The notes in 1d39ada also make me thins that we should look into some compatibility. Let me make sure that I understand what you're asking for WRT FIPS: Are you hoping for a FIPS certified shim binary? I'm not sure that is worth the effort if it's even possible. Or do you just want to unlock CERTs that a FIPS compliant openssl is happy with for use in shim? I do agree that the latter seems rather desirable. |
This. If shim binary is certified, it means for kernel FIPS certification a given vendor can avoid having a self integrity check (potentially). And if we all use the same builds or same source code, it will be easy enough to rebrand such certification to share it with us. Some people genuinely ask for wanting to have everything FIPS - because in theory we could. |
Pondering if smuellerDD/leancrypto#9 is a good choice for replacing cryptography in shim. That library targets bare-metal / freestanding code. has been fips certified before. and has PQC. |
Life would be easier if libcrypto inside shim was FIPS certified, as for example it would then not be needed for everyone to ship .hmac files for vmlinuz.
Looking at the code it seems like we currently reverted to using 1.0.2k OpenSSL version. Ubuntu actually has a FIPS certified 1.0.2g OpenSSL thus it would be interesting to see if this can be achieved.
I am also slightly concerned by how old our OpenSSL is, even if it is unlikely that any bugs or CVEs affect our reduced codebase.
In 1d39ada @vathpela reverted updates to OpenSSL due to incompatibilities with existing certs => have the certs that broke got stored somewhere as test cases? I separately ponder if we can or should work with OpenSSL upstream to contribute "UEFI" mode to OpenSSL to accept more certs.
Basically a can of worms =)
The text was updated successfully, but these errors were encountered: