Windows의 TPM이란 무엇인가 ── 그림으로 보는 「키를 밖으로 내보내지 않는 금고」와 측정 부팅

「Windows 11로 올릴 수 없는 PC가 있습니다. TPM이 없다고 합니다」──최근 몇 년, 법인의 PC 교체 상담에서 반드시 나오는 말입니다. 「보안용 칩인 것 같다」는 데까지는 알려져 있지만, 그것이 무엇을 하고, 왜 필수인지, 그리고 왜 BIOS만 업데이트해도 BitLocker 복구 키를 묻는지까지 설명할 수 있는 사람은 많지 않습니다.

TPM은 「암호화를 빠르게 하는 칩」이 아니고, 「바이러스를 막는 칩」도 아닙니다. 하는 일은, 거칠게 말하면 다음 두 가지뿐입니다.

1. 비밀 키를 자기 안에서 내보내지 않은 채로, 쓰게 해 준다
2. 부팅 때 무엇이 읽혔는지를 기록하고, 그 기록이 기대와 같을 때만 키를 내준다

이 두 가지를 알면, BitLocker, Windows Hello, Credential Guard, 디바이스 상태 증명 같은 Windows 보안 기능이 같은 토대 위에 올라 있다는 것도, 실무에서 만나는 문제의 이유도 깔끔히 설명됩니다.

이 기사에서는 TPM의 구조를 그림으로 잡은 다음, Windows의 어디에서 쓰이는지, 자기 PC 상태를 어떻게 확인하는지, 복구 키 화면이나 TPM 지우기 같은 현장 문제를 어떻게 다루는지, 그리고 개발자가 자기 앱에서 TPM을 쓰려면 어떻게 하는지를, 공식 문서의 근거와 함께 정리합니다.

다루는 범위가 넓으므로, 이 기사를 읽는 방법을 먼저 제시합니다. 처음부터 끝까지 읽을 필요는 없습니다.

1. 먼저 결론

TPM(Trusted Platform Module)은 암호 키의 생성·보관·이용을 맡는 보안 전용 프로세서입니다.¹ 하는 일은 서두에서 든 두 가지로 모입니다.

• 비밀 키를 칩 밖으로 내보내지 않은 채로 쓰게 한다(금고).내보내기 불가로 지정한 키의 비밀 부분은, 다른 소프트웨어·프로세스·사용자에게 전혀 공개되지 않습니다.²
• 부팅 때 무엇이 읽혔는지를 기록한다(대장).펌웨어나 부트 로더는, 다음에 실행할 코드의 해시를 PCR이라는 영역에 기록한 뒤 제어를 넘깁니다. 이 기록이 기대와 같을 때만 키를 꺼낼 수 있는 「봉인」이 가능하고, BitLocker가 그 대표 예입니다.³²

이 두 가지에서 실무에 바로 쓰이는 결론이 나옵니다. 자세한 내용은 각 장에서 설명합니다.

• Windows Hello의 PIN이 4자리여도 안전하게 성립하는 것은, 사전 공격 대책(인증 실패 32회면 lockout)이 하드웨어 쪽에 있기 때문입니다(2장).²
• Windows 11의 최소 요건은 「UEFI, 보안 부팅 대응」 펌웨어와 TPM 2.0입니다. 다만 Windows 11 IoT Enterprise에는 전용기용 완화 요건이 있어, TPM이 선택이 되는 구성도 있습니다(6장).⁴⁵
• TPM 구현은 3종류(전용 칩/통합/펌웨어)가 있지만, Windows는 모두 같이 사용합니다(5장).⁶
• Windows 10/11은 TPM을 자동으로 초기화해 소유권을 취득하므로, 보통 tpm.msc에서 설정을 만질 필요는 없습니다(8장).¹
• TPM 지우기는 데이터 손실로 이어집니다. 실행 전에 백업과 복구 수단 확인이 필수입니다(9장).⁷
• 개발자는 TPM을 직접 치지 말고 CNG의 「Microsoft Platform Crypto Provider」를 사용합니다(10장).⁸

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 34건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. TPM이란 무엇인가 ── 「키를 밖으로 내보내지 않는 금고」

먼저 TPM이 없는 세계를 생각합니다. 소프트웨어만으로 비밀 키를 지키려 하면, 키는 결국 어떤 타이밍에 메모리상의 평문이 됩니다. 서명이나 복호화 계산을 하려면 CPU가 키 값을 읽어야 하기 때문입니다. 즉 커널까지 도달한 멀웨어나, 메모리를 물리적으로 읽을 수 있는 공격자에게는 원리적으로 숨길 수 없습니다. 공식 문서도 소프트웨어에 의한 키 보호는 「사용 중에 메모리에서 키를 어떻게 보관하고, 어떻게 복사본을 만드는지 분석당하는 리버스 엔지니어링 공격을 받는다」고 명시합니다.³

TPM은 이 전제를 뒤집습니다. 키는 TPM 안에서 생성되고, TPM 안에 머뭅니다. 앱이나 OS는 키를 받는 것이 아니라, TPM에 일을 맡기고 결과만 받습니다.

flowchart TB
    subgraph SW["A. 소프트웨어만으로 키를 지키는 경우"]
        A1["앱 / OS"] -->|"키를 읽어 들여 계산한다"| A2["메모리상의 비밀 키<br/>평문이 되는 순간이 있다"]
        A2 -.->|"읽어 낼 수 있다"| A3["커널까지 도달한 멀웨어<br/>메모리 분석·물리 공격"]
    end
    subgraph HW["B. TPM에 키를 맡기는 경우"]
        B1["앱 / OS"] -->|"서명해 달라 / 복호화해 달라<br/>는 요청만 보낸다"| B2["TPM"]
        B2 --> B3["TPM 안의 비밀 키로 계산한다<br/>키는 칩 밖으로 나가지 않는다"]
        B3 -->|"결과만 돌려준다"| B4["앱 / OS가 받는 것은<br/>서명이나 복호화 결과만"]
        B5["커널까지 도달한 멀웨어<br/>메모리 분석·물리 공격"] -.->|"키 자체는 꺼낼 수 없다"| B2
    end
    SW ~~~ HW

그림 1: 소프트웨어만으로 키를 지키는 경우와, TPM에 키를 맡기는 경우의 차이

여기서 중요한 것은 TPM은 수동적(passive)이라는 점입니다. TPM은 스스로 무언가를 감시하거나 바이러스를 막지 않습니다. 명령을 받아 응답만 돌려주는 부품입니다.⁶ 그래서 TPM의 가치를 끌어내려면 OEM(PC 제조사)이 하드웨어와 펌웨어를 꼼꼼히 통합해야 하고, Windows가 그것을 전제로 기능을 조립하는 구도가 됩니다.

또 하나의 기둥이 사전 공격 대책입니다. TPM이 지키는 키에는 PIN 같은 인증값을 설정할 수 있습니다. 인증값 추측이 일정 횟수 실패하면 TPM은 추가 시도를 거부하고 lockout합니다. TPM 2.0에서는 이 동작을 Windows가 구성합니다. 구체적으로는 인증 실패 32회면 lockout하고, 10분이 지날 때마다 실패 1회분을 잊는 설정입니다. 320분 동안 전혀 실패가 없으면, 기억하고 있는 실패 횟수는 0으로 돌아갑니다.²

이 「횟수 제한이 하드웨어 쪽에 있다」는 사실이 여기서 효과를 냅니다. 소프트웨어로 실패 횟수를 세면, 재시작되거나 시스템 시계를 되돌리거나, 횟수를 기록한 파일을 롤백하면 무력화할 수 있습니다. TPM이라면 그것이 안 됩니다.³ Windows Hello의 PIN이 4자리여도 비밀번호보다 안전하다고 할 수 있는 근거는 바로 여기에 있습니다.

3. TPM 안 ── EK·SRK·PCR·NVRAM

TPM 내부에는 역할이 다른 요소가 몇 가지 들어 있습니다. 이름이 비슷해 헷갈리기 쉬우므로, 그림으로 위치 관계를 잡아 둡니다.

flowchart TB
    TPM["TPM 2.0"]
    TPM --> EK["EK / 보증 키<br/>제조 시 시드에서 도출된다<br/>제조사 인증서가 붙는다"]
    TPM --> SRK["SRK / 스토리지 루트 키<br/>다른 키를 감싸는 부모 키"]
    TPM --> PCR["PCR 0〜23<br/>부팅 측정값을 쌓는다"]
    TPM --> NV["NVRAM<br/>전원을 꺼도 안 지워지는 작은 영역"]
    EK --> AIK["AIK / 증명용 키<br/>EK 대신 밖으로 내보내는 신분증"]
    SRK --> K1["BitLocker의 키"]
    SRK --> K2["Windows Hello의 키"]
    SRK --> K3["인증서의 비밀 키"]
    PCR -.->|"이 값일 때만<br/>꺼낼 수 있다고 묶는다"| K1

그림 2: TPM의 주요 구성 요소와 키의 부모-자식 관계

EK(Endorsement Key / 보증 키)는 그 TPM 고유의 비대칭 키 쌍입니다. 비밀 쪽은 TPM 안에 유지되며, 외부에 공개되지도, 외부에서 접근되지도 전혀 없습니다.² 제조사가 서명한 EK 인증서가 붙어 「이 키는 분명히 당사가 제조한 TPM 안에 있다」는 것을 나타냅니다. 이로써 진짜 TPM인지, TPM을 가장한 멀웨어인지를 구별할 수 있습니다.³

보충: TPM 2.0의 EK는 「구워 넣은 키」가 아니라 「시드에서 도출되는 키」

Microsoft 문서는 EK를 RSA 키 쌍으로 설명하지만², 이는 TPM 1.2 시절부터의 서술입니다. TPM 2.0에서 제조 시 칩에 쓰이는 불변의 비밀은, 정확히는 endorsement primary seed라는 시드이고, EK는 이 시드에서 정해진 절차(템플릿)로 도출됩니다. 같은 시드에서 도출하면 반드시 같은 키가 되므로, EK는 다시 만들어도 사실상 그 TPM 고유의 키로 남습니다. RSA와 ECC 어느 쪽 EK도 도출할 수 있고, 실기에 둘 다 준비되어 있는 일도 드물지 않습니다. 본론을 이해하는 데 필요 없는 이야기이므로, 건너뛰어도 됩니다.

다만 EK를 그대로 외부에 보이면 PC를 유일하게 식별할 수 있어 프라이버시 문제가 됩니다. 그래서 실제 시나리오에서는 AIK(Attestation Identity Key / 증명용 키)를 사용합니다. 인증 기관이 EK와 그 인증서를 써서 「이 AIK는 진짜 TPM 안에 존재한다」는 것을 증명하고, AIK 인증서를 발행합니다. 상대마다 다른 AIK를 쓸 수 있으므로, 여러 검증자가 공모해 같은 단말을 추적하는 것을 막을 수 있습니다.³

SRK(Storage Root Key / 스토리지 루트 키)는 다른 키를 감싸는(wrap하는) 부모 키입니다. TPM은 만든 키를 암호화해 밖으로 내보낼 수 있고, 그 키는 그 TPM에서만 복호화할 수 있습니다. 이 처리를 「wrap」 또는 「bind」라고 부릅니다.² 즉 TPM 안의 기억 영역은 작아도, 외부 스토리지에 암호화해 두면 실질적으로 키를 얼마든지 가질 수 있다는 뜻입니다.

PCR(Platform Configuration Register)은 부팅 시 측정값을 쌓는 특수 레지스터입니다. 0번부터 23번까지 있고, 각각 무엇을 측정하는지가 정해져 있습니다.⁹ 중요한 성질은 임의의 값을 직접 쓸 수 없고, Extend라는 조작으로만 값을 진행할 수 있다는 점입니다. Extend는 「현재 값과 새 측정값을 이어 붙여 해시를 취한 결과를 새 값으로 한다」는 단방향 조작이므로, 「도중에 불편한 기록만 지운다」는 것이 원리적으로 불가능합니다. 값은 재시작으로 리셋됩니다.³

참고로 TPM 2.0에는 리셋 가능 속성을 가진 PCR도 있습니다(DRTM이나 애플리케이션 용도). 다만 BitLocker가 봉인에 쓰는 PCR(0·2·4·7·11)은 정적 측정 부팅용 PCR이라, 재시작까지 리셋할 수 없습니다. 이 기사의 설명은 이쪽을 전제로 합니다.

NVRAM은 비휘발의 작은 영역으로, 인증서 등을 유지하는 데 쓰입니다. TPM 2.0은 TPM 1.2에 비해 알고리즘, 암호, 계층, 루트 키, 인가, NVRAM의 각 면에서 개선되어 있습니다.⁶

4. 측정 부팅과 PCR ── 왜 「부팅이 바뀌면 열리지 않는가」

TPM의 또 하나의 기둥이 측정 부팅(Measured Boot)입니다. 여기가 BitLocker 동작을 이해하는 열쇠입니다.

4.1. 애초에 「측정」이란 무엇을 하는가

앞으로 나아가기 전에 「측정」이라는 말을 구체적으로 잡아 둡니다. 여기서의 측정은 무게나 온도 같은 물리량을 재는 것이 아닙니다. 다음에 실행할 프로그램이나 설정 데이터의 바이트열 전체에서 해시값을 계산하는 것입니다. 해시값은 「내용의 지문」 같은 고정 길이 값이며, 다음 성질을 가집니다.

• 같은 내용에서는, 언제 누가 계산해도 반드시 같은 값이 나온다
• 내용이 1바이트라도 다르면, 전혀 다른 값이 된다
• 값에서 원래 내용을 복원하는 것은 실질적으로 불가능하다

예를 들어 SHA-256 해시로 계산하면, abc는

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

이 되고, 마지막 한 글자만 다른 abd는

a52d159f262b2c6ddb724a61840befc36eb30c88877a4030b65cbe86298449c9

이 됩니다. 한 글자 차이여도 값은 전면적으로 바뀌고, 두 값을 견줘 봐도 「비슷한 내용이었다」는 단서조차 남지 않습니다. PowerShell의 Get-FileHash로 임의의 파일 SHA-256을 계산할 수 있으므로, 이 「지문」의 감각은 손에서도 시험해 볼 수 있습니다.

즉 「부팅 측정값」이란, 부팅 과정에서 실행되는 펌웨어·부트 로더·설정 각각의 해시값입니다. 측정값이 이전과 모두 같다면 「부팅에 관여한 소프트웨어와 구성은 이전과 전혀 같았다」고 단언할 수 있습니다. 반대로 부트 로더가 변조되었거나, 다른 OS에서 부팅되면, 대응하는 측정값은 반드시 바뀝니다. 이것이 측정 부팅의 토대입니다.

4.2. 측정의 연쇄 ── 읽어 들일 것을, 실행하기 전에 잰다

구조는 단순합니다. 시스템 펌웨어 안에는 CRTM(Core Root of Trust for Measurement)이라는, 무조건 신뢰되는 기점이 있습니다. CRTM은 다음에 실행할 소프트웨어 컴포넌트를 무조건 해시화하고, 그 측정값을 TPM에 기록합니다. 이후 컴포넌트도 같은 일을 반복합니다──읽어 들일 것을, 실행하기 전에 재는 것입니다. 실행 전에 측정값이 보내지므로, 어떤 컴포넌트가 자기 측정값을 TPM에서 지울 수는 없습니다.³

sequenceDiagram
    autonumber
    participant FW as UEFI 펌웨어 CRTM
    participant BM as Windows 부트 매니저
    participant OS as Windows 커널
    participant T as TPM

    FW->>T: 다음에 실행할 코드의 해시를 Extend
    Note over T: PCR 0 / 2 / 4 / 7 이 갱신된다
    FW->>BM: 제어를 넘긴다
    BM->>T: 봉인된 BitLocker 키의 해제를 요청
    alt PCR 이 봉인 때와 같은 값
        T-->>BM: 키를 돌려준다
        BM->>BM: OS 볼륨을 복호화한다
        BM->>T: 커널·ELAM·부트 드라이버를 Extend
        Note over BM,T: 실행 전에 잰 뒤 제어를 넘긴다
        BM->>OS: 제어를 넘겨 Windows를 시작한다
    else PCR 이 다른 값
        T-->>BM: 키를 돌려주지 않는다
        BM->>BM: 복구 키 입력 화면으로
    end

그림 3: 측정 부팅과 BitLocker 키 해제의 흐름

그림에서 「복호화한 뒤에 커널을 잰다」는 순서가 되는 것은, 측정 부팅의 원칙대로 읽어 들일 것은 실행 전에 재기 때문입니다. Windows 부트 로더가 커널의 디지털 서명을 검증한 뒤에 읽어 들이고, 커널이 다시 부트 드라이버·시작 파일·ELAM을 검증하는 연쇄입니다.¹⁰ 커널이 기동한 뒤에 자기를 재는 방식이면, 측정을 생략할 수 있어 의미가 없습니다.

BitLocker는 이 측정값이 기대한 값일 때만 쓸 수 있는 키를 TPM 안에 만듭니다. 기대값은 시스템 디스크의 OS 볼륨에서 Windows 부트 매니저가 동작하는 시점의 것으로 계산됩니다. 다른 OS로 부팅되거나 구성이 바뀌면 TPM 안의 측정값이 바뀌고, TPM은 키 사용을 허용하지 않으며, 암호화된 OS 볼륨은 복호화할 수 없습니다.³

그렇다면 실제로 어느 PCR을 보고 있을까요. 네이티브 UEFI 구성에서의 기본 플랫폼 검증 프로필은 다음과 같습니다.⁹

기본값에서는 PCR 0·2·4·11이 봉인 대상입니다. 다만 보안 부팅 상태(PCR 7)가 지원되는 경우에는 PCR 7과 PCR 11로 봉인됩니다.⁹ 이는 중요한 차이입니다. PCR 0/2/4는 펌웨어나 부트 매니저 이미지 자체의 해시이므로, 펌웨어를 업데이트할 때마다 값이 바뀌어 복구 모드로 떨어집니다. 한편 PCR 7은 「보안 부팅이 유효한지, 어떤 키를 신뢰하는지」를 재므로, 서명자가 같으면 이미지가 갱신되어도 값이 바뀌지 않습니다. Microsoft도 PCR 7에 묶으면 펌웨어 업데이트나 이미지 업데이트로 복구 모드에 들어갈 가능성이 줄어든다고 설명합니다.⁹

