# Post Quantum Design in SPDM for Device Authentication and Key Establishment

^{*}

## Abstract

**:**

## 1. Introduction

#### 1.1. The Threat of Quantum Computers

#### 1.2. Device Security and SPDM

#### 1.3. Our Contributions

- Traditional mode: PQC algorithms are not used.
- PQC mode: only PQC algorithms are used.
- Hybrid mode: both traditional algorithms and PQC algorithms are used.

#### 1.4. Related Work

## 2. SPDM Background

#### 2.1. SPDM Device Authentication

`GET_CERTIFICATE`message to ask an SPDM device, also known as an “SPDM responder”, to return its certificate chain as the device’s identity.

`CHALLENGE`message to the SPDM device (responder). The

`CHALLENGE`message includes a nonce to prevent any replay attacks. As a next step, the device signs the challenge with its private key and returns a

`CHALLENGE_AUTH`message. The authentication initiator, in turn, can verify the digital signature by using the device public key extracted from the certificate chain.

#### 2.2. SPDM Secure Session

#### 2.3. SPDM Algorithm Negotiation

`NEGOTIATE_ALGORITHMS`, which is sent by an SPDM requester, along with a message

`ALGORITHMS`, which in turn is returned by the SPDM responder. Together these two messages perform the task of negotiating a common set of cryptographic algorithms. The cryptographic algorithm selection in SPDM is different from the implementation mechanism in TLS. Specifically, a TLS entity selects one cipher suite that covers all algorithms, including key exchange or agreement, authentication, block or stream ciphers, and message authentication. An SPDM requester, on the other hand, lists all individual algorithms it can support, such as hash algorithms, responder direction asymmetric digital signature algorithms, requester direction asymmetric digital signature algorithms, key exchange algorithms and Authenticated Encryption with Associated Data (AEAD) ciphers. With this requester information in hand, the SPDM responder chooses one of these options in each category as the final negotiated algorithm. This differs from TLS cipher suites in that each type of SPDM algorithm can be negotiated separately.

## 3. Post-Quantum Design for SPDM Algorithm Negotiation

`NEGOTIATE_ALGORITHMS`request and

`ALGORITHMS`response messages. As such, we need to use the

`GET_CAPABILITIES`request and

`CAPABILITIES`response messages. To accommodate this use-case, we have added additional capabilities bits, including:

- PQC Capability: this means an entity supports PQC mode;
- Hybrid Capability: this means an entity support hybrid mode.

`CTExponent`timing parameter, which is the maximum amount of time for cryptographic processing. A PQC algorithm might have different timing requirements compared to a traditional algorithm. In addition, the timing in hybrid mode could be the addition of timing for both traditional mode and PQC only mode. Unfortunately, the timing parameter in

`CAPABILITIES`is negotiated before the algorithm negotiation in

`ALGORITHMS`. As such, it is difficult to use a single

`CTExponent`to indicate the timing parameter of three different modes. To address this concern, the setting of a maximum value is one option, but this maximum value might cause the requester to wait for en excessive period prior to a retry. The other option is to add a new

`PQCTExponent`to indicate the PQC-specific timing. With this new parameter in hand, the final interpretation of the timing parameter could be:

- Timing in Traditional Mode: ${2}^{\mathtt{CTExponent}}$;
- Timing in PQC Mode: ${2}^{\mathtt{PQCTExponent}}$;
- Timing in Hybrid Mode: ${2}^{\mathtt{CTExponent}}+{2}^{\mathtt{PQCTExponent}}$.

#### 3.1. Design Considerations

#### 3.1.1. Mode Identification

#### 3.1.2. No Combinatorial Explosion

#### 3.1.3. Security Level Matching

#### 3.1.4. Algorithm Set Matching

#### 3.1.5. Hash Algorithm Used in Digital Signature

`SPHINCS+-SHA256-128f-robust`or

`SPHINCS+-SHAKE256-128f-robust`are potential options.

## 4. Post-Quantum Design for SPDM Device Identity

`GET_CERTIFICATE`command to retrieve one X.509 certificate chain and the

`SET_CERTIFICATE`command to provision one. This one certificate chain contains both a traditional algorithm and a PQC algorithm. In either PQC mode or traditional mode, this hybrid certificate chain may still be used since the verifier can just skip the unneeded algorithm and certificate digital signature.

`GET_CERTIFICATE`command to indicate which type of certificate chain is required, namely a traditional certificate chain or a PQC certificate chain. The Certificate Type can be in

`param2`and includes

- Traditional Certificate Chain (0),
- PQC Certificate Chain (1),
- Hybrid Certificate Chain (2).

#### 4.1. Design Considerations

#### 4.1.1. No Duplicate Message in Transport

#### 4.1.2. Local Storage Size

#### 4.1.3. Transport Message Size

`GET_CERTIFIACTE`request message includes both 16-bit

`OFFSET`and 16-bit

`LENGTH`fields to indicate the requested certificate data buffer offset and length. The

`CERTIFICATE`response message includes a 16-bit

`PortionLength`and 16-bit

`RemainderLength`to indicate the transmitted data buffer length and remaining data buffer length, respectively. SPDM does not rely on any low level transport layer fragmentation support. A more generic chunking mechanism (

`CHUNK_CAP`) is defined in SPDM 1.2. As such, all SPDM messages can support chunking after the chunking capability is negotiated, such as the

`SET_CERTIFIACTE`and

`CSR`.

`GET_CERTIFICATE`command cannot meet the requirement. We may need to extend the 16-bit offset and length field to 32 bits in a new version of

`GET_CERTIFICATE`, or we can redefine

`GET_CERTIFICATE`to use the generic SPDM 1.2 chunking mechanism. However, considering a recent attack [59] on Rainbow, these PQC algorithms with larger key size might not be a concern going forward.

## 5. Post-Quantum Design for SPDM Device Authentication

`CHALLENGE_AUTH`response,

`MEASUREMENTS`response,

`KEY_EXCHANGE_RSP`response, and

`FINISH`request, require a digital signature. The digital signature can include RSA, ECDSA, EdDSA, and SM2. The SPDM specification defines the binary format of the digital signature for a specific algorithm with a fixed size.

#### 5.1. Message Flow

#### 5.1.1. First Message

`CHALLENGE`(initiator to responder)

- The initiator generates a 256-bit random number ($ran{d}_{i}$) as a challenge value to prevent the replay attacks.
- The
`CHALLENGE`message ($challeng{e}_{i}$) is the concatenation of the opcode ($challengeo{p}_{i}$), the random number ($ran{d}_{i}$), and the initiator specific opaque data.

#### 5.1.2. Second Message

`CHALLENGE_AUTH`(responder to initiator)

- The responder also generates a 256-bit random number ($ran{d}_{r}$).
- The responder can prepare the
`CHALLENGE_AUTH`message ($challengeauth{1}_{r}$), which is concatenation of the opcode ($challengeautho{p}_{r}$), the random number ($ran{d}_{r}$), and the responder specific opaque data. - Now, the responder creates the transcript for authentication ($thauth$), which is the concatenation of the negotiated SPDM protocol version, capability and algorithm ($spdmvca$), the permanent public certificate chain or public key of the responder as identity information ($p{k}_{r}$), the
`CHALLENGE`message from initiator ($challeng{e}_{i}$), and the response generated`CHALLENGE_AUTH`message ($challengeauth{1}_{r}$). - The next step is to sign the transcript ($thauth$) with the responder secret key ($s{k}_{r}$) and generate the signature ($si{g}_{r}$).
- The final full
`CHALLENGE_AUTH`message ($challengeaut{h}_{r}$) is the concatenation of the response generated`CHALLENGE_AUTH`message ($challengeauth{1}_{r}$) and the signature ($si{g}_{r}$).

`CHALLENGF_AUTH`, it will follow the same process to construct the transcript for authentication ($thauth$) and verify the signature ($si{g}_{r}$) with the responder public key ($p{k}_{r}$). If the signature verification passes, then the initiator authenticates the responder successfully.

#### 5.2. Design Considerations

#### 5.2.1. Hybrid Digital Signature

#### 5.2.2. No Duplicate Message in Transport

`CHALLENGE/CHALLENGE_AUTH`twice, namely one for classic mode and the other for PQC mode. Instead, the transcript calculation just needs to happen one time.

#### 5.2.3. Transport Message Size

`picnic_{L3,L5}_{FS,UR,full}`can be larger than ${2}^{16}$ bytes.

`CHALLENGE_AUTH`response,

`MEASUREMENTS`response,

`KEY_EXCHANGE_RSP`response, and

`FINISH`request message. In order to support the transportation of these large messages, we can use the generic SPDM 1.2 chunking message for these instances.

#### 5.2.4. Timing

`PQCTExponent`should be larger than the maximum signing time for the supported PQC signature algorithms.

## 6. Post-Quantum Design for SPDM Secure Session

`ExchangeData`) for both the SPDM requester and the SPDM responder.

`ExchangeData`format in PQC mode. This is similar to the approach in traditional mode. In this case, the requester’s

`ExchangeData`is the requester’s public key generated using the PQC KEM key generation algorithm. The responder’s

`ExchangeData`is the responder’s cipher text generated using the PQC KEM encapsulation. In hybrid mode, the

`ExchangeData`field in the SPDM message should be the concatenation of the two key

`ExchangeData`fields. The first part is the traditional key

`ExchangeData`with a fixed size, and the second part is the PQC key

`ExchangeData`with a fixed 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 the key agreement part of SPDM is converted to PQC. The remaining portion, such as the identity authentication, is unchanged.

`KEY_EXCHANGE`message flow, as well as other digital-signature-based commands such as SPDM

`CHALLENGE`or

`GET_MEASURMENT`. Our future work entails exploring these various design approaches to support SPDM KEM-based authentication, including analysis of any potential benefit therein.

#### 6.1. SPDM KEM Message Flow

`GET_VERSION/VERSION`,

`GET_CAPABILITIES/CAPABILITIES`, and

`NEGOTIATE_ALGORITHMS/ALGORITHMS`.

#### 6.1.1. First Message

`KEY_EXCHANGE`(initiator to responder)

- The initiator needs to use the KEM algorithm to generate an ephemeral private/public key pair ($es{k}_{i}$ and $ep{k}_{i}$).
- To identify the session, the initiator generates a 16-bit session ID ($si{d}_{i}$) as the first half of a 32-bit session ID.
- To prevent the replay attacks, the initiator generates a 256-bit random number ($ran{d}_{i}$).
- The
`KEY_EXCHANGE`message ($keye{x}_{i}$) is the concatenation of the opcode ($keyexo{p}_{i}$), the initiator generated session ID ($si{d}_{i}$), the random number ($ran{d}_{i}$), the ephemeral public key ($ep{k}_{i}$), and the initiator specific opaque data.

#### 6.1.2. Second Message

`KEY_EXCHANGE_RSP`(responder to initiator)

- After the responder receives the
`KEY_EXCHANGE`message, the responder uses the KEM algorithm to encapsulate the ephemeral public key ($ep{k}_{i}$) and derives the shared session key and the cipher text. - The responder generates a 16-bit session ID ($si{d}_{r}$) as the second half of the 32-bit session ID. The final session ID is the concatenation of the initiator’s session ID and the responder’s session ID ($si{d}_{i}\left|\right|si{d}_{r}$).
- The responder also generates a 256-bit random number ($ran{d}_{r}$).
- Now, the responder can prepare the
`KEY_EXCHANGE_RSP`message ($keyex{1}_{r}$), which is concatenation of the opcode ($keyexo{p}_{r}$), the half of the session ID ($si{d}_{r}$), the random number ($ran{d}_{r}$), the KEM cipher text, and the responder specific opaque data. - From the shared key, the responder uses the SPDM-defined key schedule algorithm to derive the ephemeral finish key ($efk$), initiator direction ephemeral handshake key ($eh{k}_{i}$), and responder direction ephemeral handshake key ($eh{k}_{r}$). The ephemeral finish key ($efk$) will be used to generate a message authentication code (MAC) for the transcript. The ephemeral handshake key will be used to AEAD the rest of messages in the handshake phase such as
`FINISH`and`FINISH_RSP`. - In order to prevent man-in-the-middle-attacks, the responder will create a transcript, sign the transcript with its permanent private key ($s{k}_{r}$), and generate the digital signature ($si{g}_{r}$). Per the SPDM specification, the transcript of
`KEY_EXCHANGE_RSP`for signing is the concatenation of the negotiated SPDM protocol version, capability and algorithm ($spdmvca$), the permanent public certificate chain or public key of the responder as identity information ($p{k}_{r}$), the`KEY_EXCHANGE`message from initiator ($keye{x}_{i}$), and the response generated`KEY_EXCHANGER_RSP`message ($keyex{1}_{r}$). - The next step is to create another transcript and MAC the transcript with the ephemeral finish key ($efk$) and generate the MAC ($ma{c}_{r}$). Per the SPDM specification, the transcript of
`KEY_EXCHANGE_RSP`for MAC is the concatenation of the transcript of`KEY_EXCHANGE_RSP`for signing and the digital signature ($si{g}_{r}$). - The final full
`KEY_EXCHANGE_RSP`message ($keye{x}_{r}$) is the concatenation of the response generated`KEY_EXCHANGER_RSP`message ($keyex{1}_{r}$), the digital signature ($si{g}_{r}$), and the MAC ($ma{c}_{r}$).

#### 6.1.3. Third Message

`FINISH`(initiator to responder)

- Once the initiator receives the
`KEY_EXCHANGE_RSP`message, it can use the KEM algorithm to decapsulate the cipher text with its ephemeral private key ($es{k}_{i}$) and generate the shared key. - The initiator can follow the SPDM-defined key schedule algorithm to derive the ephemeral finish key ($efk$) and initiate the direction ephemeral handshake key ($eh{k}_{i}$) and the responder direction ephemeral handshake key ($eh{k}_{r}$). These keys should be same as the one derived by the responder.
- Then, the requester will follow the same process to construct the transcript of
`KEY_EXCHANGE_RSP`for signing and verifying the digital signature ($si{g}_{r}$) with the responder’s permanent public key ($p{k}_{r}$). If the digital signature verification fails, then the initiator will terminate the session handshake immediately. - The requester will follow the same process to construct the transcript of
`KEY_EXCHANGE_RSP`for MAC and verify the MAC ($ma{c}_{r}$) with the ephemeral finish key ($efk$). If the MAC verification fails, then the initiator will terminate the session handshake immediately. - At this point, the initiator starts preparing the
`FINISH`message ($finish{1}_{i}$) to close the handshake. - If mutual authentication is required, the initiator will create the transcript of
`FINISH`for signing, which is the concatenation of $spdmvca$, the permanent public certificate chain or public key of the responder as identity information ($p{k}_{r}$), the`KEY_EXCHANGE`message from initiator ($keye{x}_{i}$) and the response generated`KEY_EXCHANGER_RSP`message ($keye{x}_{r}$), the permanent public certificate chain or public key of the initiator as identity information ($p{k}_{i}$), and the initiator generated FINISH message ($finish{1}_{i}$). The initiator needs to sign the transcript with its permanent private key ($s{k}_{i}$) and generate the digital signature ($si{g}_{i}$). - Then the initiator will create the transcript of
`FINISH`for MAC, which is the concatenation of the transcript of`FINISH`for signing and the digital signature ($si{g}_{i}$). The initiator needs to MAC the transcript with the ephemeral finish key ($efk$) and generate the MAC ($ma{c}_{i}$). - The full
`FINISH`message ($finish{p}_{i}$) is the concatenation of the requester generated`FINISH`message ($finish{1}_{i}$), the digital signature ($si{g}_{i}$), and the MAC ($ma{c}_{i}$). The digital signature is absent if mutual authentication is not required. - The final
`FINISH`message ($finis{h}_{i}$) is the AEAD of the full`FINISH`message ($finish{p}_{i}$) with the initiator direction handshake key ($eh{k}_{i}$).

#### 6.1.4. Fourth Message

`FINISH_RSP`(responder to initiator)

`FINISH`message, it performs AEAD decryption and verifies the AEAD MAC.

- If mutual authentication is required, the responder needs to verify the digital signature with the initiator’s permanent public key ($p{k}_{i}$). If the digital signature verification fails, then the responder will terminate the session handshake immediately.
- The responder needs to verify the MAC with the ephemeral finish key ($efk$). If the MAC verification fails, then the responder will terminate the session handshake immediately.
- As the final step, the responder creates the
`FINISH_RSP`message ($finish{p}_{r}$). - The final
`FINISH_RSP`message ($finis{h}_{r}$) is the AEAD of the responder-generated`FINISH_RSP`message ($finish{p}_{r}$) with responder direction handshake key ($eh{k}_{r}$).

`FINISH_RSP`, it performs AEAD decryption and verifies the AEAD MAC. If the AEAD MAC verification passes, then the secure session is set up between the initiator and the responder. The session application message after the handshake phase is unchanged, which uses the AEAD encryption.

#### 6.2. Security Analysis

#### 6.2.1. KEM-Based Key Agreement

- KEM.Gen()->(esk,epk): A probabilistic key generation algorithm. It generates an ephemeral public key (epk) and an ephemeral secret key (esk).
- KEM.Encap(epk)->(sharedkey, wrappedkey): A probabilistic encapsulation algorithm. It takes epk as input and outputs a shared secret (sharedkey) and a ciphertext pk wrapper (wrappedkey).
- KEM.Decap(esk, wrappedkey)->sharedkey: A decapsulation algorithm. It takes esk and wrappedkey as input and outputs a shared key.

- KEM.Gen()->(esk,epk): To select an exponent x and calculate ${g}^{x}$, then esk = x, epk = ${g}^{x}$.
- KEM.Encap(epk)->(sharedkey, wrappedkey): To select an exponent y and calculate ${g}^{y}$ and ${g}^{x\ast y}$, then sharedkey = ${g}^{x\ast y}$, wrappedkey = ${g}^{y}$.
- KEM.Decap(esk, wrappedkey)->sharedkey: To compute sharedkey = ${g}^{x\ast y}$.

#### 6.2.2. Shared Secret Combiner

#### 6.3. Design Considerations

#### 6.3.1. Hybrid Key Exchange

`ExchangeData`separately and then concatenate them together. We do not pursue the option of defining a new key exchange algorithm to combine both traditional and PQC algorithms. This aligns with the current practice in TLS hybrid mode.

#### 6.3.2. No Duplicate Message in Transport

`ExchangeData`are combined together. There is no need to send the

`KEY_EXCHANGE`message twice, namely one for classic mode and the other for PQC mode. The transcript calculation just needs to happen one time.

#### 6.3.3. Hybrid Key Schedule

#### 6.3.4. Transport Message Size

`classic-McEliece-{6688128,6960119,8192128}`exceeds ${2}^{16}$ bytes.

`KEY_EXCHANGE`request and response messages need to pass the key

`ExchangeData`. In order to support large message transportation, we can use the generic SPDM 1.2 chunking message for such transactions.

#### 6.3.5. Timing

`PQCTExponent`should be larger than the maximum encapsulation time for the supported KEM algorithms.

## 7. Results

#### 7.1. Test Environment

#### 7.2. Test Method

`GET_CERTIFICATE`, digital signature signing (CHAL_SIGN) and verification (CHAL_VERIFY) in

`CHALLENGE`for authentication, KEM generation (KEY_EX_KEM_GEN), encapsulation (KEY_EX_KEM_ENCAP), decapsulation (KEY_EX_KEM_DECAP) in

`KEY_EXCHANGE`, and digital signature signing (KEY_EX_SIGN) and verification (KEY_EX_VERIFY) in

`KEY_EXCHANGE`for authentication secure session setup.

#### 7.3. Test Algorithm

- L1-RSA:
`ECDHE_secp256r1`+`RSASSA_3072` - L1-EC:
`ECDHE_secp256r1`+`ECDSA_NIST_P256` - L1-RSA+KB+DL:
`ECDHE_secp256r1`&`Kyber512`+`RSASSA_3072`&`Dilithium2` - L1-EC+KB+DL:
`ECDHE_secp256r1`&`Kyber512`+`ECDSA_NIST_P256`&`Dilithium2` - L1-EC+KB90+DLA:
`ECDHE_secp256r1`&`Kyber512-90s`+`ECDSA_NIST_P256`&`Dili-thium2-AES` - L1-RSA+KB+FC:
`ECDHE_secp256r1`&`Kyber512`+`RSASSA_3072`&`Falcon-512` - L1-EC+KB+FC:
`ECDHE_secp256r1`&`Kyber512`+`ECDSA_NIST_P256`&`Falcon-512` - L1-RSA+KB+SPHRK:
`ECDHE_secp256r1`&`Kyber512`+`RSASSA_3072`&`SPHINCS+-Haraka-128f-robust` - L1-RSA+KB+SPSHA:
`ECDHE_secp256r1`&`Kyber512`+`RSASSA_3072`&`SPHINCS+-SHA256-128f-robust` - L1-RSA+KB+SPSHK:
`ECDHE_secp256r1`&`Kyber512`+`RSASSA_3072`&`SPHINCS+-SHAKE256-128f-robust` - L1-EC+KB+SPHRK:
`ECDHE_secp256r1`&`Kyber512`+`ECDSA_NIST_P256`&`SPHINCS+-Haraka-128f-robust` - L1-EC+KB+SPSHA:
`ECDHE_secp256r1`&`Kyber512`+`ECDSA_NIST_P256`&`SPHINCS+-SHA256-128f-robust` - L1-EC+KB+SPSHK:
`ECDHE_secp256r1`&`Kyber512`+`ECDSA_NIST_P256`&`SPHINCS+-SHAKE256-128f-robust` - L3-EC:
`ECDHE_secp384r1`+`ECDSA_NIST_P384` - L3-EC+KB+DL:
`ECDHE_secp384r1`&`Kyber768`+`ECDSA_NIST_P384`&`Dilithium3` - L3-EC+KB90+DLA:
`ECDHE_secp384r1`&`Kyber768-90s`+`ECDSA_NIST_P384`&`Dili-thium3-AES` - L3-EC+KB+FC:
`ECDHE_secp384r1`&`Kyber768`+`ECDSA_NIST_P384`&`Falcon-1024` - L5-EC:
`ECDHE_secp521r1`+`ECDSA_NIST_P521` - L5-EC+KB+DL:
`ECDHE_secp521r1`&`Kyber1024`+`ECDSA_NIST_P521`&`Dilithium5` - L5-EC+KB90+DLA:
`ECDHE_secp521r1`&`Kyber1024-90s`+`ECDSA_NIST_P521`&`Dili-thium5-AES` - L5-EC+KB+FC:
`ECDHE_secp521r1`&`Kyber1024`+`ECDSA_NIST_P521`&`Falcon-1024`

## 8. Discussion

#### 8.1. Challenges

`ExchangeData`as fixed size fields. 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 first four bytes to store the actual size. Care should be taken when moving the variable signature data to or from a fixed size buffer in order to avoid buffer overflows.

#### 8.2. Backward Compatibility

## 9. Conclusions and Future Work

## Author Contributions

## Funding

## Data Availability Statement

## Conflicts of Interest

## References

- Shor, P.W. Algorithms for quantum computation: Discrete logarithms and factoring. In Proceedings of the 35th Annual Symposium on Foundations of Computer Science, Santa Fe, NM, USA, 20–22 November 1994; pp. 124–134. [Google Scholar] [CrossRef]
- Shor, P.W. Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. SIAM J. Comput.
**1997**, 26, 1484–1509. [Google Scholar] [CrossRef] - Proos, J.; Zalka, C. Shor’s Discrete Logarithm Quantum Algorithm for Elliptic Curves. Quantum Inf. Comput.
**2003**, 3, 317–344. [Google Scholar] [CrossRef] - Roetteler, M.; Naehrig, M.; Svore, K.M.; Lauter, K. Quantum Resource Estimates for Computing Elliptic Curve Discrete Logarithms. In Proceedings of the Advances in Cryptology—ASIACRYPT 2017, Hong Kong, China, 3–7 December 2017; Springer International Publishing: Cham, Switzerland, 2017; pp. 241–270. [Google Scholar] [CrossRef]
- Mosca, M.; Piani, M. 2021 Quantum Threat Timeline Report. Global Risk Institute. 2021. Available online: https://globalriskinstitute.org/publications/2021-quantum-threat-timeline-report/ (accessed on 10 August 2022).
- NIST. Post-Quantum Cryptography Project. 2016. Available online: https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization (accessed on 10 August 2022).
- DMTF. Security Protocol and Data Model (SPDM) Specification, DSP0274. 2021. Available online: https://www.dmtf.org/dsp/DSP0274 (accessed on 10 August 2022).
- PCI SIG. PCI-SIG Homepage. 2022. Available online: https://pcisig.com/ (accessed on 10 August 2022).
- CXL. Compute Express Link Homepage. 2022. Available online: https://computeexpresslink.org/ (accessed on 10 August 2022).
- MIPI. MIPI Home Page. 2022. Available online: https://www.mipi.org/ (accessed on 10 August 2022).
- TCG. TCG Home Page. 2022. Available online: https://trustedcomputinggroup.org/ (accessed on 10 August 2022).
- PCI SIG. PCI Express Base Specifiction Revision 6.0. 2022. Available online: https://pcisig.com/specifications (accessed on 10 August 2022).
- CXL 3.0. CXL 3.0 Specification. 2022. Available online: https://www.computeexpresslink.org/download-the-specification/ (accessed on 10 August 2022).
- PCI SIG. PCI TEE Device Interface Security Protocol (ECN). 2022. Available online: https://pcisig.com/specifications (accessed on 10 August 2022).
- MIPI. MIPI Security Framework. Available online: https://www.mipi.org/sites/default/files/How-the-MIPI-Security-Framework-Protects-Automotive-SerDes-Applications-from-Security-Risks.pdf (accessed on 10 August 2022).
- TCG. TCG Platform Firmware Profile 1.05. Available online: https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ (accessed on 10 August 2022).
- OCP. OCP Attestation of System Components v1.0. Available online: https://www.opencompute.org/documents/attestation-v1-0-20201104-pdf (accessed on 10 August 2022).
- Ounsworth, M.; Pala, M. Composite Signatures for Use in Internet PKI. Internet-Draft draft-ounsworth-pq-composite-sigs-06, Internet Engineering Task Force. 2022; Work in Progress. [Google Scholar]
- Truskovsky, A.; Geest, D.V.; Fluhrer, S.; Kampanakis, P.; Ounsworth, M.; Mister, S. Multiple Public-Key Algorithm X.509 Certificates. Internet-Draft draft-truskovsky-lamps-pq-hybrid-x509-01, Internet Engineering Task Force. 2018; Expired Draft. [Google Scholar]
- Ounsworth, M. Post-quantum Multi-Key Mechanisms for PKIX-like protocols; Problem Statement and Overview of Solution Space. Internet-Draft draft-pq-pkix-problem-statement-01, Internet Engineering Task Force. 2019; Work in Progress. [Google Scholar]
- Kampanakis, P.; Panburana, P.; Daw, E.; Geest, D.V. The Viability of Post-quantum X.509 Certificates. Cryptology ePrint Archive, Report 2018/063. 2018. Available online: https://ia.cr/2018/063 (accessed on 10 August 2022).
- Pradel, G.; Mitchell, C.J. Post-Quantum Certificates for Electronic Travel Documents. In Proceedings of the Computer Security: ESORICS 2020 International Workshops, Guildford, UK, 17–18 September 2020; Springer: Berlin/Heidelberg, Germany, 2020; pp. 56–73. [Google Scholar] [CrossRef]
- Cho, J.Y.; Sergeev, A. Post-quantum MACsec in Ethernet Networks. J. Cyber Secur. Mobil.
**2021**, 10, 161–176. [Google Scholar] [CrossRef] - Fluhrer, S.; Kampanakis, P.; McGrew, D.; Smyslov, V. Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security. In RFC 8784. 2020. Available online: https://doi.org/10.17487/RFC8784 (accessed on 10 August 2022).
- Tjhai, C.; Tomlinson, M.; Bartlett, G.; Fluhrer, S.; Geest, D.V.; Garcia-Morchon, O.; Smyslov, V. Multiple Key Exchanges in IKEv2. Internet-Draft draft-ietf-ipsecme-ikev2-multiple-ke-04, Internet Engineering Task Force. 2021; Work in Progress. [Google Scholar]
- Stebila, D.; Fluhrer, S.; Gueron, S. Hybrid key exchange in TLS 1.3. Internet-Draft draft-ietf-tls-hybrid-design-04, Internet Engineering Task Force. 2022; Work in Progress. [Google Scholar]
- Celi, S.; Schwabe, P.; Stebila, D.; Sullivan, N.; Wiggers, T. KEM-based Authentication for TLS 1.3. Internet-Draft draft-celi-wiggers-tls-authkem-01, Internet Engineering Task Force. 2022; Work in Progress. [Google Scholar]
- Campagna, M.; Crockett, E. Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer Security 1.2 (TLS). Internet-Draft draft-campagna-tls-bike-sike-hybrid-07, Internet Engineering Task Force. 2021; Expired Draft. [Google Scholar]
- Kiefer, F.; Kwiatkowski, K. Hybrid ECDHE-SIDH Key Exchange for TLS. Internet-Draft draft-kiefer-tls-ecdhe-sidh-00, Internet Engineering Task Force. 2018; Expired Draft. [Google Scholar]
- Schanck, J.M.; Stebila, D. A Transport Layer Security (TLS) Extension For Establishing An Additional Shared Secret. Internet-Draft draft-schanck-tls-additional-keyshare-00, Internet Engineering Task Force. 2017; Expired Draft. [Google Scholar]
- Whyte, W.; Zhang, Z.; Fluhrer, S.; Garcia-Morchon, O. Quantum-Safe Hybrid (QSH) Key Exchange for Transport Layer Security (TLS) version 1.3. Internet-Draft draft-whyte-qsh-tls13-06, Internet Engineering Task Force. 2017; Expired Draft. [Google Scholar]
- Schanck, J.M.; Whyte, W.; Zhang, Z. Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security (TLS) version 1.2. Internet-Draft draft-whyte-qsh-tls12-02, Internet Engineering Task Force. 2016; Expired Draft. [Google Scholar]
- Crockett, E.; Paquin, C.; Stebila, D. Prototyping Post-Quantum and Hybrid Key Exchange and Authentication in TLS and SSH. In Proceedings of the NIST 2nd Post-Quantum Cryptography Standardization Conference, Santa Barbara, CA, USA, 22–24 August 2019; Available online: https://csrc.nist.gov/CSRC/media/Events/Second-PQC-Standardization-Conference/documents/accepted-papers/stebila-prototyping-post-quantum.pdf (accessed on 10 August 2022).
- Sikeridis, D.; Kampanakis, P.; Devetsikiotis, M. Post-Quantum Authentication in TLS 1.3: A Performance Study. In Proceedings of the 27th Annual Network and Distributed System Security Symposium, NDSS 2020, San Diego, CA, USA, 23–26 February 2020. [Google Scholar] [CrossRef]
- Schwabe, P.; Stebila, D.; Wiggers, T. More Efficient Post-quantum KEMTLS with Pre-distributed Public Keys. In Proceedings of the Computer Security—ESORICS 2021—26th European Symposium on Research in Computer Security, Darmstadt, Germany, 4–8 October 2021; Proceedings, Part I; Lecture Notes in Computer Science. Springer: Cham, Switzerland, 2021; Volume 12972, pp. 3–22. [Google Scholar] [CrossRef]
- Schwabe, P.; Stebila, D.; Wiggers, T. Post-Quantum TLS Without Handshake Signatures. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security; Association for Computing Machinery: New York, NY, USA, 2020; pp. 1461–1480. [Google Scholar] [CrossRef]
- Kampanakis, P.; Stebila, D.; Friedl, M.; Hansen, T.; Sikeridis, D. Post-quantum public key algorithms for the Secure Shell (SSH) protocol. Internet-Draft draft-kampanakis-curdle-pq-ssh-00, Internet Engineering Task Force, 2020. Expired Draft.
- Hülsing, A.; Ning, K.C.; Schwabe, P.; Weber, F.; Zimmermann, P.R. Post-quantum WireGuard. In Proceedings of the 2021 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 24–27 May 2021; pp. 304–321. [Google Scholar] [CrossRef]
- Raynal, M.; Genet, A.; Romailler, Y. PQ-WireGuard: We Did It Again. In Proceedings of the NIST Third PQC Standardization Conference, Online, 7–9 June 2021; Available online: https://csrc.nist.gov/CSRC/media/Events/third-pqc-standardization-conference/documents/accepted-papers/raynal-pq-wireguard-pqc2021.pdf (accessed on 10 August 2022).
- Kniep, Q.M.; Müller, W.; Redlich, J.P. Post-Quantum Cryptography in WireGuard VPN. In Proceedings of the Security and Privacy in Communication Networks, Washington, DC, USA, 21–23 October 2020; Springer International Publishing: Cham, Switzerland, 2020; pp. 261–267. [Google Scholar] [CrossRef]
- Kampanakis, P.; Panburana, P.; Curcio, M.; Shroff, C. Post-Quantum Hash-Based Signatures for Secure Boot. Cryptology ePrint Archive, Report 2020/1584. 2020. Available online: https://ia.cr/2020/1584 (accessed on 10 August 2022).
- Kampanakis, P.; Panburana, P.; Curcio, M.; Shroff, C.; Alam, M.M. Post-Quantum LMS and SPHINCS+ Hash-Based Signatures for UEFI Secure Boot. Cryptology ePrint Archive, Report 2021/041. 2021. Available online: https://ia.cr/2021/041 (accessed on 10 August 2022).
- Bindel, N.; Herath, U.; McKague, M.; Stebila, D. Transitioning to a Quantum-Resistant Public Key Infrastructure. In Proceedings of the Post-Quantum Cryptography, Utrecht, The Netherlands, 26–28 June 2017; Springer International Publishing: Cham, Switzerland, 2017; pp. 384–405. [Google Scholar] [CrossRef]
- Bindel, N.; Brendel, J.; Fischlin, M.; Goncalves, B.; Stebila, D. Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange. In Proceedings of the Post-Quantum Cryptography, Chongqing, China, 8–10 May 2019; Springer International Publishing: Cham, Switzerland, 2019; pp. 206–226. [Google Scholar] [CrossRef]
- NIST. Post-Quantum Cryptography FAQs. Available online: https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs (accessed on 10 August 2022).
- NIST. NIST IR 8413—Status Report on the Third Round of the NIST Post-Quantum Cryptography Standardization Process. 2022. Available online: https://nvlpubs.nist.gov/nistpubs/ir/2022/NIST.IR.8413.pdf (accessed on 10 August 2022).
- Fernández-Caramés, T.M. From Pre-Quantum to Post-Quantum IoT Security: A Survey on Quantum-Resistant Cryptosystems for the Internet of Things. IEEE Internet Things J.
**2020**, 7, 6457–6480. [Google Scholar] [CrossRef] - Chung, C.C.; Pai, C.C.; Ching, F.S.; Wang, C.; Chen, L.J. When Post-Quantum Cryptography Meets the Internet of Things: An Empirical Study. In Proceedings of the MobiSys 2022—Proceedings of the 2022 20th Annual International Conference on Mobile Systems, Applications and Services, Portland, OR, USA, 27 June–1 July 2022. [Google Scholar] [CrossRef]
- Bürstinghaus-Steinbach, K.; Krauß, C.; Niederhagen, R.; Schneider, M. Post-Quantum TLS on Embedded Systems: Integrating and Evaluating Kyber and SPHINCS+ with mbed TLS. In Proceedings of the ASIA CCS’20: Proceedings of the 15th ACM Asia Conference on Computer and Communications Security, Taipei, Taiwan, 5–9 October 2020. [Google Scholar] [CrossRef]
- Marzougui, S.; Krämer, J. Post-Quantum Cryptography in Embedded Systems. In Proceedings of the ARES’19: Proceedings of the 14th International Conference on Availability, Reliability and Security, Canterbury CA, UK, 26–29 August 2019. [Google Scholar] [CrossRef]
- Asif, R. Post-Quantum Cryptosystems for Internet-of-Things: A Survey on Lattice-Based Algorithms. IoT
**2021**, 2, 71–91. [Google Scholar] [CrossRef] - Khalid, A.; McCarthy, S.; Liu, W.; O’Neill, M. Lattice-Based Cryptography for IoT in A Quantum World: Are We Ready? Cryptology ePrint Archive, Paper 2019/681. 2019. Available online: https://eprint.iacr.org/2019/681 (accessed on 10 August 2022).
- Chaudhary, R.; Aujla, G.S.; Kumar, N.; Zeadally, S. Lattice-Based Public Key Cryptosystem for Internet of Things Environment: Challenges and Solutions. IEEE Internet Things J.
**2019**, 6, 4897–4909. [Google Scholar] [CrossRef] - TCG. TCG DICE Layering Architecture. 2020. Available online: https://trustedcomputinggroup.org/resource/dice-layering-architecture/ (accessed on 10 August 2022).
- DMTF. DSP0277—Secured Messages Using SPDM Specification. 2020. Available online: https://www.dmtf.org/dsp/DSP0277 (accessed on 10 August 2022).
- DMTF. DSP0275—Security Protocol and Data Model (SPDM) over MCTP Binding Specification. 2019. Available online: https://www.dmtf.org/dsp/DSP0275 (accessed on 10 August 2022).
- DMTF. DSP0276—Secured Messages Using SPDM over MCTP Binding Specification. 2020. Available online: https://www.dmtf.org/dsp/DSP0276 (accessed on 10 August 2022).
- DMTF. DSP0237—Management Component Transport Protocol (MCTP) SMBus/I2C Transport Binding Specification. 2020. Available online: https://www.dmtf.org/dsp/DSP0237 (accessed on 10 August 2022).
- Beullens, W. Breaking Rainbow Takes a Weekend on a Laptop. In Proceedings of the Proceedings CRYPTO 2022, Santa Barbara, CA, USA, 13–18 August 2022; pp. 464–479. Available online: https://ia.cr/2022/214 (accessed on 10 August 2022). [CrossRef]
- Castryck, W.; Decru, T. An Efficient Key Recovery Attack on SIDH. Cryptology ePrint Archive, Report 2022/975. 2022. Available online: https://eprint.iacr.org/2022/975 (accessed on 10 August 2022).
- Fujioka, A.; Suzuki, K.; Xagawa, K.; Yoneyama, K. Strongly Secure Authenticated Key Exchange from Factoring, Codes, and Lattices. In Proceedings of the PKC’12: Proceedings of the 15th international conference on Practice and Theory in Public Key Cryptography, Darmstadt, Germany, 21–23 May 2012; Springer International Publishing: Cham, Switzerland, 2012; pp. 467–484. [Google Scholar] [CrossRef]
- Barnes, R.; Bhargavan, K.; Lipp, B.; Wood, C.A. Hybrid Public Key Encryption. In RFC 9180. 2022. Available online: https://doi.org/10.17487/RFC9180 (accessed on 10 August 2022).
- Giacon, F.; Heuer, F.; Poettering, B. KEM Combiners; Springer International Publishing: Cham, Switzerland, 2018; pp. 190–218. [Google Scholar] [CrossRef]
- DMTF. libspdm—A Sample Implementation following DMTF SPDM Specification. 2022. Available online: https://github.com/DMTF/libspdm (accessed on 10 August 2022).
- Open Quantum Safe Project. Liboqs. Available online: https://github.com/open-quantum-safe/liboqs (accessed on 10 August 2022).
- Yao, J. Post-Quantum Cryptography Version of Openspdm. 2022. Available online: https://github.com/jyao1/openspdm-pqc (accessed on 10 August 2022).

Algorithm | Requester’s List | Responder’s Selection |
---|---|---|

Hash | SHA256,SHA384 | SHA384 |

Responder Digital Signature | RSASSA_3072,ECDSA_NIST_P256,ECDSA_NIST_P384 | ECDSA_NIST_P384 |

Requester Digital Signature | RSASSA_3072,RSAPSS_3072 | RSAPSS_3072 |

Key Exchange | FFDHE_3072,ECDHE_secp256r1,ECDHE_secp384r1 | ECDHE_secp384r1 |

AEAD | AES_256_GCM,CHACHA20_POLY1305 | AES_256_GCM |

Algorithm | Requester’s List (Full Capability) | Responder’s Selection (Trad. Mode) | Responder’s Selection (PQC Mode) | Responder’s Selection (Hybrid Mode) |
---|---|---|---|---|

Hash | SHA256,SHA384 | SHA384 | SHA384 | SHA384 |

Responder Digital Signature | RSASSA_3072,ECDSA_NIST_P256,ECDSA_NIST_P384 | ECDSA_NIST_P384 | - | ECDSA_NIST_P384 |

Requester Digital Signature | RSASSA_3072,RSAPSS_3072 | RSAPSS_3072 | - | RSAPSS_3072 |

Key Exchange | FFDHE_3072,ECDHE_secp256r1,ECDHE_secp384r1 | ECDHE_secp384r1 | - | ECDHE_secp384r1 |

AEAD | AES_256_GCM | AES_256_GCM | AES_256_GCM | AES_256_GCM |

PQC Responder Digital Signature | Falcon-512,Falcon-1024 | - | Falcon-512 | Falcon-512 |

PQC Requester Digital Signature | Dilithium2,Dilithium5 | - | Dilithium2 | Dilithium2 |

PQC Key Exchange | Kyber512,SIDH-p434,SIKE-p434 | - | SIDH-p434 | SIDH-p434 |

SPDM Message | Changes for PQ-SPDM | Compatible? |
---|---|---|

GET_CAPABILITIES, CAPABILITIES | 1. Add extra capabilities (PQC, Hybrid mode) 2. May add extra field PQCTExponent as the timing required for PQC processing | YES |

NEGOTIATE_ALGORITHMS, ALGORITHMS | 1. Add PQC algorithms bits (PQC signature, PQC Key establishment) | YES |

GET_CERTIFICATE, CERTIFICATE | 1. May add certificate type (PQC, Hybrid). 2. May enlarge PortionLength/RemainderLength and Offset/Length field from 2 bytes to 4 bytes or retire the CERTIFICATE specific chunking. | NO |

CHALLENGE, CHALLENGE_AUTH | 1. Add PQC or Hybrid digital signature. | YES |

GET_MEASUREMENTS, MEASUREMENTS | 1. Add PQC or Hybrid digital signature. | YES |

KEY_EXCHANGE, KEY_EXCHANGE_RSP | 1. Add PQC or Hybrid key exchange. 2. Add PQC or Hybrid digital signature. | YES |

FINISH, FINISH_RSP | 1. Add PQC or Hybrid digital signature, in mutual authentication. | YES |

GET_CSR, CSR | 1. Add PQC or Hybrid digital signature. | YES |

SET_CERTIFICATE, CERTIFICATE | 1. May add certificate type (PQC, Hybrid). | YES |

Secured Message Using SPDM | 1. May enlarge ApplicationDataLength and Length field from 2 bytes to 4 bytes | NO |

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |

© 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Yao, J.; Matusiewicz, K.; Zimmer, V.
Post Quantum Design in SPDM for Device Authentication and Key Establishment. *Cryptography* **2022**, *6*, 48.
https://doi.org/10.3390/cryptography6040048

**AMA Style**

Yao J, Matusiewicz K, Zimmer V.
Post Quantum Design in SPDM for Device Authentication and Key Establishment. *Cryptography*. 2022; 6(4):48.
https://doi.org/10.3390/cryptography6040048

**Chicago/Turabian Style**

Yao, Jiewen, Krystian Matusiewicz, and Vincent Zimmer.
2022. "Post Quantum Design in SPDM for Device Authentication and Key Establishment" *Cryptography* 6, no. 4: 48.
https://doi.org/10.3390/cryptography6040048