Integrity and Data

Encryption (IDE) ECN

Deep Dive
PCI-SIG® Educational Webinar Series
Meet the Presenter

David Harriman
PCI-SIG® Protocol Workgroup (PWG) Chair
Senior Principal Engineer, Intel

2
Disclaimer

• The information in this presentation refers to specifications still in the

development process. This presentation reflects the current thinking
of various PCI-SIG® workgroups, but all material is subject to
change before the specifications are released.

3
Outline

• Review Context of IDE & Relationship with CMA/DOE & SPDM

• IDE Use Models
• Device’s Responsibilities in Maintaining Security
• Next Level of Detail on IDE Draft ECN
• Conclusions and Call to Action

4
Key Computational Security Needs
• Protection of key assets
• Consumers: data integrity, confidentiality
• Businesses & suppliers: reputation, revenue-stream, intellectual property, business continuity
• Governments: national security, defense, elections, infrastructure
• Fully secured infrastructure “edge-to-core”
• Must protect against supply chain attacks, physical attacks, persistent attacks, malicious
components, etc
• Must secure entire component lifecycle (manufacturing, installation, initialization, operation,
addition & replacement)

5
PCI-SIG® & DMTF Specifications for Security

Security Protocol and Data Model – SPDM • SPDM defines a “toolkit” for
(DSP0274) authentication, measurement,
Component Measurement and Authentication (CMA) and other security capabilities
IDE key programming protocol • CMA defines how SPDM is
Integrity applied to PCIe devices/systems
SPDM over MCTP Binding and Data
(DSP0275) Encryption • DOE supports Data Object
Secured MCTP Messages over MCTP Binding
(IDE) transport between host CPUs &
(DSP0276) Data Object PCIe components over PCIe
Exchange (DOE)
MCTP over SMBus MCTP over PCIe • Various MCTP bindings support
Binding Binding Data Object transport over
(DSP0237) (DSP0238) different interconnects
• IDE will typically use this toolkit
Legend: DMTF PCISIG
for key exchange, but can use
other mechanisms for keys

6
PCI-SIG® and DMTF Specifications – Status

Security Protocol and Data Model – SPDM

• SPDM:
(DSP0274) https://www.dmtf.org/dsp/DSP0274
• Current release (1.0.0) covers
Component Measurement and Authentication (CMA) Authentication and Measurement
IDE key programming protocol • 1.1 pending
Integrity • 1.2 (in work queue) will be required for
SPDM over MCTP Binding and Data IDE key programming
(DSP0275) Encryption
(IDE) • CMA published Apr 2020:
Secured MCTP Messages over MCTP Binding https://members.pcisig.com/wg/PCI-
(DSP0276) Data Object
Exchange (DOE)
SIG/document/14236
MCTP over SMBus MCTP over PCIe • DOE published Mar 2020:
Binding Binding https://members.pcisig.com/wg/PCI-
(DSP0237) (DSP0238) SIG/document/14143
• IDE in Review
Legend: DMTF PCISIG
• Goal: Final Publication End of Q3

IDE D-ECN to Base 4.0/5.0 is in Review Zone – Member Review ends 7 Sept 2020
7
Overview: PCIe® Technology Integrity and Data
Encryption (IDE)
• Goals: Provide confidentiality, integrity, and replay
protection for PCIe Transaction Layer Packets (TLPs) Legend:
• Support wide variety of use models Link IDE Stream – Applies to all TLP
• Broad interoperability Root Complex traffic not in a Selective IDE Stream
and does not pass through Switches
• Aligned to industry best practices & extensible Root
Port
Root
Port Selective IDE Stream – Applies to
A C
TLPs selectively and can pass
• Security model - Physical attacks on Links, to read through Switches
confidential data, modify TLP contents, & reorder B
Port Port
D

and/or delete TLPs, via: E H

Endpoint
• lab equipment

Port

Port
Switch Endpoint

• purpose-built interposers
Port
• malicious Extension Devices F

• TLPs can be protected while transiting Switches G

Port
• Extends security model to address attacks via Switches
Endpoint
• Applies AES-GCM for encryption of TLP Data Payload
and authenticated integrity protection of entire TLP

8
IDE TLPs
Integrity Protected

Encrypted

Sequence
Number
Local
Prefix(es)
IDE TLP
Prefix
Other End-End
Prefix(es)
Header Data PCRC
ECRC
IDE TLP
MAC
LCRC Single IDE TLP

A – Additional Authenticated Data P - Plaintext

Integrity Protected Integrity Protected Two TLPs Aggregated

Encrypted Encrypted

Sequence Local IDE TLP Other End-End Sequence Local IDE TLP Other End-End IDE TLP
Number Prefix(es) Prefix Prefix(es)
Header Data PCRC
ECRC LCRC
Number Prefix(es) Prefix Prefix(es)
Header Data PCRC
ECRC
MAC
LCRC

A – Additional Authenticated Data P - Plaintext

Non-FLIT Mode TLPs shown –

• Examples show TLP format for Selective IDE
For Base 6.0 with FLIT Mode
• For Link IDE the Local Prefix(es) are also integrity protected the TLP format will be
• Aggregation can apply to up to 8 TLPs different

9
Streams & Sub-Streams
• Each IDE Stream includes Sub-Streams
distinguished by TLP type and direction No

• Posted Requests, Non-Posted Requests, & No No No

Completions No No No
• Sub-Streams allow the PCIe Producer/Consumer No No
model to be followed in a way that also works
well with AES-GCM TLP flow through PCIe fabric

• The TLPs in a Sub-Stream are processed in-order Source

Port
NP2 P2 NP1 P1 TLP Order from Requester

• Each Sub-Stream has a unique key and invocation

counter A permitted reordering:
NP2 NP1 P2 P1 Destination

• Within a Stream, Sub-Streams require P2 bypasses NP1

Port

modification of the Switch ordering rules for flow-

through Selective IDE (top right) TLP flow through PCIe fabric

• Between Streams and with non-IDE TLPs, the Source

Port
NP2 P2 NP1 P1 TLP Order from Requester
ordering rules are unchanged
• Examples of permitted and forbidden reordering NP2 P2 P1 NP1 Destination A forbidden reordering:
(right) Port NP1 bypasses P1

10
IDE Use Models – Link vs. Selective
• IDE establishes an IDE Stream between two Ports
• Can use Link IDE and/or Selective IDE between two Legend:

directly connected Ports (e.g. A & B, C & D) Link IDE Stream – Applies to all TLP
Root Complex traffic not in a Selective IDE Stream
• Desirable if, e.g., different security policies are Root Root
and does not pass through Switches

applied to the Selective IDE TLPs. A

Port Port
C
Selective IDE Stream – Applies to
TLPs selectively and can pass

• IDE does not establish security beyond the

through Switches
B D
boundary of the two terminal Ports Port Port
E H

• Selective IDE Streams between Ports C and G, and Endpoint

Port

Port
Switch Endpoint
between Ports G and H, are secured as they pass
through the Switch F
Port

• IDE provides security from Port to Port G

• Security must be provided implementation-specific Port

means within the Component past the terminal Port Endpoint

• With TLPs flowing “hop-by-hop” through one or more

Switches, it is necessary to ensure acceptable security
is maintained within the Switch(es)
11
System Construction
• In-line securing of TLPs –
a “data plane” capability Option:
Host-Based key Option:

• Stream establishment & management –

programming Management
Controller-Based
Root Complex key programming
a “control plane” capability Root Root System
Port Port Management
• IDE defines key programming from a central
A C Controller

trusted entity (e.g., Host Firmware/Software, B D

BMC) Port Port
E H
Endpoint
• Supports “Set & Forget” model as well as more

Port
Port
Switch Endpoint

active/dynamic approaches
Port
F

Legend:
G
Port
PCIe Link

Management Endpoint
IO bus/link

12
System Level Considerations

• “Verifier” Implementation is key, but outside scope of PCIe® Base specification

• Build on CMA/SPDM foundation
• System level policies expected to vary significantly
• Revisit industry spec requirements as experience base increases
• Securing centralized functions
• Centralized key programming – single point of failure must be secured!
• IDE stops at the Port – buffers/memory & processing resources must prevent leaks

13
Device’s Responsibilities in Maintaining Security

• Device requirements parallel those for the Host

• Keys must be secured!
• No paths around encryption eliminated/blocked
• Debug mechanisms must be carefully controlled

14
IDE Draft ECN – Few Remaining Opens

• Key programming protocol

• Coordinated with SPDM 1.2
• Optimizing the layering structure

• Seeking feedback on key size and related requirements

• See “NOTE TO REVIEWERS”

• Balance between spec / implementation flexibility in “control” plane, e.g.

• Mechanisms for “locking” configuration
• Details of set-up and tear-down

15
Conclusions and Call to Action

• Integrity and Data Encryption (IDE) – In Review

• Please review and provide feedback

• Consider IDE applies in your applications

• Engage with PCI-SIG®

• Consider Next Steps for the PCIe® Base Specification

16
Questions

17
Thank you for attending the PCI-SIG
Q3 2020 Webinar

For more information please go to

www.pcisig.com

18