PCR 11의 쓰임은 조금 달라, 재미있는 장치입니다. 상정하는 것은 공격자가 피해자 단말은 그대로(하드웨어와 펌웨어를 유지한 채) OS 디스크만 자기가 준비한 것으로 바꿔 끼우는 공격입니다. 키는 원래 TPM에 봉인되어 있으므로 단말째 바꿔도 의미가 없고, 피해자의 TPM을 계속 쓰는 것이 포인트입니다. 공격자는 피해자 OS 파티션의 메타데이터에서 봉인된 BitLocker 키 blob을 꺼내, 자기 지배하의 OS를 기동한 뒤 TPM API를 호출해 그 키 blob의 해제(unseal)를 시도합니다.

이것이 성립하지 않는 이유는, Windows가 키를 봉인할 때 PCR 11의 값을 0으로 봉인하고, 부트 매니저가 다음 부트 로더(정규든 부정한 것이든)로 제어를 넘길 때 반드시 PCR 11을 1로 바꾸기 때문입니다. 공격자의 OS가 동작하는 시점에 부트 매니저는 이미 제어를 놓았고, PCR 11은 분명히 0이 아닙니다. 따라서 같은 단말·같은 TPM 위에서도, 부트 매니저보다 뒤 단계에서 키를 요구할 수는 없습니다.¹¹

참고로 보안 부팅 자체도 BitLocker 방어의 일부입니다. 기본값으로 BitLocker는 PCR 7의 측정으로 보안 부팅의 무결성 보호를 이용하고, 허가되지 않은 EFI 펌웨어·EFI 부트 애플리케이션·부트 로더가 기동해 BitLocker 키를 취득하는 것을 막습니다.¹¹

5. dTPM·fTPM·Pluton ── 구현 형태의 차이

「TPM 칩」이라는 말이 퍼진 탓에 TPM은 반드시 독립된 부품이라고 생각하기 쉽지만, 구현은 3종류입니다.⁶

flowchart LR
    C1["CPU"] ---|"LPC / SPI 버스"| T1["전용 TPM 칩<br/>= discrete dTPM"]
    C2["CPU / 칩셋<br/>패키지"] --> T2["같은 패키지 안의 전용 하드웨어<br/>논리적으로는 분리<br/>= 통합 integrated"]
    C3["범용 CPU"] --> T3["신뢰 실행 환경 TEE 위에서 동작하는<br/>펌웨어 구현<br/>= 펌웨어 fTPM"]
    C4["SoC"] --> T4["Microsoft 설계의<br/>보안 프로세서<br/>= Pluton"]

그림 4: TPM의 3가지 구현 형태와, 그 연장에 있는 Pluton

• discrete TPM(dTPM)은 독립된 반도체 패키지의 전용 칩입니다. 메인보드에 실장되며, OEM이 시스템 본체와 별도로 평가·인증할 수 있다는 이점이 있습니다.⁶
• 통합 TPM은 다른 컴포넌트와 같은 패키지에 들어가면서도, 논리적으로는 분리된 전용 하드웨어로 구현됩니다.⁶
• firmware TPM(fTPM)은 범용 연산 유닛의 신뢰 실행 환경(TEE)에서 TPM을 펌웨어로 돌립니다.⁶ 소형·저소비 전력 디바이스에서 전용 칩이 현실적이지 않은 경우에 맞습니다.

Windows는 호환되는 TPM이면 모두 같이 사용합니다. Microsoft는 TPM을 어떤 방식으로 구현해야 하는지에 대해 입장을 취하지 않으며, 폭넓은 생태계가 모든 요구에 응한다고 합니다.⁶ 즉 「fTPM이라서 한 급 아래」라는 것은 없습니다.

그 위에서 Microsoft Pluton은 통합 형태를 더 밀어 간 것입니다. Microsoft가 설계하고 실리콘 파트너가 제조하는, CPU에 내장된 보안 암호 프로세서로, TPM 기능을 제공하면서 TPM 2.0 사양 범위를 넘는 보안 기능도 제공하는 것을 목표로 설계되어 있습니다.¹² 2026년 시점에서 Pluton을 쓸 수 있는 것은 Windows 11이 동작하는 다음 칩셋 탑재기입니다.¹²

• AMD: Ryzen 6000 / 7000 / 8000 / 9000 시리즈, Ryzen AI 시리즈
• Intel: Core Ultra 200V 시리즈, Core Ultra Series 3 및 Series 3 프로세서
• Qualcomm: Snapdragon 8cx Gen 3, Snapdragon X 시리즈

운용 면에서 Pluton이 가진 특징은 펌웨어 업데이트 경로가 2계통이라는 점입니다. 종래대로 UEFI 캡슐 업데이트로 메인보드 SPI 플래시 위의 펌웨어를 갱신할 수 있는 외에, OS 업데이트를 통해 새 Pluton 펌웨어를 동적으로 읽어 들일 수 있습니다. 시스템 부팅 시에는 SPI 플래시 위의 펌웨어로 초기화되고, Windows 기동 중에(있으면) Windows Update 경유로 가져온 최신판이 읽어 들여지는 흐름입니다.¹² TPM 펌웨어 취약점이 발견되었을 때 PC 제조사의 BIOS 업데이트 제공을 기다리지 않고 배포될 가능성이 있다는 것은, 실무상 반가운 성질입니다.

6. TPM 1.2와 2.0의 차이, 그리고 Windows 11 요건

오래된 PC를 다루다 보면 아직 TPM 1.2를 만날 때가 있습니다. 둘의 차는 「버전이 올라갔다」는 것 이상입니다.⁶

특히 문제가 되는 것은 SHA-1입니다. NIST는 2014년 시점에서 많은 연방 기관에 SHA-256으로의 이전을 요구했고, Microsoft와 Google도 2017년에 SHA-1 기반 서명·인증서 지원을 폐지했습니다. TPM 1.2 사양은 SHA-1만 쓸 수 있어, 이 흐름을 따라갈 수 없습니다.⁶

그리고 Windows 11입니다. 최소 요건은 호환성 목록에 오른 64bit CPU, 메모리 4GB, 스토리지 64GB, DirectX 12 이상에 대응하고 WDDM 2.0 드라이버를 가진 그래픽, 720p 이상에 9인치 초과·8비트/채널 디스플레이, 「UEFI, 보안 부팅 대응(Secure Boot capable)」시스템 펌웨어, 그리고 TPM 2.0입니다.⁴

여기는 정확히 읽으세요. 최소 요건이 요구하는 것은 보안 부팅에 대응하고 있을 것이지, 켜져 있을 것은 아닙니다.⁴ 꺼진 채로도 요건 자체는 충족할 수 있으므로, Windows 11로 올리기 위해서만 UEFI 설정을 만질 필요는 없습니다. 다만 보안 부팅을 켜고, 플랫폼이 PCR 7 바인딩 요건을 충족하면 BitLocker가 PCR 7에 묶여 복구 모드에 떨어지기 어려워집니다(4장). 켜기만 해서 자동으로 그렇게 되는 것은 아니므로, 실제로 어느 PCR에 묶여 있는지는 manage-bde -protectors -get C:의 PCR 검증 프로필로 확인하세요. 요건 때문이 아니라, 이 실익 때문에 켜는 것이 올바른 정리입니다.

또 하나 놓치기 쉬운 것이, TPM 2.0은 레거시 모드나 CSM(Compatibility Support Module) 모드 BIOS에서는 지원되지 않는다는 점입니다. TPM 2.0 탑재 디바이스는 BIOS 모드를 「네이티브 UEFI만」으로 구성해야 하고, 레거시/CSM 옵션은 무효화해야 합니다.⁶

이는 실무에서 골치 아픈 상황을 만듭니다. 레거시 모드로 설치된 OS는 BIOS 모드를 UEFI로 바꾸면 기동하지 않기 때문입니다. BIOS 모드를 바꾸기 전에 MBR2GPT 도구로 OS와 디스크를 UEFI 대응 상태로 만들어 두어야 합니다.⁶ 「TPM은 달려 있는데 Windows 11로 올릴 수 없다」는 기기는 이 상태인 일이 적지 않습니다. Windows 10에서의 전환 판단 전체상은 「Windows 10 지원 종료 후의 현실적 해법 ── ESU·LTSC·교체 판단표」에 정리해 두었습니다.

참고로 디바이스 상태 증명(Device Health Attestation)에 대해서도, Windows가 지원하는 것은 TPM 2.0이며, TPM 2.0을 실어도 레거시 BIOS 디바이스에서는 기대대로 동작하지 않습니다.¹

6.1. 예외 ── Windows 11 IoT Enterprise에서는 TPM은 선택

여기까지의 「Windows 11이면 TPM 2.0 필수」는 일반 PC용 에디션 이야기입니다. Windows 11 IoT Enterprise에는 전용기용으로 완화된 최소 요건이 따로 정의되어 있고, IoT Enterprise LTSC(및 비LTSC의 24H2 이후)에서는 TPM도 보안 부팅도 선택(Optional)입니다.⁵ 산업용 PC나 장치 임베디드 현장에서는, 이것을 아느냐에 따라 「이 기판에서는 Windows 11을 못 올린다」는 결론이 뒤집힙니다.

공식 요건표는 PREFERRED(권장)와 OPTIONAL(전용기용 최소)의 2열 구성입니다.⁵

주의점이 세 가지 있습니다.

• 「LTSC면 TPM 불필요」가 아닙니다.완화 요건이 정의된 것은 IoT Enterprise이고, Windows 11 Enterprise LTSC(IoT 없음)는 일반 PC용과 같은 취급입니다. 이름이 비슷해 혼동되기 쉽지만, 조달하는 라이선스가 어느 쪽이냐에 따라 결론이 바뀝니다.
• 비LTSC IoT Enterprise는 버전으로 다릅니다.21H2〜23H2의 OPTIONAL 요건에서는 TPM 2.0은 여전히 필수(선택이 된 것은 보안 부팅뿐)이고, TPM이 선택이 되는 것은 24H2 이후입니다.⁵
• 프로세서 요건은 따로입니다.TPM과 보안 부팅이 선택이어도, 대응 프로세서 목록은 별도로 정의되어 있으므로 그쪽은 반드시 확인하세요.⁵

그리고 Microsoft 자신이 완화 요건을 고르는 의미에 쐐기를 박습니다. 엔드 유저가 나중에 소프트웨어를 추가할 수 있는 디바이스에서 요건을 낮출 때는 신중히 검토해야 하고, TPM을 싣지 않는 것은 엔드 유저가 필요로 하는 소프트웨어에 영향을 줄 수 있다는 취지입니다.⁵ TPM이 없으면 BitLocker는 키를 부팅 상태에 봉인할 수 없고, Windows Hello 키도 소프트웨어 보호로 떨어집니다. 「요건을 맞추려고 싣는」 것이 아니라 「그 단말에 필요한 보호를 얻으려고 싣는」 판단으로 바꾸세요.

IoT Enterprise / LTSC 고르는 법과 라이선스 조달 전체상은 「산업용 PC에는 어떤 Windows를 넣어야 하는가 ── Windows IoT Enterprise / LTSC 실천 가이드」에 정리해 두었습니다.

7. Windows의 어디에서 TPM이 쓰이는가

「TPM이 필수입니다」라고 들어도, 그것이 매일의 어느 기능에 실제로 쓰이는지가 안 보이면 납득하기 어렵습니다. 지도를 그려 둡니다.

flowchart LR
    TPM["TPM 2.0"]
    TPM --> BL["BitLocker / 디바이스 암호화<br/>키를 부팅 상태에 봉인한다"]
    TPM --> WH["Windows Hello<br/>PIN이나 생체 정보에 묶인 키를 보호<br/>사전 공격 대책으로 짧은 PIN도 안전"]
    TPM --> CG["Credential Guard<br/>분리 환경의 키를 측정값으로 보호"]
    TPM --> MB["측정 부팅 / 원격 증명<br/>부팅 상태에 서명한 quote를 발행"]
    TPM --> HA["디바이스 상태 증명<br/>MDM 조건부 액세스의 판단 재료"]
    TPM --> PCP["Platform Crypto Provider<br/>인증서 비밀 키를 반출 불가로"]

그림 5: TPM을 토대로 하는 Windows의 주요 보안 기능

BitLocker / 디바이스 암호화. 4장에서 본 그대로입니다. 해제 방식은 TPM만, TPM+PIN, TPM+시작 키, TPM+PIN+시작 키의 4가지이며, TPM만은 편의성이 가장 높은 만큼 추가 인증 요소를 요구하는 방식보다 안전성은 낮다고 정리되어 있습니다.¹¹

참고로 디바이스 암호화(BitLocker를 자동으로 켜는 구조)의 전제 조건은 최근 몇 년 사이에 바뀌었습니다. 예전에는 Modern Standby 또는 HSTI 요건을 충족하고 DMA 접근이 가능한 외부 포트를 갖지 않는 것이 조건이었지만, Windows 11 버전 24H2 이후 이 전제는 철폐되어 더 많은 단말이 대상이 되었습니다.¹³ 옛 해설에 있는 「Modern Standby 대응기가 아니면 쓸 수 없다」는 24H2 이후에는 해당하지 않습니다. 손의 단말이 대상인지는 msinfo32.exe(시스템 정보)의 「디바이스 암호화 지원」에서 확인할 수 있습니다.¹³

Windows Hello / Windows Hello for Business. 디바이스마다 프로비저닝된 키와 PIN이나 생체 정보를 조합해 인증합니다. TPM이 있으면 키는 TPM이 보호하고, 없으면 소프트웨어로 보호합니다. 생체 정보는 프로비저닝된 키에 접근하기 위해서만 그 단말 위에서 쓰이며, 단말 간에 공유되지 않습니다.³ TPM이 있는 단말에서는 키를 다른 곳으로 복사할 수 없으므로, 인증 정보가 새어도 다른 단말에서는 쓸 수 없다는 성질을 얻습니다.

Credential Guard. 자격 증명 해시 처리를 커널에서 접근할 수 없는 분리 메모리 영역에서 수행하는 기능입니다. 이 분리 영역은 부팅 프로세스 중에 초기화·보호되고, Credential Guard는 TPM을 써서 그 키를 측정값으로 보호합니다. 키는 「분리 영역이 초기화되는 부팅 프로세스 단계」에서만 접근 가능하고, 보통 커널에서는 이용할 수 없습니다.³

측정 부팅과 원격 증명. AIK를 써서 TPM은 현재 측정값 상태에 암호 서명한 문(quote)을 생성할 수 있습니다. 이것을 원격으로 보내 「어떤 소프트웨어와 구성으로 부팅하고 OS를 초기화했는지」를 증명할 수 있습니다.³ 측정은 Windows의 초기 상태에서 멈추므로, 어떤 앱을 쓰고 있는지 같은 프라이버시 정보는 포함되지 않습니다.³

디바이스 상태 증명. Microsoft의 상태 증명 서비스가 여러 제조사의 TPM을 대상으로 AIK 인증서를 발행하고, 측정 부팅 정보를 분석해 「BitLocker가 켜져 있는가」「보안 부팅이 켜져 있는가」「DEP가 유효한가」 같은 단순한 진술로 변환합니다. MDM(Intune 등)은 복잡한 quote를 스스로 분석하지 않고 이 진술을 써서 단말을 격리하거나 클라우드 서비스 접근을 멈출 수 있습니다.¹³

Platform Crypto Provider. 인증서의 비밀 키를 TPM으로 보호합니다. 인증서 템플릿에서 「TPM의 Platform Crypto Provider를 쓴다」고 지정할 수 있고, 내보내기 불가로 설정된 인증서의 비밀 키는 TPM에서 꺼낼 수 없습니다. PIN을 요구하는 인증서라면 TPM의 사전 공격 대책이 자동으로 적용됩니다.³ 이것이 10장에서 다루는 개발자 시점의 입구입니다.

가상 스마트 카드. TPM을 「항상 꽂혀 있는 스마트 카드」처럼 동작시키는 기능으로, 물리 카드와 리더의 구매·배포 비용을 없앱니다.³ 다만 Microsoft는 현재 가상 스마트 카드 이용자에게 Windows Hello for Business나 FIDO2 보안 키로의 이전을 권장합니다.² 기존 자산으로는 남아 있지만, 앞으로 설계한다면 고르지 않는 방향입니다.

8. 자기 PC의 TPM을 확인한다

여기서부터는 손을 움직이는 이야기입니다. 먼저 잡아 둘 것은 Windows 10/11은 TPM을 자동으로 초기화해 소유권을 취득한다는 점입니다. 따라서 TPM 관리 콘솔(tpm.msc)에서 설정을 만질 필요는 보통 없고, Microsoft도 「대부분의 경우 tpm.msc에서의 구성은 피할 것을 권장한다」고 합니다. 예외는 PC 초기화나 클린 설치와 관련된 장면 정도입니다.¹ 참고로 TPM 관리 콘솔은 Windows Server 2019 / Windows 10 버전 1809 이후 적극적 개발이 종료되었습니다.¹

8.1. GUI로 본다

• Win + R → tpm.msc로 TPM 관리 콘솔이 열립니다. TPM 유무, 상태, 사양 버전, 제조사를 알 수 있습니다. 화면은 「상태」란(쓸 수 있는 상태인지)과 「TPM 제조업체 정보」란(제조업체 이름·제조업체 버전·사양 버전)으로 나뉘며, 사양 버전이 2.0인지가 Windows 11 TPM 요건의 판단 재료입니다. TPM이 없거나 비활성인 단말에서는 호환되는 TPM을 찾을 수 없다는 취지의 표시가 됩니다(그 경우의 확인 순서는 8.4절).
• Windows 보안의 디바이스 보안 → 보안 프로세서 세부 정보에서도 같은 정보를 볼 수 있습니다. 이 화면에서 보안 프로세서 문제 해결 → TPM 지우기로 진행할 수 있습니다(9장에서 다루지만, 가볍게 누르면 안 됩니다).⁷

8.2. PowerShell로 본다

여러 대를 조사한다면 PowerShell이 확실합니다. TrustedPlatformModule 모듈에 한 벌의 cmdlet이 있습니다.¹⁴

# TPM의 상태를 모아 확인한다(관리자 권한으로 실행)
Get-Tpm

출력은 다음 같은 형태입니다.¹⁵

TpmPresent                : True
TpmReady                  : True
TpmEnabled                : True
TpmActivated              : True
TpmOwned                  : True
ManufacturerIdTxt         : INTC
ManufacturerVersion       : 402.1.0.0
ManagedAuthLevel          : Full
OwnerClearDisabled        : False
AutoProvisioning          : Enabled
LockedOut                 : False
LockoutHealTime           : 10 minutes
LockoutCount              : 0
LockoutMax                : 31

읽는 포인트는 다음과 같습니다.¹⁵

• TpmPresent: TPM이 존재하는가. 여기가 False면 하드웨어나 UEFI 설정 문제입니다.
• TpmReady: Windows가 쓸 수 있는 상태인가. TpmPresent가 True여도 TpmReady가 False면 초기화나 소유권 취득에서 막힌 것입니다.
• LockedOut / LockoutCount / LockoutMax / LockoutHealTime: 사전 공격 대책의 상태입니다. LockedOut이 True면 PIN 입력 실수 등으로 일시적으로 잠긴 것입니다.
• OwnerClearDisabled: True이면 OS에서 소유자 인증값에 의한 리셋(지우기)을 할 수 없습니다.
• AutoProvisioning: Windows에 의한 자동 프로비저닝의 유효/무효입니다.

사양 버전이 2.0인지를 기계적으로 판정하고 싶다면 WMI에서 보는 것이 손쉽습니다.

# 사양 버전·제조사·유효 상태를 가져온다
Get-CimInstance -Namespace 'root/CIMv2/Security/MicrosoftTpm' -ClassName Win32_Tpm |
    Select-Object SpecVersion, ManufacturerId, ManufacturerVersion,
                  IsEnabled_InitialValue, IsActivated_InitialValue, IsOwned_InitialValue

여기서 주의할 것이 ManufacturerId입니다. Get-Tpm이 돌려주는 ManufacturerIdTxt(INTC 같은 문자열)는 Get-Tpm 쪽에만 있는 속성이고, Win32_Tpm 클래스에는 없습니다.¹⁶ 무심코 Select-Object ManufacturerIdTxt라고 쓰면 그 열은 조용히 비게 됩니다.

Win32_Tpm에 있는 것은 uint32의 ManufacturerId이고, 각 바이트를 ASCII 문자로 해석하면 문자열이 됩니다(예: 1414548736 → 0x54 0x50 0x4D 0x00 → TPM).¹⁶ 문자열이 필요하면 다음처럼 스스로 디코드하거나, 그냥 Get-Tpm을 쓰세요.

# ManufacturerId(uint32)를 ASCII 문자열로 바꿔 목록으로 만든다
Get-CimInstance -Namespace 'root/CIMv2/Security/MicrosoftTpm' -ClassName Win32_Tpm |
    Select-Object SpecVersion, ManufacturerVersion,
        @{ Name = 'ManufacturerText'; Expression = {
            $bytes = [System.BitConverter]::GetBytes([uint32]$_.ManufacturerId)
            # uint32를 상위 바이트부터 읽는다(예: 1229870147 → 0x49 0x4E 0x54 0x43 → INTC)
            if ([System.BitConverter]::IsLittleEndian) { [array]::Reverse($bytes) }
            -join ($bytes | Where-Object { $_ -ne 0 } | ForEach-Object { [char]$_ })
        } }

SpecVersion은 2.0, 0, 1.16처럼 「사양 버전, 리비전, 에라타」 형태로 돌아옵니다.¹⁶ 선두가 2.0인지를 보면 Windows 11 TPM 요건을 충족하는지의 판정에 쓸 수 있습니다(CPU·메모리·스토리지 등 다른 요건은 별도 확인이 필요합니다. 11장 참조). 여러 대에 대해 원격으로 실행하는 방법은 「PowerShell Remoting(WinRM) 입문」을 참조하세요.

그 외에 Get-TpmEndorsementKeyInfo로 EK와 인증서 정보를, Get-TpmSupportedFeature로 특정 기능의 지원 상황을 확인할 수 있습니다. lockout 해제는 Unblock-Tpm, TPM 리셋은 Clear-Tpm입니다.¹⁴

8.3. 명령줄 도구로 본다

tpmtool은 TPM 정보 취득과 진단에 쓰는 표준 도구입니다.¹⁷

:: TPM의 기본 정보를 표시한다
tpmtool getdeviceinformation

:: TPM 로그를 수집해 현재 디렉터리에 둔다
tpmtool gatherlogs

BitLocker 상태와 함께 보려면 manage-bde -status나 Get-BitLockerVolume을 병용합니다. 이벤트 로그 쪽 조사 절차는 「Get-WinEvent로 이벤트 로그를 실무적으로 조사한다」에 정리해 두었습니다.

8.4. 「TPM 2.0인데도 쓸 수 없다」일 때의 확인 순서

확인만으로는 앞으로 나아가지 못하므로, 결과별 다음 수까지 이어 둡니다. 판단의 기점은 Get-Tpm의 TpmPresent와 TpmReady입니다.

UEFI 설정을 볼 때의 확인 포인트는 다음과 같습니다. 많은 기종에서 펌웨어 TPM은 기본값으로 꺼져 있으며, 켜기만 해도 해결됩니다.

• 항목 이름이 제조사마다 다릅니다.Intel 계열 플랫폼에서는 PTT(Platform Trust Technology), AMD 계열에서는 fTPM(AMD fTPM / AMD CPU fTPM 등)으로 표기되는 일이 많고, TPM이라는 말이 화면에 나오지 않는 기종이 있습니다. 「TPM 항목이 없으니 미탑재」라고 판단하지 마세요.
• 위치는 Security 또는 Advanced 아래가 일반적입니다. Trusted Computing, PCH-FW Configuration 같은 제목 아래에 있는 일도 있습니다.
• 전용 칩(dTPM)과 펌웨어 TPM의 전환 설정을 가진 기종이 있습니다.이 경우는 9.2절의 「여러 TPM을 전환하면 BitLocker가 복구 모드로 들어간다」에 해당하므로, 한 번 정하면 바꾸지 마세요.⁷
• 레거시/CSM 모드가 켜져 있지 않은가.TPM 2.0은 CSM 모드에서 동작하지 않습니다. 여기가 원인이면 UEFI로 바꾸기 전에 MBR2GPT가 필요합니다(6장).⁶
• UEFI 쪽에서 TPM을 켰다면 BitLocker 일시 중단을 잊지 마세요.측정값의 전제가 바뀌는 조작이므로, 9장 맨 앞의 인과표와 같은 취급입니다.

9. 실무의 문제 ── 복구 키 화면·TPM 지우기·lockout

현장에서 TPM이 화제가 되는 것은 대개 무언가 잘 안 될 때입니다. 흔한 세 가지를 다룹니다.

그 전에, 이 기사 서두에서 든 질문──「왜 BIOS만 업데이트해도 BitLocker 복구 키를 묻는가」──에 대한 직접 답을, 인과표로 먼저 둡니다. 「어떤 조작이 어떤 PCR을 바꾸고, 결과 어떻게 되는가」의 대응입니다.⁹¹¹⁷

이 표의 요점은, 위 5행과 맨 아래 행이 전혀 다른 사건이라는 것입니다.위 5행은 「키는 있지만 측정값이 맞지 않는」 상태이고, 복구 키로 통과하면 원래대로 돌아갑니다. 맨 아래 행은 「키 자체가 수중에 없는」 상태이고, 복구 키가 없으면 복구할 수 없습니다.

OS 디스크 이전이 맨 아래 행에 들어가는 것은, 봉인한 키가 원래 PC의 TPM 안에 있기 때문입니다. 디스크를 다른 PC에 꽂아도 키는 따라오지 않습니다. 디스크만 교체할 생각이어도, 실질은 메인보드 교체와 같은 취급이 됩니다. 이전 예정이 있다면 작업 전에 BitLocker를 일시 중단하거나, 복구 키를 수중에 준비하세요.

9.1. BitLocker 복구 키를 요구받았다

가장 많은 상담입니다. 원인 분리는 실은 단순합니다.

flowchart TD
    S["부팅 때 복구 키 화면이 나왔다"] --> Q1{"직전에 무언가를 바꿨는가"}
    Q1 -->|"UEFI/BIOS를 업데이트했다"| A1["PCR 0 등의 측정값이 바뀌었다<br/>다음부터는 다시 봉인되므로<br/>복구 키로 잠금을 풀고 계속"]
    Q1 -->|"보안 부팅 설정을 바꿨다<br/>CSM을 켰다"| A2["PCR 7의 측정값이 바뀌었다<br/>설정을 되돌리거나 복구 키로 잠금을 푼다"]
    Q1 -->|"TPM을 지웠다<br/>메인보드를 교체했다"| A3["봉인한 키 자체가 사라졌다<br/>사전에 BitLocker를 일시 중단하지 않았으면<br/>복구 키가 유일한 수단"]
    Q1 -->|"USB에서 다른 OS를 부팅했다<br/>부팅 순서를 바꿨다"| A4["부팅 구성의 측정값이 바뀌었다<br/>되돌리고 다시 시작한다"]
    Q1 -->|"짐작이 없다"| A5["공격을 포함해 조사<br/>로그 수집 후 복구 키로 잠금을 푼다"]
    A1 --> R["복구 키 보관 위치를 확인<br/>AD DS / Entra ID / Microsoft 계정"]
    A2 --> R
    A3 --> R
    A4 --> R
    A5 --> R

