SPDM은 장치 간 증명 프로토콜입니다
DMTF SPDM 1.4의 요청자(Requester)는 응답자(Responder)와 버전·기능·알고리즘을 협상합니다. 이어 인증서 체인과 CHALLENGE 응답으로 응답자 신원을 검증하고, GET_MEASUREMENTS로 장치 상태 측정값을 받을 수 있습니다. 장치가 이 기능을 모두 지원한다는 뜻은 아니며 실제 기능 비트와 협상 결과를 확인해야 합니다.
측정값의 서명 검증은 그 값이 해당 응답에서 왔는지 확인하는 단계입니다. 기대하는 펌웨어·설정값과 일치하는지의 판정은 요청자의 기준값과 정책을 필요로 합니다. 따라서 측정 메시지를 받았다고 해서 장치가 안전하거나 최신 상태라고 결론 내리지 않습니다.
이 글은 DSP0274 1.4.0과 DSP0277 1.3.0을 기준으로 읽습니다. 두 규격의 버전 번호가 같아야 한다는 뜻이나 최신판이라는 뜻은 아닙니다.
인증서 체인은 한 경로입니다. DSP0274 §7.2.2는 신뢰할 수 있는 환경에서 미리 제공한 공개 키(raw public key)도 허용합니다. 인증서 교환이 모든 구성의 필수 단계는 아닙니다.
인증, 보호된 세션, 인가 정책은 다른 단계입니다
SPDM의 KEY_EXCHANGE는 응답자 인증(선택적으로 상호 인증)과 공유 키 재료 수립을 위한 핸드셰이크를 시작합니다. 세션 안의 응용 데이터 암호화·인증 형식은 별도 DMTF DSP0277 Secured Messages 규격이 정의합니다. 버전·알고리즘·전송 바인딩을 모두 맞춰야 실제 상호 운용을 판단할 수 있습니다.
인증을 마쳤다고 보호된 관리 명령의 사용 권한이 자동으로 생기지는 않습니다. DMTF는 2025년 DSP0289 Authorization Specification을 별도로 발표했습니다. 따라서 “SPDM 지원”이라는 제품 문구만으로 인가 정책 구현까지 단정하지 말고 해당 규격·제품 구성·권한 설정을 따로 확인해야 합니다.
KEY_EXCHANGE 경로의 핸드셰이크는 FINISH와 FINISH_RSP를 성공적으로 교환해야 끝납니다(§10.17–10.18). 사전 공유 키를 쓰는 PSK_EXCHANGE 경로(§10.19)는 별도 선택지이며, PSK 제공 방식 자체는 이 규격의 범위 밖입니다.
보호된 세션이 항상 데이터를 숨기는 것은 아닙니다. DSP0277 1.3.0 §5.2.2.1은 응용 데이터를 암호화하지 않고 메시지만 인증하는 구성을, §5.2.2.2는 암호화와 인증을 함께 하는 구성을 정의합니다. 기밀성이 필요하면 실제 협상된 암호화 기능까지 확인합니다.
-
신원과 측정
신뢰 앵커와 측정 기준값
-
전송 보호
암호화 지원 여부와 세션 완료
-
명령 권한
로컬 정책과 제품별 허용 범위
TPM은 SPDM 프로토콜과 같은 물건이 아닙니다
TCG TPM 2.0 Library는 암호 키, 명령, 권한과 플랫폼 측정에 쓰이는 보안 모듈의 동작을 규정합니다. SPDM은 요청자와 응답자가 신원·측정·세션 정보를 교환하는 프로토콜입니다. 한 시스템이 TPM을 신뢰 근거로 활용할 수는 있지만 TPM이 있다고 SPDM 엔드포인트가 자동으로 구현되거나, SPDM을 쓴다고 TPM이 필수인 것은 아닙니다.
Lattice의 TPM·SPDM 소개 페이지는 설계 아이디어를 제공하지만 특정 FPGA 보드의 키 저장 방식, 서명 검증 회로, 표준 버전 또는 인가 정책이 구현되었다는 증거는 아닙니다. 실제 제품을 평가할 때는 해당 보드의 기술 가이드와 검증 가능한 펌웨어 구성으로 내려가 확인합니다.
FPGA 설계 검수에서 묻는 질문
요청자와 응답자의 위치, 지원 SPDM 버전과 기능 비트, 인증서 신뢰 앵커, 측정 대상 및 기준값, KEY_EXCHANGE와 Secured Messages의 지원 여부를 먼저 확인합니다. 접근 제어가 필요하면 DSP0289 구현 여부와 로컬 정책을 별도로 적습니다.
부팅 이미지 CRC나 Golden 복구는 손상 감지·가용성 경로입니다. 서명 기반 출처 인증과 장치 원격 증명은 다른 검증 단계입니다. 이 글은 표준의 역할 경계만 정리하며 Lattice Sentry v5의 개별 보안 인증이나 성능을 검증했다고 주장하지 않습니다.