SPDM과 CMA 인증 흐름 — 디바이스 신원과 펌웨어 측정 검증

#한 줄 요약

“IDE가 링크를 암호화하기 전에 양쪽이 서로 누구인지 확인해야 합니다.” — SPDM은 디바이스 인증·키 교환·세션 협상을 담당하는 DMTF 표준입니다. CMA는 PCIe·CXL 디바이스가 SPDM으로 인증받고 측정값을 내놓는 방식입니다. 둘이 합쳐 Confidential Computing의 신뢰 사슬 끝단을 만듭니다.

Ch 11에서 IDE가 링크를 AES-GCM으로 암호화하는 걸 봤습니다. 그런데 키를 어떻게 안전하게 교환하는지, 상대편이 진짜인지 어떻게 확인하는지는 IDE 밖의 문제입니다. 그게 SPDM·CMA의 역할입니다.

#왜 인증이 필요한가

IDE만으로는 부족한 이유:

1. 공격자가 디바이스 자체를 교체했다면 — 교체된 디바이스와 IDE 키 교환·암호화가 정상 진행됩니다. 데이터가 암호화되어 새지는 않지만 공격자에게 전달됩니다.
2. Firmware downgrade — 디바이스에 알려진 취약점이 있는 옛 firmware가 설치되어 있어도, IDE는 그걸 막지 못합니다.
3. Counterfeit 디바이스 — 정품처럼 가장한 디바이스가 동작은 비슷해도 backdoor 포함일 수 있습니다.

SPDM은 이 시나리오를 판단할 재료를 줍니다. 디바이스의 인증서 chain과 서명된 firmware 측정값입니다. 그 값으로 어떤 디바이스를 받아들일지는 호스트 정책이 정하고, SPDM spec은 정책을 정하지 않습니다(DSP0274 Scope).

#SPDM이란

*SPDM (Security Protocol and Data Model)*은 DMTF DSP0274가 정의한 디바이스 인증 표준 프로토콜입니다.

SPDM 자체는 전송 무관입니다. 어느 채널로 보낼지는 별도 결정. PCIe·CXL은 보통 DOE (Data Object Exchange) 채널을 통합니다.

#SPDM 메시지 시퀀스

표준 디바이스 인증·키 교환 흐름:

이 시퀀스가 끝나면 호스트는 디바이스의 신원을 확인했고, 둘은 secure session을 갖습니다. CXL에서는 이 session이 IDE 키를 설정하는 CXL_IDE_KM 메시지를 보호합니다(CXL 3.1 §11.4). session 키가 곧 IDE 키는 아닙니다.

#DOE 채널 — SPDM 전송

PCIe·CXL에서 SPDM 메시지는 *DOE (Data Object Exchange)*로 전송됩니다.

1
# DOE capability 레지스터 (pciutils는 DOECap·DOECtl·DOESta만 출력)
2
$ lspci -vvv -s 5e:00.0 | grep -A 4 "Data Object Exchange"
3

4
# 디바이스가 지원하는 DOE feature (Vendor ID:type)
5
$ ls /sys/bus/pci/devices/0000:5e:00.0/doe_features/
6
0001:01  0001:02  doe_discovery

DOE feature는 Vendor ID:data object type으로 식별합니다. Vendor 0001h(PCI-SIG) 아래 type 0이 Discovery, 1이 CMA-SPDM, 2가 Secured CMA-SPDM입니다(Linux include/linux/pci-doe.h, Documentation/ABI/testing/sysfs-bus-pci). lspci는 이 목록을 출력하지 않습니다.

DOE는 config space에 mailbox를 두고, 호스트가 명령 write → 디바이스 응답 read 하는 단순 인터페이스입니다.

#CMA — Component Measurement and Authentication

*CMA (Component Measurement and Authentication)*는 PCIe·CXL 디바이스가 DOE 위에서 SPDM으로 인증과 측정값 보고를 하는 방식입니다. CXL 3.1 spec은 compliance 항목 §14.11.1을 이 이름으로 두고, Linux는 CMA-SPDM이라 부릅니다.

측정값은 SPDM GET_MEASUREMENTS로 받습니다(DSP0274).

index에 무엇을 둘지는 디바이스가 정하고, 각 block은 DMTFSpecMeasurementValueType으로 종류를 밝힙니다.

Param1 bit 0을 켜서 요청하면 요청에 nonce가 붙고, 디바이스는 응답에 서명합니다.

#DICE — Device Identifier Composition Engine

DICE는 TCG가 정의한 방식으로, *하드웨어 수준의 디바이스 고유 비밀(UDS)*과 다음 단계 software의 측정값을 섞어 *CDI(Compound Device Identifier)*를 만듭니다. 아래 식은 Open Profile for DICE(Google open-dice)의 구성입니다.

핵심 성질: 측정된 software가 변하면 CDI가 변합니다. mutable software는 UDS에 접근하지 못하고 자기 단계의 CDI만 받습니다.

#공격 시나리오와 SPDM의 방어

SPDM 자체가 MITM·spoofing·replay를 막아 IDE 키 교환이 진짜 정품 디바이스와 이루어지게 보장합니다.

#자주 하는 실수

#“SPDM만 활성화하면 보안 끝”

디바이스 한 번 인증된 뒤 트래픽 자체는 *별도 보호 메커니즘 (IDE)*이 필요합니다. SPDM은 세션 시작 전 한 번, IDE는 세션 내내. 둘이 상호 보완이지 대체 관계가 아닙니다.

#“MEASUREMENT의 hash를 어떤 값과 비교할지 SPDM이 정해 준다”

아닙니다. SPDM은 측정값을 서명해 전달할 뿐이고, 어느 값을 받아들일지는 정책의 몫이며 spec 범위 밖입니다(DSP0274). 기준값은 따로 확보해야 합니다.

#정리

• SPDM은 DMTF DSP0274 표준으로 디바이스 인증·측정·secure session을 담당합니다.
• PCIe·CXL에서는 DOE (Data Object Exchange) 채널로 SPDM 메시지가 흐릅니다. DOE feature 0001
  CMA-SPDM입니다.
• CMA(Component Measurement and Authentication)는 DOE 위의 SPDM 인증·측정 방식입니다.
• DICE는 UDS와 측정값으로 CDI를 derive해 software 변경 시 신원도 변경되게 합니다.
• SPDM + IDE 조합이 Confidential Computing의 신원 검증 + 트래픽 보호 두 축을 완성합니다.

다음 편은 Ch 13: CXL TEE 확장 — SPDM 위에서 디바이스가 인증되면 그 디바이스를 TVM (Trusted Virtual Machine)에 안전하게 attach하는 PCI-SIG TDISP, CXL TSP, Linux PCI TSM 프레임워크를 분해합니다.

#관련 항목

• Ch 11: PCIe·CXL IDE 분석 — 링크 무결성과 데이터 암호화
• Ch 13: CXL TEE 확장 (다음 편)
• Ch 2: Secure Boot 분석 — DICE와 같은 chain of trust
• Ch 5: TEE 비교 분석 — OP-TEE·ARM CCA·SGX
• 원문 — DMTF DSP0274 (SPDM)