repository·main·Indexed 41 days ago
https://github.com/dmtf/libspdmA reference implementation of the Security Protocol and Data Model (SPDM) and associated secured message libraries. Designed for high-security environments, embedded systems, and OS-level drivers, it supports SPDM versions 1.0 through 1.3. The library uses C99 freestanding headers, avoids dynamic memory allocation, and provides wrappers for cryptography libraries including OpenSSL and Mbed TLS, supporting traditional and Post-Quantum (PQC) algorithms.
Starting from version 3.0.0, libspdm includes support for FIPS 140-3.
Important Note for Integrators: The SPDM Working Group does not intend to obtain FIPS 140-3 Cryptographic Module Validation Program (CMVP) or Cryptographic Algorithm Validation Program (CAVP) certification for libspdm itself. Integrators are responsible for choosing a cryptographic module and supporting CMVP certification for their specific implementation.
The files in the unit_test/test_size/ directory are used exclusively to characterize and measure the object code size of a libspdm endpoint.
Warning: This code is not functional and is not intended for production use. If you need to see how to implement a functional SPDM endpoint using libspdm, refer to the spdm-emu repository instead.
libspdm. For information regarding FIPS compliance and enabling FIPS support, refer to the dedicated fips.md documentation.In SPDM version 1.3 and later, endpoints negotiate an AEAD limit using the AEADlimitOE opaque data element (SMDataID = 2). This limit defines how many messages can be encrypted/decrypted before a key update is required.
Negotiation Logic:
AEADlimitOE if its local version list includes 1.3. The Responder advertises it only if it selects version 1.3 or later.(2 ^ local_AeadLimitExponent) - 1.(2 ^ peer_AeadLimitExponent) - 1.KEY_UPDATE is performed to reset the sequence number.Note: If the negotiated version is older than 1.3, any received AEADlimitOE is ignored and treated as the default exponent of 64.
The spdm_context is a required input parameter for libspdm. Consumers must allocate this context using the size returned by libspdm_get_context_size().
In the spdm-emu (SPDM emulator), you can verify the size using:
printf("context_size - 0x%x\n", (uint32_t)libspdm_get_context_size());
At Level 4 of the trust model, transport-specific libraries (e.g., SpdmTransportMctpLib, SpdmTransportPciDoeLib) manage the encapsulation of SPDM messages.
Capabilities:
Security Considerations:
At Level 2 of the trust model, the spdm_secured_message_lib (crypto engine specific or common) manages ephemeral secrets and session security.
Capabilities:
Security Considerations:
In libspdm, encapsulated flows can exist either within a specific session or outside of one (non-session context). The library supports arbitrary and interleaved encapsulated messages between different sessions.
Session Independence Example:
GET_ENCAPSULATED_REQUEST / ENCAPSULATED_REQUEST in Session1.GET_ENCAPSULATED_REQUEST / ENCAPSULATED_REQUEST in Session2.DELIVER_ENCAPSULATED_RESPONSE / ENCAPSULATED_RESPONSE_ACK in Session1.DELIVER_ENCAPSULATED_RESPONSE / ENCAPSULATED_RESPONSE_ACK in Session2.Exception: Handshake in the Clear
If both endpoints have set HANDSHAKE_IN_THE_CLEAR_CAP, encapsulated messages are sent outside of a session. In this state, if the Responder signals for an encapsulated flow, the next non-session message must be:
GET_ENCAPSULATED_REQUEST if MutAuthRequested bit 1 is set.DELIVER_ENCAPSULATED_RESPONSE if MutAuthRequested bit 2 is set.In this mode, the Requester may also issue GET_VERSION.
The libspdm threat model is organized into five hierarchical levels of trust domains. Each level represents a different functional layer of the SPDM stack, ranging from low-level hardware I/O to high-level cryptographic secret handling. Understanding these levels helps developers identify where specific security threats (such as tampering, information disclosure, or denial of service) can occur and which libraries are responsible for mitigating them.
asymsignlib or psklib. Responsible for device-specific private keys and Pre-Shared Keys (PSK).spdm_secured_message_lib. Responsible for Diffie-Hellman (DH) secrets, session key derivation, key updates, and encryption/decryption.spdm_common_lib, spdm_requester_lib, or spdm_responder_lib. Responsible for building and processing the core SPDM protocol messages.SpdmTransportXXXLib (e.g., Mctp, PciDoe). Responsible for wrapping SPDM messages into transport-specific formats.SPDM_DEVICE_SEND / RECEIVE_MESSAGE_FUNC. Responsible for the raw hardware I/O used to move messages to/from the device.libspdm manages complex encapsulated flows that require multiple message exchanges automatically:
GET_CERTIFICATE requests are issued to retrieve a single certificate chain, libspdm handles the sequence of ENCAPSULATED_RESPONSE and DELIVER_ENCAPSULATED_RESPONSE messages. The encap_flow_handler() is only called once the entire certificate chain has been successfully retrieved.KEY_UPDATE request with UpdateKey or UpdateAllKeys is issued, libspdm automatically handles the subsequent KEY_UPDATE with VerifyNewKey.In SPDM 1.3+, multikey support allows different certificate chains and asymmetric keys to be used for different purposes (e.g., one key for L1/L2 transcripts and another for M1/M2).
An endpoint can support multikey in three ways:
MULTI_KEY_CAP == 0.MULTI_KEY_CAP == 1.MULTI_KEY_CAP == 2 (support depends on the peer endpoint's preference).To handle conditional support (MULTI_KEY_CAP == 2), use libspdm_set_data() with LIBSPDM_DATA_OTHER_PARAMS_SUPPORT and set the SPDM_ALGORITHMS_MULTI_KEY_CONN boolean.
At Level 5 of the trust model, the lowest level of the stack involves device-specific functions for raw communication.
Capabilities:
Security Considerations: