PCIe·CXL IDE 분석 — 링크 무결성과 데이터 암호화

#한 줄 요약

“IDE는 PCIe 링크 자체를 암호화된 통로로 만듭니다.” — TrustZone이 CPU 안을 보호하고 TEE가 Secure World 안을 보호한다면, IDE는 디바이스 사이의 케이블을 보호합니다. AES-GCM 256-bit으로 TLP·CXL.mem flit을 암호화·인증해 물리 접근 공격자가 링크를 sniffing·tampering해도 데이터가 새지 않게 합니다.

#왜 링크 암호화가 필요한가

Ch 4 (TrustZone)에서 CPU 안 Secure World를 격리했고, Ch 5 (TEE)에서 TA가 안전한 환경에서 동작하는 걸 봤습니다. 그러나 CPU 밖으로 나가는 순간은 다른 문제입니다.

PCIe 카드 한 장을 분리해서 별도 보드에 장착하면 TLP를 그대로 볼 수 있습니다. 데이터센터에서 물리 접근 가능한 운영자가 interposer·protocol analyzer를 끼우면 링크를 흐르는 모든 트래픽을 읽을 수 있고, 심지어 수정도 가능합니다.

이 위협이 클라우드 신뢰 모델의 마지막 약점입니다. Confidential Computing에서 CPU에서 GPU로 가속기 작업을 넘길 때, 또는 CXL.mem expander에 KV cache가 저장될 때, 그 경로 자체가 암호화되지 않으면 모든 CPU/TEE 안의 보안은 디바이스 밖에서 무력화됩니다.

PCIe·CXL IDE(Integrity and Data Encryption)는 이 링크 구간을 암호화 통로로 만드는 표준입니다.

#위협 모델

IDE가 푸는 세 가지 공격:

IDE는 MITM 자체를 막지는 않습니다. 공격자가 링크 중간에 끼는 것은 가능하지만, 암호화·인증된 데이터를 의미 있게 조작하지는 못합니다.

링크 끝점 자체(host CPU, 디바이스 controller)의 키 보호는 IDE의 책임 밖입니다. 그건 TEE·HSM의 영역입니다.

#IDE의 두 모드 — Selective vs Link

PCIe Base Spec 6.0 IDE는 두 가지 모드를 정의합니다.

CXL 환경에서는 Link IDE가 기본입니다. CXL.mem flit·CXL.cache flit·CXL.io TLP 모두 한 키로 암호화되어 링크 전체가 암호화 영역이 됩니다.

Selective IDE는 기존 비암호화 트래픽과 혼재가 가능해 *제어 평면(config·enumeration)*은 평문으로, 데이터 평면만 암호화하는 시나리오에 적합합니다.

#암호화 알고리즘 — AES-GCM 256

IDE는 AES-GCM 256을 단일 표준으로 사용합니다.

GCM 모드 선택 이유:

• Parallel 처리 가능 — flit 단위 순차 의존성 없음. high-throughput PCIe·CXL에 적합
• Authenticated Encryption — 암호화와 무결성을 한 번에. 두 알고리즘 따로 돌릴 필요 없음
• Hardware acceleration — Intel AES-NI, ARM Cryptography Extensions 등 전용 명령어 지원

#키 관리 — IDE_KM (Key Management)

IDE 자체는 데이터 흐름의 암호화만 정의합니다. 키를 어떻게 만들고·교환하고·교체할지는 별도 프로토콜 IDE_KM이 담당합니다.

IDE 키 라이프사이클 — 5단계:

키 교환은 SPDM 위에 IDE_KM 메시지를 얹는 구조입니다. 자세한 SPDM 흐름은 Ch 12에서 봅니다.

주기적 키 refresh가 중요한 이유는 96-bit counter overflow가 물리적으로 가능하기 때문입니다. CXL 3.0 fabric의 128 GB/s 링크는 약 6분에 sequence space 12.5% 소모. 보통 분 단위로 key refresh가 권장됩니다.

#성능 영향

IDE 활성화 시 지연·대역폭에 비용이 발생합니다.

+17 ns 지연은 AES-GCM 인코딩·디코딩 + GMAC 검증에서 옵니다. 하드웨어 가속이면 flit 1개당 ~5 ns이고, 왕복으로 +10~17 ns가 자연스러운 범위입니다.

5% throughput 손실은 flit 헤더에 IDE metadata가 추가되어서입니다. MAC 96-bit + counter 일부가 flit payload를 줄입니다.

Ch 54 (Perf Eng)에서 봤듯 CXL.mem의 워크로드별 지연 budget이 200 ns vs 400 ns 차이가 크지 않다면, IDE의 +17 ns는 운영 가능한 범위입니다.

#현세대 디바이스 지원

Confidential Computing을 full stack으로 지원하려면 모든 링크에 IDE가 켜져야 합니다. CPU↔GPU·CPU↔CXL·GPU↔NVLink 등 어느 하나라도 빠지면 전체 보안이 깨집니다.

#운영 — 활성화 확인

Linux 환경에서 IDE 상태 확인:

1
# PCIe IDE capability
2
$ lspci -vvv -s 5e:00.0 | grep -A 20 "Integrity and Data Encryption"
3
Integrity and Data Encryption:
4
    Selective IDE Streams: 4
5
    Link IDE Streams:      1
6
    Aggregation supported: Yes
7
    PCRC supported:        Yes
8

9
# CXL IDE 상태
10
$ cxl list -i -m mem0
11
[
12
  {
13
    "memdev":"mem0",
14
    "ide": {
15
      "link_ide_active": true,
16
      "selective_ide_streams": 0,
17
      "key_refresh_interval_ms": 60000
18
    }
19
  }
20
]
21

22
# IDE 이벤트 추적
23
$ bpftrace -e 'tracepoint:cxl:ide_key_refresh { @[kstack] = count(); }'

IDE는 enable만으로 의미가 없습니다. 정기적인 key refresh가 동작하는지, failover 시 graceful한지가 운영의 핵심입니다.

#자주 하는 실수

#”IDE만 켜면 데이터센터가 안전하다”

IDE는 링크만 보호합니다. 디바이스 안의 메모리·캐시·레지스터는 별도 보호 메커니즘이 필요합니다. CXL 메모리 디바이스에 저장된 plain DRAM 내용은 physical attack에 그대로 노출됩니다 — 그건 Ch 13의 CXL TEE 영역입니다.

#”AES-GCM이면 성능 영향 없다”

하드웨어 가속이 있을 때만입니다. 소프트웨어 fallback은 3~5배 느립니다. CPU AES-NI 또는 디바이스 controller에 전용 가속기가 반드시 있어야 합니다.

#”한 번 키 교환하면 끝”

아닙니다. Counter overflow 전에 refresh 필수입니다. 고대역폭 CXL fabric에서는 분 단위 refresh가 정상입니다. 그렇지 않으면 nonce 재사용으로 암호화 약화가 발생합니다.

#”IDE는 PCIe 6.0 전용이다”

아닙니다. PCIe 5.0과 CXL 2.0부터 IDE를 지원합니다. PCIe 6.0은 Optional Aggregation과 향상된 throughput을 추가했을 뿐입니다.

#한국 메모리 산업의 위치

Ch 9 (HBM·GDDR 심화)에서 봤듯 Samsung CMM-D·SK Hynix Niagara가 CXL 메모리 디바이스 시장의 선두권입니다. CXL 2.0 IDE는 2024~2025년 양산 디바이스의 revision에서 qualification 항목에 들어가는 흐름입니다.

CXL 메모리 디바이스의 controller die 내부 AES-GCM 가속기 통합은 firmware로 IDE 활성화·키 관리를 가능하게 합니다. Astera Labs Leo는 fabless 모델로 한국 DRAM 제품과 자체 ASIC controller를 묶어 IDE 가속기를 chip 안에 통합하는 구조입니다. Samsung·SK Hynix는 vertical integration(DRAM + controller 한 회사) 이점을 활용합니다.

표준 기여 측면에서도 Samsung·SK Hynix가 CXL Consortium IDE Working Group에 코어 멤버로 참여합니다. *2024~2026년 ECN(Engineering Change Notice)*의 IDE 관련 항목에 한국 두 회사의 영향이 큽니다.

#정리

• IDE는 PCIe·CXL 링크 자체를 AES-GCM 256으로 암호화·인증하는 표준입니다.
• Selective IDE는 특정 stream만, Link IDE는 전체 트래픽을 보호합니다. CXL은 보통 Link IDE 기본.
• 위협은 eavesdropping·tampering·replay 세 가지. MITM 자체는 못 막지만 의미 있는 조작은 차단합니다.
• AES-GCM 256은 parallel·authenticated·hardware-accelerated라 high-throughput에 적합합니다.
• 키는 SPDM 위 IDE_KM 프로토콜로 교환·refresh되며, counter overflow 전 정기 refresh가 필수입니다.
• 성능 비용은 -5% throughput, +17 ns 지연. 대부분 워크로드에서 수용 가능한 범위입니다.
• Full Confidential Computing을 위해서는 CPU↔GPU·CPU↔CXL 모든 링크에 IDE 활성화가 필요합니다.
• 한국 메모리 두 회사가 CXL Consortium IDE WG 코어 멤버로 2025+ 양산 디바이스에 표준 적용합니다.

다음 편은 Ch 12: SPDM과 CMA 인증 흐름 — IDE 키 교환을 떠받치는 SPDM 프로토콜과 *CMA(Component Measurement Attestation)*의 디바이스 신원 검증·firmware 측정을 분해합니다.

#관련 항목

• Ch 4: ARM TrustZone 분석 — CPU 안 격리
• Ch 5: TEE 비교 분석 — Secure World 안의 격리
• Ch 12: SPDM과 CMA 인증 흐름 (다음 편)
• Ch 13: CXL TEE 확장 — Trusted Execution을 메모리 디바이스까지
• HBM·GDDR 심화 Ch 9: CXL.mem 분석
• Embedded Performance Engineering Ch 54: CXL.mem 지연·대역폭 실측 — IDE 성능 영향이 운영 가능한 범위인지의 근거