-
Notifications
You must be signed in to change notification settings - Fork 101
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
[Feature request] Support FIPS 140-3 level 1 compliance #1260
Comments
I think 1 through 4 is fine. 5, 6, and 8 only concern the cryptography software and hardware, correct? If so I don't think libspdm needs to expose any interfaces. Whomever is integrating libspdm into a Requester or Responder can perform those functions outside of libspdm. I think 7 assumes that libspdm is a standalone dynamically linked library in which case we could support integrity checking. But if libspdm is integrated into a larger executable or another library then integrity checking needs to be done at a higher level. |
Yes, agreed with all your points. 5, 6, 8 can be implemented in the SW crypto lib; if the crypto is HW (and assumingly hard to change), then libspdm or new "crypto driver" SW/FW could help with 5, 6, 8. |
I think we need a clear definition on FIPS boundary. For example, FIPS boundary == SPDM lib (responder and/or requester) + crypto lib. We also need determine how libspdm integrates the existing crypto lib, which may already have FIPS MODE. (e.g. https://www.openssl.org/docs/fips.html, or https://www.wolfssl.com/license/fips/). For example: Proposal as first step:
Reference: https://icmconference.org/wp-content/uploads/C22b-RuanX.pdf |
ref: #1406 for API proposal. |
Fix the issue: DMTF#1260 Signed-off-by: Wenxing Hou <[email protected]>
Fix the issue: DMTF#1260 The approved algo is listed at:https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-140Cr1.pdf Signed-off-by: Wenxing Hou <[email protected]>
Fix the issue: #1260 Signed-off-by: Wenxing Hou <[email protected]>
Fix the issue: #1260 The approved algo is listed at:https://nvlpubs.nist.gov/nistpubs/ SpecialPublications/NIST.SP.800-140Cr1.pdf Signed-off-by: Wenxing Hou <[email protected]>
Reference: DMTF#1260 Signed-off-by: Wenxing Hou <[email protected]>
Reference: DMTF#1260 Signed-off-by: Wenxing Hou <[email protected]>
Reference: #1260 Signed-off-by: Wenxing Hou <[email protected]>
Reference: #1260 Signed-off-by: Wenxing Hou <[email protected]>
Summary is at #1406. |
FIPS 140-3 is a US government government standard for crypto and security modules. Some open source libraries are certified for compliance with FIPS 140-3 level 1. For example, OpenSSL 3.0 achieved FIPS 140-3 level 1 certificate (https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4282).
Though libspdm does not have to acquire FIPS 140-3 certificate, compliance with FIPS 140-3 makes easier for adopters of the libspdm to achieve FIPS 140-3 certificates for their products.
Detailed requirements to make libspdm FIPS compliant and design suggestions:
- For most algorithms, implement known answer selftest (KAT), i.e., pass hardcoded input data and key to underlying crypto library and compare returned output data with hardcoded answer.
- This is usually not possible for DRBG (SP 800-90A), as the crypto library usually does not allow caller to specify seed. So DRBG (SP 800-90A) KAT should be implemented within the crypto library, before first use of the DRBG.
- Entropy selftest is not possible from libspdm. The crypto library should implement.
- KEY_EXCHANGE uses ECDH (SP 800-56Arev3), which has comprehensive pairwise consistency selftest requirement for ephemeral ECC keypair. See the IG.
The text was updated successfully, but these errors were encountered: