Post Quantum Design in SPDM for Device Authentication and Key Establishment

. The Security Protocol and Data Model (SPDM) defines a set of flows whose purpose includes the authentication of a computing device’s hardware identity. SPDM also allows for the creation of a secure session wherein data communication between two devices has both confidentiality and integrity protection. The present version of SPDM, namely version 1.2, relies upon traditional asymmetric cryptographic algorithms, and these algorithms are known to be vulnerable to quantum attacks. This paper describes the means by which support for post-quantum (PQ) cryptography can be added to the SPDM protocol in order to prepare SPDM for the upcoming world of quantum computing. As part of this paper, we examine the SPDM 1.2 protocol and discuss various aspects of using PQC algorithms, including negotiation of the use of post-quantum cryptography (PQC) algorithms, support for device identity reporting, mechanisms for device authentication, and establishing a secure session. We consider so-called "hybrid modes" where both classical and PQC algorithms are used to achieve security properties, especially given the fact that these modes are important during the transition period from the classical to the quantum computing regime. We also share our experience with implementing a software embodiment of PQC in SPDM, namely "PQ-SPDM", and we provide benchmarks that evaluate a subset of the winning NIST PQC algorithms.


Introduction
The Security Protocol and Data Model (SPDM) 1.2 specication [16] is dened by the Distributed Management Task Force (DMTF). It is used for device identity collection, device authentication, measurement collection and device secure session establishment. The SPDM protocol is a standard for the device community. It is adopted by multiple other standard groups, including Peripheral Component Interconnect (PCI) [35], Compute Express Link (CXL) [11], Mobile Industry Processor Interface (MIPI) [27], and Trusted Computing Group (TCG) [48].
The current SPDM 1.2 specication uses traditional asymmetric cryptographic algorithms, such as RSA, ECDSA, EdDSA for digital signatures and ephemeral Die-Hellman over nite elds (FFDHE) or elliptic curves (ECDHE) for key establishment. Unfortunately, all of the earlier listed algorithms are not quantum safe. Attacks based on Shor's algorithm [44,45,37,39] will break cryptosystems relying on the hardness of integer factorization and discrete logarithms in abelian groups. While the race to build large scale quantum computers is still at an early phase, some devices have long lifetimes and need to be supported beyond 2030. Beyond 2030 is when people expect quantum computers may be available. If a device uses SPDM and needs to be supported beyond 2030, then likely it will need to be PQC-ready and it seems prudent to consider supporting post-quantum cryptography (PQC) [29] in the SPDM protocol.
As far as we know, this is the rst study of PQC algorithm adoption for a device communication security protocol, such as SPDM. This aspect seems to be currently particularly relevant as the IoT market is expanding and on one hand we get more and more devices with diverse security needs (including long-term security requirements) and on the other hand, IoT devices need to be served by backend services where performance is also critical due to the scale factor.

Our Contributions
Our focus in this work is to provide a construction for supporting post-quantum cryptography algorithms in the SPDM protocol, including algorithm negotiation, device certicate transfer, digital signature signing and verication, and authenticated key exchange for secure session. We explored a prototype implementation of the SPDM PQC capability in a device with dierent modes: Traditional mode: PQC algorithms not used, PQC mode: only PQC algorithms are used, Hybrid mode: using both traditional algorithms and PQC algorithms.
The hybrid mode was studied in [5,4] and recommended by NIST during the transition and migration phase [28].
We also consider design challenges for adopting post-quantum algorithms for devices with SPDM capability, such as backward compatibility and message size.
The paper is organized as follows. We start with a brief recap of SPDM in Section 2. Section 3 is dedicated to extending algorithm negotiation phase. Then, we follow with changes to support PQC-ready device identities in Section 4 and device authentication in Section 5. Establishment of secure session keys is treated in detail in Section 6 with security analysis. Finally, we report the results of our proof-of-concept implementation and discussion in Section 7 and Section 8.
The PQC algorithm selection has been driven by National Institute of Standards and Technology (NIST) [30]. While te protocol design is algorithm agnostic and could be used with any new PQC scheme, we report performance results for the four winners of the NIST PQC competition announced very recently.
Note that since symmetric cryptographic algorithms can be used in the quantum computing world with increased key sizes and larger hash digests, we do not study any symmetric cryptographic algorithms for SPDM, such as hash algorithms or Authenticated Encryption with Associated Data (AEAD) algorithms.

SPDM Device Authentication
In the SPDM specication, the authentication of the identity of a device involves two steps: device identication and device authentication.
During the device manufacturing phase, each device is provisioned with a device certicate chain. This certicate chain can be treated as the device identity. The device certicate chain includes all the certicates from a trusted root certicate authority (CA) certicate that chains to a device specic leaf certicate. The device certicate contains the public key that corresponds to the device private key. The root CA endorses the device public / private key pair through the certicate chain. At runtime, an SPDM initiator (requester) may use a GET_CERTIFICATE message to ask an SPDM device (responder) to return its certicate chain as the identity.
The SPDM device authentication uses a challengeresponse mechanism. The initiator (requester) sends a CHALLENGE message to the SPDM device (responder). The CHALLENGE message includes a nonce to prevent replay attacks. Then the device signs the challenge with its private key and returns a CHALLENGE_AUTH message. The authentication initiator can verify the digital signature by using the device public key taken from the certicate chain.

SPDM Secure Session
The SPDM specication allows two devices to establish a secure communication channel, similar to the network Transport Layer Security (TLS) 1.3. An SPDM requester and an SPDM responder may use an authenticated key exchange protocol to derive a set of session keys. The session keys will provide condentiality and integrity for the communication data by using encryption and message authentication.

SPDM Algorithm Negotiation
SPDM specication denes a message NEGOTIATE_ALGORITHMS sent by an SPDM requester and a message ALGORITHMS returned by the SPDM responder that together perform the task of negotiating a common set of cryptographic algorithms.   The other option is to merge the traditional algorithm and PQC algorithm together in one eld. There is no impact to a requester in choosing this approach.
The impact for a responder is that we need to allow the algorithm selection eld to designate one or two algorithms. If only one algorithm is selected, then it is traditional mode or PQC mode. If two algorithms are selected -one that is traditional and the other that is PQC, then it is hybrid mode.
No Combinatorial Explosion Since SPDM allows both entities to negotiate algorithms individually, there is no danger of algorithm combination explosion.
We use a similar technique to handle the hybrid mode. SPDM uses one bit to indicate one algorithm. In order to support N traditional mode ciphers and M PQC mode ciphers, the total required bit space is (N + M ). In the hybrid mode, the requester needs to request the certicate chain twice: one for the traditional certicate chain and the other for the PQC certicate chain.
The X.509 certicate format is out of scope of the SPDM specication so we will not discuss the details here.
The SPDM specication may also allow a device to provision a raw public key of the peer during the manufacturing phase. In this case, the trust of the public key of the peer is established without the certicate based public key infrastructure. If PQC is required in the raw public key scenario then the manufacturer may need to provision the public keys for both a traditional algorithm and a PQC algorithm. The format of the raw public keys is out of scope of the SPDM specication. That raw key format is implementation specic so we don't discuss the details here.

Design Considerations
No Duplication In the hybrid mode, if we require an entity to pass one hybrid certicate chain, then the message includes the identity information. In this case, the authority information just needs to be transmitted once.
If we require an entity to pass both a traditional certicate chain and a PQC certicate chain, then the identity information and authority information will be transmitted twice. Also, both certicate chains needs to be included in the transcript calculation. This is not ecient and might cause latency problems.
In addition, the entity needs to check if the two certicate chains use the same identity information or authority information. If they are dierent, then the entity needs to record the dierence and verify against the pre-dened policy, which adds lots of complexity.
Local Storage Size When an entity considers the compatibility requirements,  [7]. We adopted KEM style algorithm to make the ExchangeData format in PQC mode similar to the one in the traditional mode. The requester's ExchangeData is the requester's public key generated with a PQC KEM key generation. The responder's ExchangeData is the responder's cipher text generated with the PQC KEM encapsulation. In hybrid mode, the ExchangeData eld in the SPDM message should be the concatenation of the two key ExchangeData. The rst part is the traditional key ExchangeData with a xed size, and the second part is the PQC key ExchangeData with a xed size. The format of the PQC key ExchangeData, such as public key and cipher text, should be determined by the selected PQC algorithm. With this approach, only key agreement part of SPDM is converted to PQC. The remaining portion, such as the identity authentication, is unchanged.
We did notice that KEM based authentication [18] was adopted by several standard proposals, such as wireguard [20] and KEMTLS [8,43,42]. However, that will involve a much bigger impact for the SPDM KEY_EXCHANGE message ow, as well as other digital signature based commands such as SPDM CHALLENGE or GET_MEASURMENT. Our future work is to investigate the design decision on how to support SPDM KEM based Authentication and if we can get any benet.

SPDM KEM message ow
For PQC-SPDM, we use a key encapsulation mechanism (KEM) based authenticated key exchange to replace DHE. Fig. 1 shows 3. The responder also generates a 32bit random number (rand r ).
4. Now the responder can prepare the KEY_EXCHANGE_RSP message (keyex1 r ), which is concatenation of the opcode (keyexop r ), the half of the session ID (sid r ), the 32bit random number (rand r ), the KEM cipher text and the responder specic opaque data.  will be used to AEAD the rest of messages in the handshake phase such as FINISH and FINISH_RSP. 6. In order to prevent man-in-the-middle-attacks, the responder shall create a transcript and sign the transcript with its permanent private key (sk r ) and generate the digital signature (sig r ). Per the SPDM specication, the transcript of KEY_EXCHANGE_RSP for signing is the concatenation of the negotiated SPDM protocol version, capability and algorithm (spdmvca), the permanent public certicate chain or public key of the responder as identity information (pk r ), the KEY_EXCHANGE message from initiator (keyex i ) and the response generated KEY_EXCHANGER_RSP message (keyex1 r ).
7. The next step is to create another transcript and MAC the transcript with the ephemeral nish key (ef k) and generate the MAC (mac r ). Per the SPDM specication, the transcript of KEY_EXCHANGE_RSP for MAC is the concatenation of the transcript of KEY_EXCHANGE_RSP for signing and the digital signature (sig r ).
8. The nal full KEY_EXCHANGE_RSP message (keyex r ) is the concatenation of the response generated KEY_EXCHANGER_RSP message (keyex1 r ), the digital signature (sig r ) and the MAC (mac r ). and generate the shared key.
2. The initiator can follow the SPDM dened key schedule algorithm to derive the ephemeral nish key (ef k), initiator direction ephemeral handshake key (ehk i ) and responder direction ephemeral handshake key (ehk r ). These keys should be same as the one derived by the responder.
3. Then the requester shall follow the same process to construct the transcript of KEY_EXCHANGE_RSP for signing and verify the digital signature (sig r ) with the responder's permanent public key (pk r ). If the digital signature verication fails, then the initiator shall terminate the session handshake immediately.
4. The requester shall follow the same process to construct the transcript of KEY_EXCHANGE_RSP for MAC and verify the MAC (mac r ) with the ephemeral nish key (ef k). If the MAC verication fails, then the initiator shall terminate the session handshake immediately.

At this point the initiator starts preparing the FINISH message (f inish1 i )
to close the handshake.
6. If mutual authentication is required, the initiator shall create the transcript of FINISH for signing, which is the concatenation of spdmvca, the permanent public certicate chain or public key of the responder as identity information (pk r ), the KEY_EXCHANGE message from initiator (keyex i ) and the response generated KEY_EXCHANGER_RSP message (keyex r ), the permanent public certicate chain or public key of the initiator as identity information (pk i ) and the initiator generated FINISH message (f inish1 i ). The initiator needs to sign the transcript with its permanent private key (sk i ) and generate the digital signature (sig i ).
7. Then the initiator shall create the transcript of FINISH for MAC, which is the concatenation of the transcript of FINISH for signing and the digital signature (sig i ). The initiator needs to MAC the transcript with the ephemeral nish key (ef k) and generate the MAC (mac i ). 8. The full FINISH message (f inishp i ) is the concatenation of the requester generated FINISH message (f inish1 i ), the digital signature (sig i ) and the MAC (mac i ). The digital signature is absent if mutual authentication is not required.
9. The nal FINISH message (f inish i ) is the AEAD of the full FINISH message (f inishp i ) with initiator direction handshake key (ehk i ).

Fourth Message: FINISH_RSP (responder to initiator)
Once the responder receives the FINISH message, it performs AEAD decryption and veries the AEAD MAC.
1. If mutual authentication is required, the responder needs to verify the digital signature with the initiator's permanent public key (pk i ). If the digital signature verication fails, then the responder shall terminate the session handshake immediately.
2. The responder needs to verify the MAC with the ephemeral nish key (ef k).
If the MAC verication fails, then the responder shall terminate the session handshake immediately.
3. As the nal step, the responder creates the FINISH_RSP message (f inishp r ). 4. The nal FINISH_RSP message (f inish r ) is the AEAD of the responder generated FINISH_RSP message (f inishp r ) with responder direction handshake key (ehk r ).
After the requester receives the FINISH_RSP, it performs AEAD decryption and veries the AEAD MAC. If the AEAD MAC verication passes, then the secure session is setup between the initiator and the responder. The session application message after the handshake phase is unchanged, which uses the AEAD encryption.
In hybrid mode, there will be two shared secrets, including the traditional Die-Hellman ephemeral (DHE) secret and the PQC shared secret. We concatenate them together as the nal SPDM key exchange shared secret and input it to the SPDM key schedule algorithm.
Note that in the SPDM specication, the SPDM key schedule algorithm names the SPDM key exchange shared secret to be "DHE Secret" because the traditional algorithms only support DHE or ECDHE. We use a new term "key exchange shared secret" to avoid any misunderstanding. In traditional mode, "key exchange shared secret" is "DHE Secret". In PQC mode, "key exchange shared secret" is "PQC shared secret". In hybrid mode, "key exchange shared secret" is "the concatenation of traditional DHE secret and PQC shared secret".

Security Analysis
KEM based key agreement In this proposal, we replaced the DHE based key agreement with a KEM based key agreement. This mechanism is similar to the key exchange model in TLS 1.3 hybrid design [47]. KEM.Encap(epk)->(sharedkey, wrappedkey): To select an exponent y and calculate g y and g x * y , then sharedkey = g x * y , wrappedkey = g y .
The details of DH based KEM are described in RFC9180 [2]. In the current SPDM and NIST PQC KEM algorithms, the length of shared_secret is xed. As such, the length of f inal_shared_secret is also xed.
The f inal_shared_secret shall have hybrid property: The secret is secure if at least one of the key exchange algorithm is secure. The analysis of KEM combiners were provided in [4,19].

Results
We have developed a prototype that implements the above PQ-enabled SPDM variant using post-quantum algorithms library liboqs [31] on top of an SPDM implementation [1]. The implementation can run in both the Windows and Linux SPDM emulators. It can run in a Field Programmable Gate Array (FPGA) smart card and communicate with a host system on Intel Core CPU. We collected data for the winning PQC algorithms (Kyber as a KEM and DILITHIUM, FALCON, SPHINCS+ as digital signature primitives) described in the status report of NIST PQC 3rd round nalists [30] and compare them with the RSA and ECC in traditional mode and hybrid mode. For parameters, we choose NIST security level 1, 3 and 5 separately. The data has been collected on Intel Core(TM) i7-8665U CPU @ 1.90 GHz.
Usually, a device is an SPDM responder and a host operating system is an SPDM requester. We collect data from SPDM requester and responder separately. We considered two typical use cases: 1) device authentication which includes digital signature signing and verication, 2) one-way authenticated secure session establishment, which includes key establishment and digital sig-   Fig. 4 show the data for the SPDM requester. Fig. 5 and Fig. 6 show the data for the SPDM responder. L1, L3 and L5 means the minimal NIST security level for the combination. The algorithm list is below (note that for hybrid modes we have both classical and PQC algorithm suites): The data on the requester side shows that the cryptography timing caused by the hybrid mode is less than double of the traditional time. Kyber, DILITHIUM and FALCON all demonstrate good performance. The data on the responder side shows that the digital signature process contributed the majority of time.
DILITHIUM is much better than FALCON. However, SPHINCS+ takes significantly longer time in both signature generation and verication.
Challenges The SPDM specication denes the digital signature data or the public key ExchangeData as xed size elds. However, some PQC algorithms will generate a signature with variable size, such as FALCON. The actual size is smaller than the maximum size. The liboqs implementation uses the rst four bytes to store the actual size. Care should be taken to move the variable signature data to or from a xed size buer to avoid buer overows.
If there is a transport message size limitation, we have to use chunking mechanism to transfer the large signature or public key. Chunking will increase the overhead on message disassembling and reassembling. However, even the transport layer has capability to transfer a large message, we may still consider chunking. The SPDM transport layer might not be reliable. As such, a package may be lost or broken during transmission, then a message retry maybe needed. The overhead to retry a large message is bigger than the one to retry a small chunked messaged. The implementer needs to balance the overhead of chunking and the overhead of message retry.
Backward Compatibility According to the previous discussion, the PQ-SPDM can achieve partial backward compatibility with SPDM 1.2 protocol. See Table 3.

Conclusions
In this paper, we proposed to a way to add PQC capability to the SPDM protocol. This addition entailed minimal modication of the existing SPDM protocol.
We successfully created a prototype based upon the proposal. This prototype shows that PQC-SPDM is feasible in practice. We hope our analysis will help prepare the industry to adopt SPDM for device rmware with long-lived service requirements. This is imperative given the looming need to have more widespread support for post-quantum security capabilities. We notice that the latency caused by the digital signature signing on the responder side might become a performance concern in the future. The KEM based authentication [18] could be a way to resolve this timing problem. We will do the research on that area in the future.