Closed xiaoyuruan closed 1 year ago
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: . using binary(DLL) linking - need item 7. . using source build - no need item 7.
Proposal as first step:
Reference: https://icmconference.org/wp-content/uploads/C22b-RuanX.pdf
ref: https://github.com/DMTF/libspdm/discussions/1406 for API proposal.
Summary is at https://github.com/DMTF/libspdm/discussions/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: