정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#Secure Boot#Root of Trust#신뢰 체인#UEFI#원격증명
최종 업데이트 · 2026-10-26

보안 부팅(Secure Boot)과 신뢰 체인(Chain of Trust)

1. 개요

가. 정의

보안 부팅(Secure Boot) 이란 하드웨어에 고정된 신뢰의 뿌리(Root of Trust, RoT) 에서 출발해, 전원 인가 직후부터 펌웨어 → 부트로더 → 운영체제 커널 → 응용에 이르는 각 단계가 다음 단계의 코드를 실행하기 전에 그 무결성을 암호학적으로 검증(또는 측정)하고 신뢰를 전이하는 부팅 보안 체계를 말한다. 이렇게 단계마다 신뢰가 끊김 없이 이어지는 구조를 신뢰 체인(Chain of Trust) 이라 하며, UEFI Secure Boot·Measured Boot·원격 증명(Attestation)이 이를 구현하는 대표 기술이다.

보안 부팅의 근본 발상은 "무엇이 보안 소프트웨어 자신의 무결성을 보증하는가"라는 순환 문제를 끊는 데 있다. 백신·EDR·방화벽 같은 보안 솔루션은 결국 운영체제 위에서 실행되는 코드이므로, 커널이나 그보다 먼저 뜨는 부트로더·펌웨어가 조작되면 보안 소프트웨어가 로드되기도 전에 이미 장악당한다. 즉 '가장 먼저 실행되는 코드'가 신뢰되지 않으면 그 위의 모든 보안은 사상누각이 된다. 보안 부팅은 변조가 어려운 하드웨어에 신뢰의 출발점을 못 박고, 거기서부터 상위 계층으로 신뢰를 한 단계씩 '증명하며' 넘겨줌으로써 이 공백을 메운다.

여기서 핵심은 신뢰가 전이(transitive)된다는 점이다. RoT 자신은 외부가 검증해 주는 것이 아니라 하드웨어적으로 '믿는다고 전제'하는 공리(axiom)이며, 그 뒤의 모든 단계는 바로 앞 단계가 검증해 주기 때문에 신뢰된다. 따라서 체인의 어느 한 고리라도 검증 없이 건너뛰거나 뿌리가 손상되면 그 아래 전체의 신뢰가 붕괴한다. 보안 부팅 설계가 "가장 약한 고리"의 문제로 귀결되는 이유가 여기에 있다.

나. 등장 배경과 필요성

전통적 보안은 OS가 뜬 '이후'를 지키는 데 집중해 왔다. 그러나 공격자가 OS보다 먼저 자리를 잡는 부트킷(Bootkit)·루트킷(Rootkit)·펌웨어 임플란트가 등장하면서, OS 수준 보안으로는 탐지·제거가 사실상 불가능한 위협이 현실화됐다. 부팅 초기 단계를 장악한 악성코드는 커널 서명 검증을 우회하고, BitLocker·HVCI·Defender 같은 방어를 부팅 과정에서 미리 무력화하며, OS를 다시 설치해도 디스크 밖(펌웨어·ESP)에 남아 재감염을 일으킨다.

이러한 위협의 심각성은 실제 사례로 드러났다. 2023년 공개된 BlackLotus는 완전히 패치된 Windows 11에서도 UEFI Secure Boot를 우회한 최초의 상용 부트킷으로, 구형 취약 부트로더를 되돌려 심는 CVE-2022-21894(Baton Drop) 와 후속 CVE-2023-24932 를 악용했다. 미국 NSA가 별도 완화 가이드를 발간하고, Microsoft가 취약 부트로더를 폐기 목록(dbx)에 등록하는 대응을 단계적으로 전개해야 했을 만큼 파장이 컸다. 이는 "보안 부팅이 있다"는 사실만으로는 부족하며, 취약해진 신뢰 요소를 폐기(Revocation) 하고 신선하게 유지하는 운영까지 함께 가야 함을 보여준다.

또한 보안 부팅은 공급망·장치 신뢰의 토대라는 점에서 필요성이 커진다. 제로트러스트(Zero Trust)에서 "이 디바이스를 믿어도 되는가"를 판단하려면 그 기기가 변조되지 않은 상태로 부팅되었다는 하드웨어 근거가 있어야 한다. 데이터센터의 서버 펌웨어 변조, IoT·OT 기기의 펌웨어 교체, 중고·반입 기기의 임플란트 같은 공급망 위험이 커지면서, 보안 부팅과 그 측정값에 기반한 원격 증명은 선택이 아니라 기본 요구사항으로 자리 잡고 있다.

2. 신뢰 체인의 전체 구조와 핵심 개념

보안 부팅은 '하드웨어 뿌리 → 상위 계층'으로 신뢰가 단방향 전이되는 계층 구조로 이해해야 한다. 아래 전체 구조도는 전원 인가 직후 불변의 RoT에서 시작해, 각 단계가 다음 단계를 검증(Verify)하거나 측정(Measure)하면서 제어를 넘기고, 측정값은 TPM에 누적되어 최종적으로 원격 증명에 활용되는 흐름을 보여준다.

flowchart TD
  RoT["신뢰의 뿌리(RoT) - 불변 Boot ROM·퓨즈"]
  FW["플랫폼 펌웨어(UEFI/BIOS)"]
  BL["부트로더(shim·GRUB 등)"]
  OS["OS 커널·드라이버"]
  APP["응용·서비스"]
  TPM[("TPM - PCR 누적")]
  VER["원격 검증 서버(Attestation)"]
  RoT -->|"검증 후 제어 이양"| FW
  FW -->|"검증 후 제어 이양"| BL
  BL -->|"검증 후 제어 이양"| OS
  OS -->|"검증 후 제어 이양"| APP
  RoT -.->|"측정값 extend"| TPM
  FW -.->|"측정값 extend"| TPM
  BL -.->|"측정값 extend"| TPM
  OS -.->|"측정값 extend"| TPM
  TPM -->|"PCR 서명(Quote) 제출"| VER
  style RoT fill:#e8f0fe,stroke:#2f6fed,stroke-width:2px
  style TPM fill:#eafbea,stroke:#2f9e44,stroke-width:1px
  style VER fill:#fef3e8,stroke:#ed8f2f,stroke-width:1px

가. 신뢰의 뿌리(Root of Trust)

신뢰 체인은 반드시 '변하지 않는 무언가'에서 출발해야 한다. 이 출발점이 RoT이며, 보통 칩 제조 시 마스크 ROM에 구워진 불변 코드(immutable Boot ROM) 와, OEM 공개키의 해시를 담아 쓰기가 불가능한 일회성 퓨즈(OTP fuse) 로 구현된다. 소프트웨어로 교체·수정할 수 없기 때문에 공격자가 손대기 가장 어려운 지점이며, 바로 이 성질이 '신뢰의 공리'가 될 자격을 부여한다.

RoT는 기능에 따라 세 가지로 나뉜다. 측정의 뿌리(RTM, Root of Trust for Measurement) 는 부팅 요소의 해시를 처음으로 계산해 신뢰 체인의 측정을 개시하고, 저장의 뿌리(RTS) 는 키와 측정값을 안전하게 보관하며, 보고의 뿌리(RTR) 는 측정 결과를 외부에 신뢰성 있게 증명한다. TPM은 RTS·RTR을, CPU 내부의 최초 측정 코드(CRTM)는 RTM을 담당하는 식으로 역할이 분담된다. 이렇게 뿌리를 기능별로 명확히 정의해야 "무엇을 믿고, 무엇을 증명하는가"가 분명해진다.

중요한 설계 원칙은 뿌리는 작고 단순해야 한다는 점이다. RoT 코드가 크고 복잡하면 그 안의 결함이 곧 전체 신뢰의 붕괴로 이어지므로, 검증 가능한 최소한의 코드(수 KB 수준)만 두고 나머지 기능은 상위 계층으로 미룬다. 이 '최소 신뢰 기반(Minimal TCB)' 원칙은 보안 부팅뿐 아니라 모든 신뢰 컴퓨팅 설계의 공통 교훈이다.

나. 신뢰 전이(Chain of Trust)의 원리

신뢰 체인의 각 고리는 동일한 패턴을 반복한다. (1) 현재 단계가 다음에 실행할 코드를 메모리에 적재 → (2) 그 코드의 서명·해시를 검증(또는 측정) → (3) 검증 통과 시에만 제어권을 넘김. 이 "검증 후 실행(verify-then-execute)" 규칙이 끊기지 않고 뿌리까지 이어질 때 비로소 '부팅된 전체 소프트웨어 스택이 신뢰할 수 있다'는 보장이 성립한다.

이때 중요한 것은 신뢰가 아래로만 흐른다는 비대칭성이다. 상위 계층은 하위 계층을 신뢰할 수밖에 없지만, 하위 계층은 상위를 믿지 않고 오히려 검증한다. 따라서 체인 중간의 한 요소가 취약하면 그 아래(이후 단계)는 모두 오염되지만, 그 위(이전 단계)는 영향을 받지 않는다. BlackLotus가 '부트로더' 단계를 노린 것도, 그 아래의 커널·OS 전체를 한 번에 장악할 수 있기 때문이다.

다. 검증형 부팅과 측정형 부팅

보안 부팅에는 성격이 다른 두 접근이 있으며, 실제 시스템은 둘을 병행한다. 검증형 부팅(Verified/Secure Boot) 은 서명 검증에 실패하면 부팅을 중단하는 '예방(Prevention)' 중심 방식이고, 측정형 부팅(Measured Boot) 은 각 단계의 해시를 TPM PCR에 기록만 하고 부팅은 계속 진행한 뒤, 그 측정값으로 나중에 상태를 '증명'하게 하는 '탐지(Detection)' 중심 방식이다. 전자는 변조된 코드의 실행 자체를 막고, 후자는 "어떤 상태로 부팅됐는지"를 사후에 증거로 남긴다.

구분 검증형 부팅(Verified Boot) 측정형 부팅(Measured Boot)
목적 예방(부정 코드 실행 차단) 탐지(부팅 상태 증명)
동작 서명 검증 실패 시 부팅 중단 해시를 TPM PCR에 누적, 부팅 진행
근거 db/dbx·공개키 서명 PCR 값 + 원격 증명
한계 허용된 취약 코드는 통과 차단은 못 함(판단은 검증자 몫)
대표 UEFI Secure Boot TPM 기반 Measured Boot

두 방식은 상호 보완적이다. 검증형만 쓰면 '서명은 유효하지만 취약한' 부트로더(예: Baton Drop 구형 바이너리)를 막지 못하고, 측정형만 쓰면 변조 코드가 일단 실행된 뒤에야 탐지된다. 그래서 실무에서는 검증형으로 1차 차단하고, 측정형+원격 증명으로 "허용된 것 중 실제로 무엇이 떴는가"까지 검증해 심층 방어(Defense in Depth)를 구성한다.

3. 동작 메커니즘 — UEFI Secure Boot·TPM 측정·원격 증명

아래 상세도는 x86 플랫폼을 기준으로, UEFI 펌웨어가 키 계층(PK·KEK·db·dbx)으로 부트로더 서명을 검증하는 흐름과, 동시에 각 단계의 해시가 TPM PCR에 누적되어 원격 증명으로 이어지는 과정을 함께 나타낸다. 검증(실선)과 측정(점선)이 같은 부팅 과정에서 병행된다는 점이 핵심이다.

sequenceDiagram
  participant FW as UEFI 펌웨어
  participant KEYS as 키 DB(PK·KEK·db·dbx)
  participant BL as 부트로더
  participant TPM as TPM(PCR)
  participant SRV as 검증 서버
  FW->>KEYS: 부트로더 서명 조회
  KEYS-->>FW: db 허용·dbx 폐기 여부 응답
  alt 서명 유효하고 dbx에 없음
    FW->>TPM: 부트로더 해시 extend(PCR)
    FW->>BL: 제어 이양(실행)
    BL->>TPM: 커널·설정 해시 extend(PCR)
  else 서명 불일치 또는 dbx 등재
    FW--xBL: 부팅 중단(검증형 차단)
  end
  BL->>SRV: 부팅 완료, Quote 요청 트리거
  TPM-->>SRV: PCR 값 서명(Quote) 제출
  Note over SRV: 기준값(golden)과 비교해 신뢰 판정

가. UEFI Secure Boot의 키 계층

UEFI Secure Boot는 네 종류의 변수로 신뢰를 관리한다. 최상위 PK(Platform Key) 는 플랫폼 소유자(OEM)의 권한을 상징하며 KEK를 관리한다. KEK(Key Exchange Key) 는 db·dbx를 갱신할 수 있는 권한 키다. db(Signature Database) 는 부팅을 허용할 서명자·해시의 '허용 목록'이고, dbx(Forbidden Signature Database) 는 취약·악성으로 판명된 바이너리를 막는 '폐기 목록'이다. 펌웨어는 부트로더의 서명이 db에 있고 dbx에는 없을 때만 실행한다.

이 계층 구조가 중요한 이유는 폐기(dbx)와 권한 분리 때문이다. 특정 부트로더가 취약해지면 그 해시를 dbx에 추가해 전 세계적으로 차단할 수 있는데, 이는 인증서 폐기와 동일한 원리다. 리눅스 진영은 Microsoft UEFI CA가 서명한 shim 부트로더를 두어, 배포판이 자체 키로 서명한 GRUB·커널을 Microsoft 신뢰 아래에서 부팅시키는 방식으로 상호운용성을 확보한다. 그러나 이 구조는 PK가 안전하게 관리된다는 전제에 전적으로 의존한다.

바로 그 전제가 깨진 대표 사례가 2024년 PKfail이다. Binarly는 American Megatrends(AMI)가 테스트용으로 만들어 "DO NOT TRUST"로 명시한 Platform Key가 교체되지 않은 채 Acer·Dell·HP·Lenovo·Supermicro 등 약 813개 제품(2012년 5월~2024년 6월 출시 펌웨어)에 그대로 출하된 사실을 밝혀냈다(BRLY-2024-005). 유출된 테스트 PK 개인키를 쥔 공격자는 KEK·db·dbx를 조작해 Secure Boot를 무력화할 수 있다. 이는 "신뢰의 뿌리인 키 관리가 무너지면 상위의 모든 검증이 의미를 잃는다"는 신뢰 체인의 본질을 그대로 보여준 사건이다.

나. 측정형 부팅과 TPM PCR

측정형 부팅의 심장은 TPM의 PCR(Platform Configuration Register) 누적 기록이다. 각 단계는 다음 코드를 실행하기 전 그 해시를 계산해 PCR에 기록하는데, 이때 덮어쓰기가 아니라 PCR_new = Hash(PCR_old ‖ 측정값) 형태로 extend(누적) 한다. 이 연산은 되돌릴 수 없으므로, 부팅 과정 어느 한 단계라도 바뀌면 최종 PCR 값이 완전히 달라진다. 즉 PCR은 '위조 불가능한 부팅 이력의 지문'이 된다.

예컨대 PCR0~7에는 펌웨어·옵션롬·설정·부트로더 측정값이, 그 위로는 OS 로더·커널 측정값이 나뉘어 기록된다. 이렇게 단계별로 PCR을 분리하면, 나중에 "펌웨어는 정상인데 부트로더만 바뀌었다"처럼 변조 지점을 세분화해 판단할 수 있다. 측정 기록은 TPM 밖의 이벤트 로그와 함께 유지되어, 검증자가 각 측정값의 의미를 재구성할 수 있게 한다.

다. 원격 증명(Remote Attestation)과 롤백 방지

측정값은 기기 내부에만 두면 "스스로를 믿어 달라"는 자기 참조에 그친다. 그래서 TPM은 PCR 값들을 증명키(AIK/AK)로 서명(Quote) 해 원격 검증 서버에 제출하고, 서버는 이를 사전에 확보한 기준값(golden measurement) 과 비교해 그 기기가 신뢰할 수 있는 상태로 부팅됐는지 판정한다. 이것이 제로트러스트에서 디바이스 신뢰를 하드웨어 근거로 뒷받침하는 핵심이며, 기밀 컴퓨팅(Intel TDX·AMD SEV-SNP)의 VM 증명도 같은 원리를 쓴다.

한편 신뢰 체인은 롤백(다운그레이드) 공격에도 대비해야 한다. 서명은 유효하지만 이미 취약점이 알려진 구버전 펌웨어·부트로더로 되돌리는 공격을 막기 위해, 단조 증가 카운터(monotonic counter)나 퓨즈로 최소 허용 버전을 강제하는 안티롤백(Anti-rollback) 을 둔다. 나아가 NIST SP 800-193(Platform Firmware Resiliency)은 펌웨어 보안을 보호(Protection)·탐지(Detection)·복구(Recovery) 의 세 축으로 규정해, 변조 시 신뢰할 수 있는 복구본으로 자동 회복하는 복원력(Resiliency) 까지 요구한다.

4. 플랫폼별 구현 비교와 사례

신뢰 체인의 원리는 공통이지만, 뿌리를 어디에 두고 어떻게 검증하는지는 플랫폼마다 다르다. 서버·PC는 CPU·칩셋에 뿌리를 두는 Intel Boot Guard·AMD PSB로 펌웨어 자체를 먼저 검증하고, 모바일·임베디드는 SoC 내부 Boot ROM과 ARM TrustZone·TF-A 체인을 쓰며, 폐쇄 생태계인 Apple은 불변 Boot ROM과 Secure Enclave로 매우 견고한 체인을 구성한다. 이 차이는 '얼마나 개방적이고 교체 가능한가'와 '얼마나 통제되고 견고한가'의 트레이드오프를 반영한다.

플랫폼 신뢰의 뿌리 검증 체인 특징
x86 PC/서버 Intel Boot Guard·AMD PSB(퓨즈) 펌웨어→UEFI Secure Boot→부트로더 개방·상호운용(shim), dbx 폐기
ARM 모바일/임베디드 SoC Boot ROM BL1→BL2→BL31→부트로더(TF-A) TrustZone 보안세계 분리
Apple 불변 Boot ROM·Secure Enclave LLB→iBoot→커널 폐쇄·강견고, 롤백 강제
Android 하드웨어 RoT Android Verified Boot(dm-verity) 파티션 무결성·롤백 방지
Chromebook 읽기전용 펌웨어 RO→RW(A/B)→커널 복구용 이중화·자가복구

구체 사례로, Google Chromebook의 Verified Boot는 읽기 전용 펌웨어를 뿌리로 삼고 A/B 두 벌의 읽기·쓰기 펌웨어를 두어, 한쪽이 손상되면 다른 쪽이나 복구 모드로 자동 회복한다 — NIST SP 800-193이 말하는 '복구'를 제품 수준에서 구현한 예다. Android의 AVB(Android Verified Boot) 는 dm-verity로 시스템 파티션의 블록 단위 무결성을 검증하고, vbmeta에 최소 허용 버전을 담아 다운그레이드를 막는다. Apple은 Boot ROM부터 커널까지 서명이 하나라도 어긋나면 복구 모드로 빠지는 체인을 구성해, 사실상 상용 기기 중 가장 변조가 어려운 축에 든다.

5. 심화 — 신뢰 체인의 공격·우회와 최신 동향

보안 부팅이 보편화되자 공격자는 체인의 '가장 약한 고리'를 노리는 방향으로 진화했다. 첫째 흐름은 서명은 유효하되 취약한 요소를 되돌려 심는 우회다. BlackLotus(2023)가 Baton Drop(CVE-2022-21894) 구형 부트로더를 재이용해 패치된 Windows 11의 Secure Boot를 넘은 것이 전형으로, 이는 "허용 목록(db) 기반 검증만으로는 부족하며 폐기(dbx)를 신선하게 유지해야 한다"는 교훈을 남겼다. 그러나 dbx 갱신은 자칫 정상 기기를 부팅 불능으로 만들 수 있어, Microsoft는 신중한 단계적 배포(KB5025885 등)로 대응해야 했다.

둘째 흐름은 뿌리·키 관리 자체의 붕괴다. PKfail(2024)은 테스트 PK가 수백 개 모델에 방치돼, 아무리 상위 검증이 정교해도 뿌리 키가 공유·유출되면 전체가 무너진다는 점을 드러냈다. 이는 보안 부팅의 리스크가 암호 알고리즘이 아니라 키 생애주기 관리(생성·주입·교체·폐기) 라는 운영 문제에 있음을 시사한다.

셋째 흐름은 TPM 없는 경량·IoT 환경으로의 확장이다. TCG의 DICE(Device Identifier Composition Engine) 는 전용 보안칩이 없는 소형 기기를 위해, 칩 고유 비밀(UDS)과 각 계층 측정값을 키 유도 함수에 넣어 계층별 복합 식별자(CDI)를 파생하는 방식으로 하드웨어 신뢰와 기기 고유 신원을 동시에 제공한다. 각 계층이 사용 후 자신의 비밀을 지워 상위로 전이하므로, 저비용 MCU에서도 신뢰 체인과 원격 증명을 구현할 수 있어 Android·기밀 컴퓨팅 등에서 채택이 늘고 있다.

넷째 흐름은 암호 민첩성(Crypto Agility)과 포스트 양자 전환이다. 부팅 서명에 쓰이는 RSA·ECDSA가 양자 컴퓨팅 위협에 노출되면서, 부팅 검증 알고리즘을 ML-DSA 등 양자내성암호(PQC)로 교체할 수 있도록 펌웨어·키 구조를 설계하는 논의가 진행 중이다. 뿌리 키와 서명 체계를 교체하는 일은 대규모 재서명·폐기를 수반하므로, 신뢰 체인의 알고리즘 교체 가능성을 미리 설계에 반영하는 것이 점점 중요해지고 있다.

6. 고려사항 및 시사점

첫째, 보안 부팅은 '기능 유무'가 아니라 '운영·폐기 체계'로 평가해야 한다. BlackLotus 사례처럼, Secure Boot가 켜져 있어도 취약 요소를 폐기(dbx)하지 못하면 우회된다. 조직은 펌웨어·부트로더·dbx의 최신화를 자산관리·패치관리에 편입하고, 폐기 배포가 정상 기기를 벽돌로 만들지 않도록 사전 검증·단계적 롤아웃 절차를 갖춰야 한다.

둘째, 신뢰의 뿌리인 키 관리를 최우선으로 통제해야 한다. PKfail이 보여주듯 뿌리 키의 공유·유출은 상위 검증 전체를 무력화한다. OEM·운영자는 기기별 고유 PK 생성, 테스트 키의 생산 반입 차단, HSM 기반 서명, 키 교체·폐기 절차를 공급망 보안 요구사항으로 명문화하고, 조달 단계에서 이를 검증해야 한다.

셋째, 검증형과 측정형을 병행해 심층 방어를 구성하고, 원격 증명을 제로트러스트와 연계해야 한다. 검증형으로 부정 코드 실행을 막되, 측정형+원격 증명으로 "허용된 것 중 실제 부팅된 상태"까지 검증해 디바이스 신뢰 판단에 활용한다. 이는 MDM·조건부 접근·기밀 컴퓨팅 증명과 통합할 때 실효성이 커진다.

넷째, 복원력(Resiliency)을 설계 요소로 포함해야 한다. NIST SP 800-193의 보호·탐지·복구 원칙에 따라, 펌웨어 변조 탐지 시 신뢰할 수 있는 골든 이미지로 자동 복구하는 메커니즘(이중화·복구 영역)을 갖춰야 가용성과 보안을 동시에 지킬 수 있다. 특히 무인·원격 운영되는 서버·OT·IoT에서는 복구 자동화가 필수다.

다섯째, 전망적으로 경량 RoT와 암호 민첩성에 선제 투자해야 한다. TPM이 없는 대규모 IoT·엣지로 신뢰 컴퓨팅을 확장하려면 DICE 같은 경량 RoT 표준을 검토하고, 장기적으로 PQC 전환에 대비해 부팅 서명 알고리즘을 교체 가능한 구조로 설계해야 한다. 보안 부팅은 일회성 구축이 아니라, 신뢰 요소를 지속적으로 갱신·증명·복구하는 신뢰 공급망(Trust Supply Chain) 관리의 문제임을 인식하는 것이 기술사 수준의 관점이다.

참고자료

한 줄 요약: 보안 부팅은 하드웨어 신뢰의 뿌리(RoT)에서 출발해 펌웨어·부트로더·커널까지 '검증 후 실행'으로 신뢰를 전이하는 체인이며, UEFI Secure Boot(검증형)·TPM 측정형·원격 증명을 병행하되 dbx 폐기·키 관리·복원력(NIST SP 800-193)까지 운영해야 BlackLotus·PKfail 같은 우회를 막을 수 있다.