Hardware Root of Trust & Secure Boot

1. Overview

하드웨어 신뢰 루트와 보안 부팅(Hardware Root of Trust & Secure Boot, HRT)은 시스템에 전기가 들어오는 첫 1밀리초의 순간부터 운영체제가 켜지기까지, 해커의 부트킷(Bootkit)이나 펌웨어 변조를 원천 봉쇄하는 '시간적(Temporal) 신뢰 사슬' 구축 공학입니다.

학습자는 공장에서 실리콘 칩 안에 녹여버린 절대 수정 불가능한 마스터키(Fused Key)와 코드를 기반으로 삼는 **하드웨어 신뢰 루트(Root of Trust, RoT)**의 절대적 물리 법칙을 뜯어봅니다. 나아가 이 RoT를 시작점으로 하여 "내가 부팅할 다음 단계의 코드(부트로더 $\rightarrow$ 커널 $\rightarrow$ OS)가 서명된 진짜인지" 매 단계마다 해시 검증을 때리며 신뢰를 전이(Chain of Trust)시키는 **보안 부팅(Secure Boot)**과 **측정된 부팅(Measured Boot)**의 암호학적 파이프라인을 해부하여, 펌웨어 감염으로 인한 좀비 PC(Rootkit) 붕괴를 하드웨어 단에서 막아내는 방어 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• 신뢰 루트 (Root of Trust): RoT for Measurement (RTM), RoT for Storage (RTS), RoT for Reporting (RTR), 실리콘 퓨즈(eFuse)와 불변성 ROM (Boot ROM).
• 보안 부팅 역학 (Secure Boot): UEFI Secure Boot, 서명 검증(Digital Signature Verification), PK/KEK/db/dbx 인증서 계층 구조.
• 측정된 부팅 체인 (Measured Boot & TPM): 하드웨어 신뢰 플랫폼 모듈(TPM), 플랫폼 구성 레지스터(PCR) 해시 연장(Extend).
• 펌웨어 물리 보안 (Firmware Physics): SPI 플래시 메모리 접근 제어, 하드웨어 타이머 기반 워치독(Watchdog).

Out-of-Scope

• 운영체제 런타임 방어: 부팅이 완전히 끝난 후 커널(Ring 0) 내부에서 유저 프로세스의 시스템 콜을 필터링하는 기법(Seccomp 등) $\rightarrow$ 10-01. OS & System Security 영역.
• 네트워크 인증서 인프라: 웹 브라우저가 SSL/TLS 통신을 위해 CA(Certificate Authority) 루트 인증서를 검증하는 PKI 시스템 $\rightarrow$ 10-03. Applied Cryptography 영역.

Boundaries

• HRT vs. TEE (02-04-02): TEE(02-04-02)가 "운영체제가 이미 켜져서 미쳐 날뛰는 런타임(Runtime) 환경 중에 데이터를 어떻게 격리할 것인가?"를 다루는 '공간 방어'라면, HRT는 "애초에 미쳐 날뛰는 해킹 운영체제가 부팅조차 되지 못하게 멱살을 잡아 컷(Cut)시켜버리자"는 시스템의 '시작점(Origin) 방어'입니다.

3. Counterexample

• 소프트웨어 안티바이러스 맹신 (Software Anti-Virus Fallacy): "윈도우 디펜더나 백신 프로그램을 깔았으니 부트 섹터(Boot Sector) 바이러스도 다 잡아주겠지"라고 맹신하는 치명적 멍청함. 악성 코드가 OS보다 먼저 켜지는 메인보드 펌웨어(UEFI)나 부트로더에 심겨 버리면(Rootkit), 백신이 눈을 뜨기도 전에 이미 시스템을 장악하여 백신에게 가짜 데이터를 보여주며 무적 상태가 됩니다. 하드웨어 기반의 보안 부팅(Secure Boot) 없이 소프트웨어 백신만 믿는 것은 모래 위에 성을 쌓는 것입니다.
• 단일 지점 해시 검증 (Single Point Verification Breakdown): 보안 부팅 체인을 설계할 때 부트로더(GRUB)는 열심히 서명 검증을 해놓고, 정작 부트로더가 커널(OS)을 메모리에 올릴 때는 귀찮다고 서명 검증 코드를 빼먹는(Chain Break) 안일함. 신뢰 체인(Chain of Trust)은 단 하나의 연결 고리만 썩어 들어가도 전체 시스템의 신뢰가 완전히 무너지므로, 0단계(Boot ROM)부터 N단계(OS Kernel)까지 한 치의 오차 없는 암호학적 파이프라인 검증이 강제되어야 합니다.

4. Prerequisites

• 비대칭 암호와 전자 서명 (Basic): RSA/ECC 퍼블릭 키를 이용해 "이 코드가 진짜 마이크로소프트가 만든 게 맞는지" 서명(Signature)을 검증하는 기본 수학적 매커니즘을 숙지해야 부트 체인을 이해할 수 있습니다. (10-03-01)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 실리콘에 새겨진 맹세, 신뢰 루트 (Hardware Root of Trust)

• Why to Learn: 소프트웨어는 결국 누군가(해커)가 0을 1로 덮어쓸 수 있는 모래성일 뿐이므로, 물리적으로 절대 변조 불가능한 화강암(반도체 ROM) 레벨의 기둥을 박아넣는 시발점을 장악하기 위함입니다.
• What to Learn:
  • Concepts: 하드웨어 신뢰 루트(Hardware RoT), 불변 ROM(Immutable Boot ROM).
  • Skills: 전자 퓨즈(eFuse / OTP: One Time Programmable), 제조사 공개키(OEM Public Key) 하드와이어링.
  • Tools: 실리콘 다이(Die) 맵핑.
  • Trade-offs: Boot ROM 코드는 전원이 들어오자마자 무조건 실행되는 무적의 신뢰를 자랑하지만, 만약 공장에서 Boot ROM 코드에 버그를 낸 채로 출하해버리면 소프트웨어 패치(업데이트)가 물리적으로 불가능해 칩 전량을 리콜(폐기)해야 하는 극악의 치명타 위험(닌텐도 스위치 테그라 칩 해킹 사태).
• How to Learn:
  • 1단계: CPU 전원이 켜지자마자 가장 먼저 읽어 들이는 주소(Reset Vector)가 메인보드 플래시 칩이 아니라, CPU 다이(Die) 내부에 레이저로 각인되어 물리적으로 쓰기(Write) 전압 핀이 존재조차 하지 않는 불변 ROM(Boot ROM)임을 해부합니다.
  • 2단계: 그 불변 ROM 안에는 "다음 단계의 펌웨어를 검증할 때 쓸 제조사 공개키(Public Key)"의 해시값이 eFuse(한 번 태우면 끝인 실리콘 선)로 끊겨 있어, 해커가 아무리 권한을 뺏어도 퓨즈를 다시 연결할 수는 없는 양자 역학적 방어 구조를 뜯어봅니다.
• Implement: 파이썬으로 ReadOnlyMemory 클래스를 만들어 write() 메서드 자체를 오버라이드하여 예외(Exception)를 뱉게 만들고, 이 객체 안에 ["OEM_Public_Key"]를 하드코딩한 뒤, 부팅 함수가 이 키를 통해서만 외부 펌웨어의 전자 서명을 승인하는 가상 칩셋 초기화 스크립트 작성.

Recommended

Core Topic 02: 신뢰의 사슬, 보안 부팅 물리 (Chain of Trust & Secure Boot)

• Why to Learn: 1MB짜리 Boot ROM이 수백 MB짜리 OS 커널을 한 방에 검증하는 건 메모리 구조상 불가능하므로, A가 B를 검증하고 B가 C를 검증하는 도미노(Domino) 식 연쇄 보안망을 설계하기 위해서입니다.
• What to Learn:
  • Concepts: 신뢰의 사슬(Chain of Trust), 부트스트래핑(Bootstrapping).
  • Skills: 서명 검증 릴레이(Boot ROM $\rightarrow$ First Stage Bootloader $\rightarrow$ OS Bootloader $\rightarrow$ OS Kernel).
  • Tools: 해시 및 RSA 전자 서명 연산기.
  • Trade-offs: 매 부팅 단계마다 수 메가바이트의 코드를 메모리에 올려 SHA-256 해시를 돌리고 RSA 복호화를 때려야 하므로 발생하는 1~2초의 짜증 나는 부팅 지연 시간(Boot Delay) vs 해킹된 부트로더가 켜져서 랜섬웨어에 통째로 장악당하는 리스크 차단.
• How to Learn:
  • 1단계: Boot ROM(A)이 플래시에서 부트로더(B)를 메모리로 퍼올린 뒤, "B의 코드 덩어리 해시값"이 "A가 들고 있는 공개키로 풀리는 B의 전자 서명"과 완벽히 일치할 때만 CPU 제어권을 B의 시작 주소로 넘겨주는(Jump) 엄격한 멱살잡이 배턴 터치를 해부합니다.
  • 2단계: 만약 해커가 부트로더(B) 코드 1바이트라도 악성 코드로 덮어쓰면, 해시값이 우주 끝까지 달라져 서명 검증이 깨지고 Boot ROM이 즉시 전원을 뽑아버리는(Halt) 무자비한 격리 조치를 뜯어봅니다.
• Implement: 함수 A, B, C를 만들어 A는 B의 텍스트 스크립트를 RSA 공개키로 검증(verify(B.script, B.signature))한 후 exec(B)를 치고, B는 다시 C를 검증 후 exec(C)를 치는 파이프라인 구축. C 스크립트에 "Hack"이라는 단어를 한 글자 추가했을 때 연쇄 검증망이 박살 나 부팅(Execution)이 중단되는 시나리오 모사.

Practical

Core Topic 03: UEFI 아키텍처와 PKI 계층 (UEFI Secure Boot)

• Why to Learn: 우리가 매일 쓰는 윈도우 PC나 리눅스 서버에서, 마더보드(메인보드)가 어떻게 바이러스 부트로더를 걸러내고 "정품 OS"만 켤 수 있는지 현실 세계의 데스크톱 보안 스펙을 쥐기 위함입니다.
• What to Learn:
  • Concepts: UEFI(Unified Extensible Firmware Interface), 플랫폼 키(PK), 키 교환 키(KEK).
  • Skills: 화이트리스트 데이터베이스(db), 블랙리스트(dbx), 펌웨어 설정 권한 통제.
  • Tools: 리눅스 셰임(Shim) 부트로더.
  • Trade-offs: 마이크로소프트의 인증서(KEK/db)가 마더보드에 독점적으로 박혀 있어 해커의 접근을 철벽 방어하는 우수한 윈도우 생태계 보호력 vs 서명을 받지 못한 군소 리눅스 배포판(Ubuntu 등)을 깔려고 하면 마더보드가 "너 가짜 OS지!"라며 부팅을 거부해버리는(Vendor Lock-in) 자유 오픈소스 진영과의 끔찍한 충돌.
• How to Learn:
  • 1단계: 공장에서 마더보드 NVRAM에 플랫폼 키(PK)가 구워지고, 이 PK가 KEK(운영체제 벤더 키)를 보증하며, KEK가 다시 db(부트 서명 리스트)를 보증하는 3단 계층적(Hierarchical) 인증서 구조를 해부합니다.
  • 2단계: 유출된 해커의 인증서나 취약한 부트로더 해시값이 발견되면, 업데이트를 통해 그 값을 dbx(블랙리스트)에 때려 박아 영원히 부팅 금지(Revocation)를 먹여버리는 펌웨어 격리 역학을 뜯어봅니다.
• Implement: 딕셔너리로 db (허용 리스트)와 dbx (금지 리스트)를 만들고, 부트로더 바이너리를 로드할 때 해당 해시가 dbx에 있으면 즉각 Boot_Failure를 던지며, db에 서명 매칭이 될 때만 Load_OS()를 호출하는 가상 UEFI 펌웨어 로직 구현.

Advanced

Core Topic 04: TPM 칩과 측정된 부팅 (TPM & Measured Boot)

• Why to Learn: 클라우드 가상머신(VM)이나 기업용 랩톱이 해킹당했을 때, 냅다 부팅을 멈춰버리는(Secure Boot) 대신 "일단 켜지게 냅두되, 부팅 과정 전체의 발자국을 하드웨어 칩(TPM)에 강제 박제하여 나중에 네트워크로 보고(Reporting)"하는 고도화된 감시 체계를 장악하기 위해서입니다.
• What to Learn:
  • Concepts: TPM(Trusted Platform Module), PCR(Platform Configuration Register).
  • Skills: 해시 확장(Hash Extend: PCR = Hash(PCR || New_Data)), 동적 신뢰 루트(DRTM).
  • Tools: 비트로커(BitLocker) 볼륨 암호화 연동.
  • Trade-offs: 부팅 실패로 서버가 먹통이 되는 사태를 막으면서도 무결성 로깅이 가능한 유연함 vs 해커가 부팅 후 OS 권한을 따내 TPM의 로그 값을 거짓으로 위조하려고 시도할 위험(물론 TPM의 암호학적 Extend 역학 때문에 위조는 수학적으로 불가능함).
• How to Learn:
  • 1단계: 마더보드에 납땜 된 쥐똥만 한 TPM 칩 안의 24개짜리 슬롯(PCR)은 절대 '직접 덮어쓰기'가 불가능하고, 오직 "기존 해시값과 새로운 이벤트 해시값을 이어 붙여(Concatenate) 다시 해시를 치는(Extend)" 덧칠하기 연산만 허용되어 과거의 기록 세탁을 양자 역학적으로 막아내는 설계를 해부합니다.
  • 2단계: 윈도우 비트로커(BitLocker)가 디스크 암호를 풀 때 유저 패스워드만 묻는 게 아니라, TPM 칩에게 "PCR 레지스터 0번부터 7번까지(부트로더와 커널 서명 발자국)가 어제랑 똑같아?"라고 물어보고, 단 1비트라도 빗나가면 해킹으로 간주하고 키 방출을 셧다운 해버리는 연계 물리를 뜯어봅니다.
• Implement: 초기값이 0인 PCR 레지스터 변수를 두고, extend(new_data) 함수 호출 시 PCR = SHA256(PCR + SHA256(new_data)) 로만 업데이트되도록 강제하는 클래스 작성. 정상 부팅 체인(A $\rightarrow$ B $\rightarrow$ C)과 해킹된 체인(A $\rightarrow$ B' $\rightarrow$ C)의 최종 PCR 상태(해시 폭포 효과)가 완전히 우주 끝까지 달라짐을 콘솔에 덤프하여 무결성 감시망 증명.

7. Terminology

8. References

Primary

• [P3] CyBOK v1.1 - Hardware Security / Hardware Roots of Trust — Standard reference.
• [P1] CS2023 - AR/System Security Hardware Support — Educational requirements.

Secondary

• [Trusted Computing Platforms: TPM 2.0 in Context] Challener et al. — The TPM 2.0 handbook.
• [Windows Boot & Security: A deep dive into Secure Boot] — Practical OS implementation.

Industry

• [TCG (Trusted Computing Group) Main Specification] — Official industry standard.
• [NIST SP 800-155: BIOS Integrity Measurement] — Government hardware standards.

9. Final Checklist

Primary

• '보안 부팅' 과정에서 하드웨어가 읽어 들이는 'DB/DBX' 리스트가 불어난 서명들을 어떻게 물리적으로 필터링하는지 설명 가능한가? (P1)
• 시스템 전원이 들어온 직후 실행되는 '첫 번째 유효 명령'이 왜 반드시 하드웨어 ROM에 있어야 함을 입증할 수 있는 가? (P1)

Secondary

• TPM의 PCR 레지스터에 값을 쓸 때 왜 단순 저장이 아닌 'Extend(SHA1/SHA256)' 물리 연산을 수행해야 하는지 소통 가능한가?
• 하드웨어 RoT가 깨졌을 때, 소프트웨어 수준의 모든 보안 방어막(Encryption, VPN 등)이 왜 의미를 잃는지 물리적 완결성 측면에서 증명할 수 있는 가?

Industry

• 대규모 서버 인프라 운영 시, 'Measured Boot' 데이터를 기반으로 오염된 노드를 자동 격리하는 보안 관제 시나리오를 제안할 수 있는 가? (SFIA)
• 임베디드 기기 설계 시, 양산 과정에서 암화화 키를 하드웨어 퓨즈(eFuse)에 굽는 'Key Provisioning' 공정의 물리적 보안 절차를 기술할 수 있는 가?