그림 6: BitLocker 복구 키를 요구받았을 때의 원인 분리

펌웨어 업데이트는 복구 모드의 단골 방아쇠입니다. Microsoft도 PCR 0을 포함하는 프로필을 설정한 경우에는 펌웨어 업데이트 전에 BitLocker를 일시 중단하라고 안내합니다.⁹ 거꾸로 말하면, 보안 부팅이 올바르게 구성되고 PCR 7에 묶인 단말에서는 펌웨어 업데이트로 복구 모드에 떨어지는 빈도가 낮아집니다.⁹ Modern Standby 대응기에서는 PCR 7 측정이 로고 요건이며, TPM과 보안 부팅이 올바르게 구성되어 있으면 기본값으로 PCR 7과 PCR 11에 묶입니다.⁹

운용으로서의 결론은 단순합니다. UEFI 업데이트·보안 부팅 설정 변경·TPM 지우기·메인보드 교체 전에는 반드시 BitLocker를 일시 중단한다.그리고 그 전에 복구 키 보관 위치(Active Directory Domain Services, Microsoft Entra ID, 개인이라면 Microsoft 계정)를 확인해 두는 것입니다. 조직에서는 BitLocker를 구성해 복구 키를 AD DS에 보관할 수 있습니다.³

일시 중단을 끼웠는지에 따라 그 뒤의 수고는 전혀 달라집니다. BitLocker를 일시 중단하면 클리어 키 보호 기능이 볼륨에 남으므로, TPM을 지워도 새 TPM으로 교체해도 복구 키를 입력하지 않고 그대로 기동할 수 있습니다(기동 후 보호를 재개하면 새 TPM에 대해 다시 봉인됩니다). 그림 6에서 「복구 키가 유일한 수단」이라고 한 것은, 일시 중단하지 않고 지우기·교체해 버린 경우의 이야기입니다. 거꾸로 말하면, 사전 준비를 하나 넣기만 해도 이 분기는 피할 수 있습니다.

9.2. TPM을 지우고 싶다 / 지워 버렸다

TPM 지우기는 데이터 손실을 초래합니다.공식 문서의 경고는 명확합니다. 지우면 TPM에 묶여 만들어진 키와, 그 키로 보호된 데이터(가상 스마트 카드나 로그인 PIN 등)가 모두 사라집니다. TPM으로 보호·암호화하고 있는 데이터에 대해 백업과 복구 수단을 반드시 마련하세요.⁷

더해, 실무에서 중요한 주의점이 세 가지 있습니다.⁷

• 자기 소유물이 아닌 단말(회사나 학교 PC)의 TPM을, 관리자 지시 없이 지우지 않는다.
• 지우기는 반드시 OS 기능(tpm.msc나 Windows 보안)에서 하고, UEFI에서 직접 지우지 않는다.
• 일시적으로 TPM 동작만 멈추고 싶다면, 지우기가 아니라 「TPM 끄기」를 쓴다.

지운 뒤 Windows는 자동으로 TPM을 다시 초기화해 소유권을 다시 취득합니다.⁷

여기서 강조하고 싶은 것은, TPM 지우기는 데이터 삭제(sanitize)가 아니다는 점입니다. 지우기로 사라지는 것은 TPM 안의 키이고, 디스크 위의 데이터 자체는 1바이트도 지워지지 않습니다. BitLocker 복구 키는 AD DS나 Microsoft Entra ID, Microsoft 계정에 보관되어 있는 것이 보통이므로, 그것을 가진 사람은 TPM을 지운 뒤에도 볼륨을 복호화할 수 있습니다.

단말을 제3자에게 넘길 때의 본체는, Windows의 「이 PC를 초기 상태로 되돌리기(데이터도 삭제)」, 전용 삭제 도구, 암호화 삭제, 물리 파괴 같은 스토리지 삭제 절차입니다. TPM 지우기는 그 마무리에 지나지 않습니다. 폐기·양도 절차 전체는 「Windows PC의 폐기·양도 체크리스트」에 정리해 두었습니다.

또 하나, 의외로 알려지지 않은 함정이 있습니다. 일부 시스템에는 여러 TPM이 달려 UEFI에서 전환할 수 있지만, Windows는 이 구성을 지원하지 않습니다. TPM을 전환하면 Windows가 새 TPM을 올바르게 검출하지 못하는 일이 있고, BitLocker는 복구 모드로 들어갑니다. 전환한다면 전환한 뒤에 지우고, Windows를 다시 설치해야 합니다. Microsoft는 TPM이 두 개인 시스템에서는 한쪽을 고르면 바꾸지 말 것을 강하게 권장합니다.⁷

9.3. TPM이 lockout되었다

PIN 입력 실수가 이어지면 TPM이 lockout합니다. Windows의 기본 구성에서는 TPM 2.0은 인증 실패 32회면 잠그고, 10분마다 실패 1회분을 잊습니다. 잠긴 상태에서도, 회복 간격 동안 전원을 켠 채로 기다리면 lockout에서 빠져나올 수 있습니다.² 10분은 어디까지나 Windows 기본값이므로, 실제 간격은 그 단말의 Get-Tpm이 돌려주는 LockoutHealTime으로 확인하세요(8장). 허둥지둥 재시작을 반복하는 것보다, 그냥 두는 편이 빠른 일이 있습니다.

즉시 해제하고 싶다면 lockout 리셋 명령을 보냅니다. 여기서 오해하기 쉬운 것이 TPM 소유자 비밀번호입니다. Windows 10 버전 1607 이후, Windows는 TPM 프로비저닝 때 소유자 비밀번호를 유지하지 않습니다(난수의 고엔트로피 값을 설정한 뒤 폐기합니다).¹⁸ 「관리자가 소유자 비밀번호를 가지고 있다」는 전제로 절차를 짜면 현장에서 멈춥니다.

대신 쓰이는 것이 lockout 인가(lockout authorization)입니다. OSManagedAuthLevel의 기본값 5는 TPM 2.0에서 「lockout 인가만 유지한다」는 뜻입니다.¹⁸ 즉 「전체 소유자 비밀번호는 잃었지만, lockout을 해제하기 위한 인가는 남아 있다」가 기본 상태이고, tpm.msc의 lockout 시간 리셋이나 Unblock-Tpm은 보통 이 인가로 동작합니다. 소유자 비밀번호 자체를 남기는 설정(레지스트리에서 OSManagedAuthLevel을 4로)도 있지만, Microsoft는 강하게 비권장합니다.¹⁸

참고로 소유자 비밀번호가 없어도, UEFI에서의 물리적 존재 확인으로 TPM 켜기·끄기·지우기 같은 관리 조작을 하는 경로는 남아 있습니다.¹⁸ 다만 이것은 lockout을 비파괴로 즉시 해제하는 대체 수단이 아닙니다. lockout 인가를 쓸 수 없는 경우에는 시간 경과에 의한 회복(10분마다 1회분)을 기다리는 것이 기본이고, 지우기는 키를 모두 잃는 최종 수단입니다(9.2절).

참고로 인가값을 명시적으로 입력해 리셋하는 구성의 경우, 잘못된 값으로 리셋을 시도하면 TPM은 24시간 리셋 재시도를 허용하지 않습니다.² 닥치는 대로 시도하지 마세요.

참고로 TPM 2.0에서는 인증값 없이 만들 수 있는 키도 있고, 그것들은 TPM이 잠겨 있어도 쓸 수 있습니다. BitLocker의 기본 TPM만 구성은, TPM이 잠겨 있어도 Windows를 기동할 수 있습니다.²

10. 개발자가 보는 TPM ── Platform Crypto Provider와 CNG

자사 앱에서 「라이선스 키를 단말에 묶고 싶다」「서버 연결에 단말 고유 클라이언트 인증서를 쓰고 싶다」「설정 파일의 기밀 값을 이 단말에서만 복호화할 수 있게 하고 싶다」는 요건이 나왔을 때, TPM은 유력한 선택지가 됩니다.

10.1. TBS가 아니라 CNG를 쓴다

Windows에는 저수준 API로 TBS(TPM Base Services)가 있습니다. 애플리케이션을 가로질러 TPM 접근을 집중 관리하는 시스템 서비스로, RPC 경유 API로 제공되며, 호출 측이 지정한 우선순위에 따라 TPM 접근을 협조적으로 스케줄합니다.¹⁹

다만 TBS 문서 자신이 이렇게 적습니다. 「TPM은 키 보관 용도로도 쓸 수 있지만, 개발자에게는 이런 시나리오에서는 키 스토리지 API 사용을 권장한다. 키 스토리지 API는 키 생성·서명·암호화·영속화 기능을 제공하며, TBS보다 고수준이고 다루기 쉽다」.¹⁹ 즉 키만 지키고 싶다면 TBS를 건드릴 이유는 없습니다.

써야 하는 것은 CNG(Cryptography API: Next Generation)의 키 스토리지 공급자 「Microsoft Platform Crypto Provider」입니다. CNG는 암호 공급자와 키 스토리지 공급자를 분리하고 있으며, Platform Crypto Provider는 TPM을 이용하는 KSP로서 비밀 키를 안전하게 보관하고 꺼내지 못하게 합니다.⁸

Platform Crypto Provider가 제공하는, 소프트웨어만의 CNG 공급자로는 실현할 수 없는(또는 동등하게 실현할 수 없는) 특성은 두 가지입니다.³

• 키 보호: TPM 안에 이용 제한이 붙은 키를 만들 수 있다. OS는 키를 시스템 메모리에 복사하지 않고 TPM 안에서 읽어 쓸 수 있다. 반출 불가로 설정할 수 있다. TPM이 만든 키는 그 TPM에만 존재하고, 그 TPM은 키 복사본을 만드는 원천이 되지 않는다.
• 사전 공격 대책: 키에 PIN 등 인증값을 요구할 수 있고, 추측이 너무 많으면 TPM이 일정 시간 거부를 돌려준다.

10.2. C#에서의 쓰는 법

.NET에서는 System.Security.Cryptography의 CNG 계열 클래스로 다룹니다. 먼저 TPM 안에 키를 만들어 반출 불가로 하는 최소형이 이것뿐입니다(.NET 8 / Windows).

using System.Security.Cryptography;

var parameters = new CngKeyCreationParameters
{
    // TPM을 쓰는 키 스토리지 공급자
    Provider = new CngProvider("Microsoft Platform Crypto Provider"),
    // 비밀 키 반출을 일절 허용하지 않는다
    ExportPolicy = CngExportPolicies.None,
};

using var key = CngKey.Create(CngAlgorithm.Rsa, "KomuraSoft.DeviceKey", parameters);
using var rsa = new RSACng(key);

이것으로 비밀 키는 TPM 안에 만들어지고, 프로세스 메모리에는 나타나지 않습니다. 다만 실제 운용에서는 「2회째 이후는 기존 키를 연다」「사용자 단위인가 머신 단위인가」「동시 기동의 경합」을 다뤄야 합니다. 그것을 넣은 것이 다음 코드입니다.

using System;
using System.Security.Cryptography;

const string KeyName = "KomuraSoft.DeviceKey";

// NTE_EXISTS: 「개체가 이미 있습니다」(같은 이름의 키가 이미 있다)
const int NTE_EXISTS = unchecked((int)0x8009000F);

// TPM을 쓰는 키 스토리지 공급자
var provider = new CngProvider("Microsoft Platform Crypto Provider");

// 사용자 단위 키로 할지, 머신 단위(서비스나 작업에서 쓸)로 할지.
// 생성 측과 참조 측에서 반드시 맞춘다 ── 여기가 어긋나면 「만들었을 키가 안 보인다」가 된다.
const bool UseMachineKey = false;
var openOptions = UseMachineKey ? CngKeyOpenOptions.MachineKey : CngKeyOpenOptions.None;
var creationOptions = UseMachineKey
    ? CngKeyCreationOptions.MachineKey   // 생성에는 관리자 권한이 필요
    : CngKeyCreationOptions.None;

CngKey OpenOrCreateKey()
{
    if (CngKey.Exists(KeyName, provider, openOptions))
    {
        // 2회째 이후는 기존 키를 연다(키는 TPM에 영속화되어 있다)
        return CngKey.Open(KeyName, provider, openOptions);
    }

    var creationParameters = new CngKeyCreationParameters
    {
        Provider = provider,
        KeyCreationOptions = creationOptions,
        // 비밀 키 반출을 일절 허용하지 않는다 ── 여기가 TPM을 쓰는 의미의 중심
        ExportPolicy = CngExportPolicies.None,
    };
    creationParameters.Parameters.Add(
        new CngProperty("Length", BitConverter.GetBytes(2048), CngPropertyOptions.None));

    try
    {
        return CngKey.Create(CngAlgorithm.Rsa, KeyName, creationParameters);
    }
    catch (CryptographicException ex) when (ex.HResult == NTE_EXISTS)
    {
        // Exists 와 Create 사이에 다른 프로세스가 같은 이름 키를 만들면, Create 는
        // NTE_EXISTS 로 실패한다. 그 경우만, 이긴 쪽이 만든 키를 다시 연다.
        // 그 외의 실패(TPM을 쓸 수 없음·권한 부족 등)는 그대로 호출 원으로 던진다.
        return CngKey.Open(KeyName, provider, openOptions);
    }
}

using (var key = OpenOrCreateKey())
using (var rsa = new RSACng(key))
{
    byte[] payload = System.Text.Encoding.UTF8.GetBytes("device-attestation-challenge");
    // 서명은 TPM 안에서 이루어진다. 비밀 키는 프로세스 메모리에 나타나지 않는다
    byte[] signature = rsa.SignData(payload, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

ExportPolicy = CngExportPolicies.None이 핵심입니다. 여기를 기본값으로 두면, 애써 TPM을 써도 키를 꺼낼 수 있는 설정이 될 수 있습니다. 「키가 밖으로 나가지 않는다」는 것이 TPM을 쓰는 이유이므로, 명시적으로 반출 불가를 지정하세요.

또 하나의 함정이 사용자 단위 키와 머신 단위 키의 혼동입니다. CngKey.Exists / CngKey.Open의 2인수 판은 사용자 단위 키만 찾습니다. 생성 측만 CngKeyCreationOptions.MachineKey로 바꾸고 참조 측을 그대로 두면, 기존 머신 키를 찾지 못해 매번 「같은 이름으로 다시 만들려다 실패한다」는 깨짐이 됩니다. 위 코드처럼 생성·존재 확인·오픈의 세 곳에서 같은 범위(CngKeyCreationOptions.MachineKey와 CngKeyOpenOptions.MachineKey)를 쓰도록 맞추세요.

OpenOrCreateKey를 함수로 빼 내고 try/catch를 넣은 데도 이유가 있습니다. 「존재를 확인한 뒤 만든다」는 경합에 약하기 때문입니다. 앱 다중 기동 등으로 두 프로세스가 모두 Exists == false를 본 뒤 Create로 가면, 먼저 만든 쪽이 이기고, 진 쪽은 「같은 이름 키가 이미 있다」로 실패합니다. 첫 기동 때에만, 게다가 드물게만 일어나므로 테스트에서는 거의 밟지 않습니다. 진 쪽은 승자가 만든 키를 다시 연다는 뒷처리를 처음부터 넣어 두세요.

다만 다시 열어도 되는 것은 실패 이유가 「같은 이름 키가 이미 있다」(NTE_EXISTS)일 때뿐입니다. TPM을 쓸 수 없음·권한이 부족한 다른 실패까지 같은 경로로 흘리면, 본래 원인이 Open의 「키를 찾을 수 없다」는 다른 예외로 바뀌어 조사가 미로에 빠집니다. 위 코드가 예외 필터로 HResult를 좁히는 것은 그 때문입니다.

10.3. 설계 때 넣어야 할 현실

공식 문서의 서술과 TPM의 성질에서, 구현 전에 정해 둘 것이 몇 가지 있습니다.

• TPM은 빠르지 않다.전용 마이크로컨트롤러나, CPU의 보호 모드에서 동작하는 작은 프로세서입니다.² 키 생성에 수 초가 걸리는 일도 드물지 않습니다. 대량 데이터 암호화에 TPM 키를 직접 쓰지 마세요.데이터는 AES 등 대칭 키로 암호화하고, 그 대칭 키를 TPM 키로 보호하는 두 단 구성으로 합니다.
• 키 생성·서명은 UI 스레드에서 돌리지 않는다.위의 느림이 그대로 멈춤으로 보입니다.
• TPM을 지우면 키는 사라진다.수리·메인보드 교체·OS 재설치로 잃는다는 전제로, 재등록 동선(서버 쪽에서 단말을 다시 등록하는 절차 등)을 설계에 넣으세요. 「키가 사라지면 막힌다」는 설계는 현장에서 반드시 사고를 냅니다.
• 사용자 단위인가 머신 단위인가를 정한다.사용자 단위 키는 프로필에 묶입니다. 서비스나 예약된 작업에서 쓴다면 머신 단위(CngKeyCreationOptions.MachineKey)가 필요하고, 생성에는 관리자 권한이 필요합니다. 참조 쪽에도 CngKeyOpenOptions.MachineKey를 넘기는 것을 잊지 마세요.데이터 두는 곳의 생각은 「Windows 앱의 데이터 저장 위치 고르는 법」도 참고가 됩니다.
• 머신 단위로 했다고 해서, 서비스 계정이 그 키를 쓸 수 있는 것은 아닙니다.MachineKey가 정하는 것은 키 스토어 위치뿐이고, 누가 쓸 수 있는지는 키에 붙은 ACL(보안 기술자)로 정해집니다. 관리자가 만든 키를 비관리자 서비스 계정으로 열려다 「액세스가 거부되었습니다」로 멈추는 것은 단골 사고입니다. 대처는, 키를 쓰는 본인(서비스 계정)의 권한으로 만들거나, 생성 때 보안 기술자(CNG의 Security Descr 속성)에 서비스 SID를 허용으로 설정하거나. 어느 쪽이든 반드시 실제 실행 계정으로 동작 확인하세요.
• TPM이 없는 환경을 어떻게 다룰지 정한다.요건으로 걸러 낼 것인지, Microsoft Software Key Storage Provider로 fallback해 「보호 수준이 내려간다」는 것을 받아들일 것인지. 혼재 환경에서는 인증서 템플릿에서 Platform Crypto Provider를 우선하면서 소프트웨어 공급자도 허용하는 운용이 실제로 취해집니다.³
• 키에 PIN을 붙일지는 신중히.사전 공격 대책이 효과를 내는 것은 이점이지만, TPM lockout은 전역(global)입니다. 개별 키마다 실패 횟수를 관리하는 것은 기술적으로 현실적이지 않으므로, 인증 실패가 너무 늘면 TPM 전체가 잠깁니다.² 자사 앱의 입력 실수가 같은 단말의 Windows Hello를 끌어들일 수 있다는 뜻입니다.
• 자격 증명 자체의 취급은 별 문제로 남습니다. 스크립트나 설정 파일에 평문으로 두지 않는 설계는 「PowerShell에서의 자격 증명의 안전한 취급」에 정리해 두었습니다.

11. 실무의 정석(판단표)

12. 정리

• TPM은 「비밀 키를 칩 밖으로 내보내지 않은 채로 쓰게 하는 금고」와 「부팅 때 읽어 들인 것을 기록하는 대장」을 겸한, 수동적 보안 프로세서입니다.
• 측정 부팅용 정적 PCR은 Extend로만 값을 진행할 수 있고, 게다가 실행 전에 측정하므로 도중 컴포넌트가 자기 흔적을 지울 수 없습니다. BitLocker는 이 측정값에 키를 봉인합니다(TPM 2.0에는 리셋 가능한 PCR도 있지만, 봉인에 쓰는 PCR은 대상 밖입니다).
• 네이티브 UEFI 기본값에서는 PCR 0/2/4/11, 보안 부팅을 쓸 수 있는 환경에서는 PCR 7/11에 봉인됩니다. PCR 7에 묶는 편이 펌웨어 업데이트로 복구 모드에 떨어지기 어렵습니다.
• 구현은 discrete/통합/펌웨어의 3종류이고, Windows는 모두 같이 다룹니다. Pluton은 CPU 통합형으로, 펌웨어를 Windows Update 경유로도 갱신할 수 있다는 점이 운용상의 특징입니다.
• Windows 11 요건은 TPM 2.0과 「UEFI, 보안 부팅 대응」 펌웨어. 요건은 대응이지 켜 있음이 아니지만, 켜면 BitLocker가 PCR 7에 묶인다는 실익이 있습니다. TPM을 실어도 CSM 모드에서는 요건을 충족하지 않으므로, MBR2GPT를 끼운 뒤 BIOS 모드를 바꾸세요.
• 예외는 Windows 11 IoT Enterprise로, 전용기용 완화 요건에서는 TPM도 보안 부팅도 선택입니다. 다만 대상은 IoT Enterprise LTSC와 비LTSC의 24H2 이후이고, 비LTSC의 21H2〜23H2는 TPM 2.0 필수, IoT 없는 Windows 11 Enterprise LTSC는 완화 대상 밖입니다. 애초에 TPM을 싣지 않는 선택은 BitLocker나 Windows Hello의 보호를 놓는 것이기도 합니다.
• 펌웨어 업데이트·보안 부팅 설정 변경·TPM 지우기·메인보드 교체 전에는 BitLocker 일시 중단과 복구 키 소재 확인을 세트로 합니다.
• 자사 앱에서는 TBS가 아니라 CNG의 Microsoft Platform Crypto Provider를 씁니다. 반출 불가를 명시하고, TPM의 느림과 지울 때의 소실을 설계에 넣으세요.

관련 기사

• Windows 10 지원 종료 후의 현실적 해법 ── ESU·LTSC·교체 판단표
• 산업용 PC에는 어떤 Windows를 넣어야 하는가 ── Windows IoT Enterprise / LTSC 실천 가이드
• Windows PC의 폐기·양도 체크리스트
• PowerShell Remoting(WinRM) 입문 ── 여러 대의 Windows를 일괄 관리한다
• Get-WinEvent로 이벤트 로그를 실무적으로 조사한다 ── 좁히기의 속도가 조사 시간을 결정한다
• PowerShell에서의 자격 증명의 안전한 취급 ── 평문 비밀번호를 스크립트에서 몰아낸다
• Windows 앱의 데이터 저장 위치 고르는 법

관련 상담 영역

合同会社小村ソフト에서는 Windows 11 전환에 따른 하드웨어 요건 점검과 BitLocker 운용 설계 상담, TPM을 쓴 단말 고유 키 관리를 포함한 Windows 업무 앱 수탁 개발을 다룹니다.

• Windows 앱 개발
• 결함 조사·원인 분석
• 기존 자산 활용·이전 지원
• 문의

참고 링크

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

TPM은 결국 무엇을 하나요?

한 마디로 「비밀 키를 밖으로 내보내지 않은 채로 쓰게 해 주는 작은 금고」입니다. TPM 안에서 만든 비밀 키는, 설정에 따라 칩 밖으로 전혀 나가지 않습니다. 앱이나 OS는 키 자체를 받는 것이 아니라, TPM에 「이 데이터에 서명해 달라」「이 키로 복호화해 달라」고 요청하고 결과만 받습니다. 여기에 더해, 부팅 때 읽어 들인 펌웨어나 부트 로더의 해시를 PCR이라는 영역에 쌓아 기록하고, 그 값이 기대와 같을 때만 키를 꺼낼 수 있게 하는 「봉인」을 할 수 있습니다. BitLocker가 「PC 안을 바꿔 끼우면 잠금을 풀 수 없다」는 것은 이 구조 때문입니다.

Windows 11이 TPM 2.0을 필수로 한 이유는 무엇인가요?

BitLocker·Windows Hello·Credential Guard·디바이스 상태 증명 같은 기능이, 하드웨어에 뿌리내린 신뢰의 기점을 전제로 설계되어 있기 때문입니다. TPM 1.2는 RSA와 SHA-1만 쓸 수 있었고, 잠금(lockout) 동작도 제조사마다 제각각이었지만, TPM 2.0에서는 새 알고리즘을 쓸 수 있고, 사전 공격(dictionary attack) 대책도 Windows가 일관되게 구성합니다. 참고로 TPM 2.0은 레거시 BIOS 호환 모드(CSM)에서는 동작하지 않으므로, 네이티브 UEFI 구성이 전제입니다. 예외는 Windows 11 IoT Enterprise로, IoT Enterprise LTSC와 비LTSC의 24H2 이후에서는 TPM도 보안 부팅도 선택입니다(비LTSC의 21H2〜23H2에서는 TPM 2.0은 필수. 이름이 비슷한 Windows 11 Enterprise LTSC(IoT 없음)는 완화 대상이 아닙니다).

dTPM, fTPM, Pluton은 무엇이 다른가요? 무엇을 골라야 하나요?

구현 형태의 차이입니다. dTPM(discrete TPM)은 메인보드 위의 전용 칩, fTPM(firmware TPM)은 CPU의 신뢰 실행 환경에서 동작하는 소프트웨어 구현, Pluton은 CPU에 통합된 Microsoft 설계의 보안 프로세서입니다. Windows에서 보는 사용법은 모두 같고, Microsoft는 어떤 구현을 골라야 하는지에 대해 입장을 취하지 않는다고 명시합니다. 실무상의 차이는, 전용 칩은 CPU와의 버스가 물리 공격의 대상이 될 수 있다는 점, fTPM은 CPU 펌웨어 업데이트에 동작이 좌우된다는 점, Pluton은 펌웨어를 Windows Update 경유로 업데이트할 수 있다는 점 등입니다. 조달에서 고를 수 있다면, 업무 단말에서는 제조사의 보수 방침과 펌웨어 업데이트 제공 상황을 기준으로 하는 것이 현실적입니다.

BIOS를 업데이트했더니 BitLocker 복구 키를 요구받았습니다. 왜인가요?

BitLocker의 키는 부팅 시 측정값(PCR)에 봉인되어 있으므로, 그 측정 대상이 바뀌면 키가 해제되지 않고 복구 모드로 들어갑니다. 펌웨어 업데이트는 바로 PCR 0 등의 측정값을 바꾸는 조작입니다. Microsoft도 PCR 0을 포함하는 구성에서는 펌웨어 업데이트 전에 BitLocker를 일시 중단하라고 안내합니다. 복구 키로 잠금을 풀면, 다음부터는 새 측정값으로 다시 봉인되므로 같은 일은 일어나지 않습니다. 운용으로는 UEFI 업데이트·보안 부팅 설정 변경·TPM 지우기·메인보드 교체 전에 반드시 BitLocker를 일시 중단하고, 복구 키 보관 위치(Active Directory, Microsoft Entra ID, Microsoft 계정)를 먼저 확인하세요.

내 앱에서 TPM으로 키를 지키려면 어떻게 하나요?

TPM 명령을 직접 치지 말고, CNG(Cryptography API: Next Generation)의 키 스토리지 공급자 「Microsoft Platform Crypto Provider」를 사용합니다. .NET이라면 CngKey.Create에 이 공급자와 ExportPolicies.None을 지정하기만 하면, 비밀 키가 TPM 안에 만들어지고 반출할 수 없는 상태가 됩니다. 저수준 TPM Base Services(TBS)도 공개되어 있지만, Microsoft 자신이 키 보관·서명·암호화 용도에는 더 고수준 키 스토리지 API를 쓰라고 권장합니다. 구현에서는 TPM 처리가 느리다는 점, TPM을 지우면 키가 사라진다는 점, TPM이 없는 환경으로의 fallback을 어떻게 할지를 설계에 넣으세요.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.