Security Protocol and Data Model (SPDM) Specification

1 1 Document Identifier:DSP02742 Date: 2020-07-153 Version: Protocol and data Model (SPDM)Specification7 Supersedes: Class: Normative10 Document Status: Work in Progress11 Document Language: en-USInformation for Work-in-Progress version:5 IMPORTANT:This document is not a standard. It does not necessarily reflect the views of the DMTFor its members. Because this document is a Work in Progress, this document may still change,perhaps profoundly and without notice. This document is available for public review and comment any comments through the DMTF Feedback Portal: is a not-for-profit association of industry members dedicated to promoting enterprise and systemsmanagement and interoperability. Members and non-members may reproduce DMTF specifications anddocuments, provided that correct attribution is given.

2 As DMTF specifications may be revised from time totime, the particular version and release date should always be of certain elements of this standard or proposed standard may be subject to third partypatent rights, including provisional patent rights (herein "patent rights"). DMTF makes no representationsto users of the standard as to the existence of such rights, and is not responsible to recognize, disclose,or identify any or all such third party patent right, owners or claimants, nor for any incomplete orinaccurate identification or disclosure of such rights, owners or claimants. DMTF shall have no liability toany party, in any manner or circumstance, under any legal theory whatsoever, for failure to recognize,disclose, or identify any such third party patent rights, or for such party's reliance on the standard orincorporation thereof in its product, protocols or testing procedures.

3 DMTF shall have no liability to anyparty implementing such standard, whether such implementation is foreseeable or not, nor to any patentowner or claimant, and shall have no liability or responsibility for costs or losses incurred if a standard iswithdrawn or modified after publication, and shall be indemnified and held harmless by any partyimplementing the standard from any and all claims of infringement by a patent owner for information about patents held by third-parties which have notified the DMTF that, in their opinion,such patent may relate to or impact implementations of DMTF standards, document's normative language is English. Translation into other languages is Notice12 Copyright 2020 DMTF. All rights Protocol and data Model (SPDM) SpecificationDSP02742 Work in ProgressVersion {-}.

4 {-}.. 62 Introduction {-}.. {-}.. conventions {-}.. and unassigned values {-}.. ordering {-}.. data types {-}.. encoding {-}.. {-}.. 83 Scope.. 104 Normative references.. 115 Terms and definitions.. 136 Symbols and abbreviated terms.. 177 SPDM message exchanges.. capability discovery and negotiation.. authentication.. provisioning.. authentication.. and configuration measurement.. sessions.. authentication overview.. 208 SPDM messaging Protocol .. bits-to-bytes mapping.. SPDM message format.. request codes.. response codes.. request and response code issuance allowance.. SPDM message processing.. for Requesters.. for Responders.. 299 Timing requirements.. measurements.. Specification table.. 3010 SPDM messages.. discovery and negotiation.. request and VERSION response messages.

5 Request and CAPABILITIES response messages.. request and ALGORITHMS response messages.. identity authentication.. identity authentication.. 56 DSP0274 Security Protocol and data Model (SPDM) SpecificationVersion in and certificate chains.. request and DIGESTS response messages.. request and CERTIFICATE response messages.. authentication requirements for GET_CERTIFICATE and CERTIFICATE messages.. certificate.. request and CHALLENGE_AUTH response messages.. signature generation.. signature verification.. ordering and message transcript computation rules for M1 and M2.. mutual authentication.. authentication message transcript.. and other measurements.. request and MEASUREMENTS response messages.. block.. Specification for the Measurement field of a measurement block.

6 Signature generation.. signature verification.. response message.. request message format.. request message.. response message.. request and KEY_EXCHANGE_RSP response messages.. authentication.. Requester certificate for mutual authentication.. request and FINISH_RSP response messages.. hash calculation rules.. request and PSK_EXCHANGE_RSP response messages.. request and PSK_FINISH_RSP response messages.. request and HEARTBEAT_ACK response messages.. additional information.. request and KEY_UPDATE_ACK response messages.. key update synchronization.. transport allowances.. request and ENCAPSULATED_REQUEST responsemessages.. request flow.. encapsulated request flow.. constraints.. request and ENCAPSULATED_RESPONSE_ACKresponse messages.. information.. 118 Security Protocol and data Model (SPDM) SpecificationDSP02744 Work in ProgressVersion request and END_SESSION_ACK response messages.

7 11811 Session.. handshake phase.. phase.. termination phase.. active sessions.. and session ID.. 12312 Key schedule.. hash in key derivation.. definition.. definition.. schedule major secrets.. handshake secret.. handshake secret.. data secret.. data secret.. key and IV derivation.. derivation.. additional keys from the Export Master Secret.. secrets update.. 13013 Application data .. derivation.. 13114 ANNEX A (informative) TLS {-}.. 13215 ANNEX B (normative) Leaf certificate example {-}.. 13316 ANNEX C (informative) Change log {-}.. 13517 Bibliography {-}.. 136 DSP0274 Security Protocol and data Model (SPDM) SpecificationVersion in Progress5181 Foreword {-}19 The Platform Management Components Intercommunication (PMCI) working group of theDMTF prepared theSecurity Protocol and data Model (SPDM) Specification (DSP0274).

8 DMTF is a not-for-profit association of industrymembers that promotes enterprise and systems management and interoperability. For information about the DMTF, {-}21 The DMTF acknowledges the following individuals for their contributions to this document:22 Contributors: Richelle Ahlvers Broadcom Inc. Lee Ballard Dell Technologies Patrick Caporale Lenovo Yu-Yuan Chen Intel Corporation Nigel Edwards Hewlett Packard Enterprise Daniil Egranov Arm Limited Philip Hawkes Qualcomm Inc. Brett Henning Broadcom Inc. Jeff Hilland Hewlett Packard Enterprise Yuval Itkin Mellanox Technologies Theo Koulouris Hewlett Packard Enterprise Luis Luciani Hewlett Packard Enterprise Masoud Manoo Lenovo Donald Matthews Advanced Micro Devices, Inc. Mahesh Natu Intel Corporation Edward Newman Hewlett Packard Enterprise Jim Panian Qualcomm Inc.

9 Scott Phuong Cisco Systems Inc. Jeffrey Plank Microchip ViswanathPonnuru Dell Technologies Xiaoyu Ruan Intel Corporation Nitin Sarangdhar Intel Corporation Hemal Shah Broadcom Inc. Srikanth Varadarajan Intel CorporationSecurity Protocol and data Model (SPDM) SpecificationDSP02746 Work in ProgressVersion {-}24 TheSecurity Protocol and data Model (SPDM) Specificationdefinesmessages, data objects, and sequences forperforming message exchanges betweendevicesover a variety of transport and physical media. The description ofmessage exchanges includesauthenticationof hardware identities, measurement for firmware identities and sessionkey exchange protocols to enable confidentiality and integrity protected data communication. The SPDM enablesefficient access to low-level Security capabilities and operations.

10 Other mechanisms, including non-PMCI- andDMTF-defined mechanisms, can use the {-}26 The following conventions apply to all SPDM conventions {-} Document titles appear initalics. The first occurrence of each important term appears initalicswith a link to its definition. ABNF rules appear in a monospaced and unassigned values {-}29 Unless otherwise specified, any reserved, unspecified, or unassigned values in enumerations or other numericranges are reserved for future definition by the otherwise specified, reserved numeric and bit fields shall be written as zero (0) and ignored when ordering {-}32 Unless otherwise specified, for all SPDM specificationsbyteordering of multi-byte numeric fields or multi-byte bitfields is "Little Endian"(that is, the lowest byte offset holds the least significant byte, and higher offsets hold the moresignificant bytes).