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회로 잠금)이 하드웨어 쪽에 있기 때문입니다(2장).²
• Windows 11의 최소 요구 사항은 ‘UEFI, Secure Boot 지원’ 펌웨어와 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장).⁸

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회에서 잠기고, 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에서 제조 시 칩에 기록되는 불변의 비밀은 정확히는 ‘엔도스먼트 프라이머리 시드’라는 씨앗(seed)이며, EK는 이 시드로부터 정해진 절차(템플릿)에 따라 도출됩니다. 같은 시드에서 도출하면 반드시 같은 키가 되므로, EK는 다시 만들 수 있어도 사실상 해당 TPM 고유의 키로 유지됩니다. RSA와 ECC 어느 쪽의 EK도 도출할 수 있으며, 실제 기기에 양쪽이 모두 준비되어 있는 경우도 드물지 않습니다. 본론을 이해하는 데는 필요 없는 이야기이므로 건너뛰어도 무방합니다.

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

SRK(Storage Root Key / 스토리지 루트 키)는 다른 키를 감싸는(래핑하는) 부모 키입니다. 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에 비해 알고리즘, 암호, 계층, 루트 키, 인가(authorization), 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이 봉인 대상입니다. 다만 Secure Boot 상태(PCR 7)가 지원되는 경우에는 PCR 7과 PCR 11로 봉인됩니다.⁹ 이것은 중요한 차이입니다. PCR 0/2/4는 펌웨어나 부트 매니저 이미지 자체의 해시이므로, 펌웨어를 업데이트할 때마다 값이 바뀌어 복구 모드로 떨어집니다. 반면 PCR 7은 ‘Secure Boot가 활성화되어 있는지, 어떤 키를 신뢰하고 있는지’를 측정하므로, 서명자가 같다면 이미지가 업데이트되어도 값이 바뀌지 않습니다. 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 위에서도, 부트 매니저보다 뒤 단계에서부터 키를 요청할 수는 없습니다.¹¹

덧붙여 Secure Boot 자체도 BitLocker의 방어 일부입니다. 기본적으로 BitLocker는 PCR 7의 측정을 통해 Secure Boot의 무결성 보호를 활용하여, 허용되지 않은 EFI 펌웨어·EFI 부트 애플리케이션·부트로더가 실행되어 BitLocker의 키를 취득하는 것을 막습니다.¹¹

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

‘TPM 칩’이라는 표현이 널리 퍼져 있는 탓에 TPM은 반드시 독립된 부품이라고 여겨지기 쉽지만, 구현은 3종류가 있습니다.⁶

flowchart LR
    C1["CPU"] ---|"LPC / SPI 버스"| T1["전용 TPM 칩<br/>= 디스크리트 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

• 디스크리트 TPM(dTPM)은 독립된 반도체 패키지의 전용 칩입니다. 마더보드에 실장되며, OEM이 시스템 본체와는 별도로 평가·인증할 수 있다는 이점이 있습니다.⁶
• 통합 TPM은 다른 구성 요소와 같은 패키지에 들어가면서도, 논리적으로는 분리된 전용 하드웨어로 구현됩니다.⁶
• 펌웨어 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이 가진 특징은 펌웨어 업데이트 경로가 두 계통 있다는 점입니다. 기존과 같이 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입니다. 최소 요구 사항은 호환성 목록에 실린 64비트 CPU, 메모리 4GB, 저장소 64GB, DirectX 12 이상을 지원하고 WDDM 2.0 드라이버를 가진 그래픽스, 720p 이상에 9인치 초과·8비트/채널의 디스플레이, ‘UEFI, Secure Boot 지원(Secure Boot capable)’ 시스템 펌웨어, 그리고 TPM 2.0입니다.⁴

여기는 정확하게 읽어야 합니다. 최소 요구 사항이 요구하는 것은 Secure Boot에 대응하고 있다는 것이지, 활성화되어 있다는 것이 아닙니다.⁴ 비활성화 상태여도 요구 사항 자체는 충족할 수 있으므로, Windows 11로 올리기 위해서만 UEFI 설정을 만질 필요는 없습니다. 다만 Secure Boot를 활성화하고, 또한 플랫폼이 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도 Secure Boot도 임의(Optional)입니다.⁵ 산업용 PC나 장치 내장 현장에서는 이 사실을 알고 있는지 여부로 ‘이 보드에서는 Windows 11을 쓸 수 없다’는 결론이 뒤집힙니다.

공식 요구 사항 표는 PREFERRED(권장)와 OPTIONAL(전용기용 최소)의 2열 구성으로 되어 있습니다.⁵

주의할 점이 3가지 있습니다.

• ‘LTSC라면 TPM이 필요 없다’는 것이 아닙니다. 완화 요구 사항이 정의되어 있는 것은 IoT Enterprise이며, Windows 11 Enterprise LTSC(IoT 아님)는 일반 PC용과 동일한 취급입니다. 이름이 비슷해서 혼동하기 쉽지만, 조달하는 라이선스가 어느 쪽인지에 따라 결론이 달라집니다.
• 비LTSC의 IoT Enterprise는 버전에 따라 다릅니다. 21H2~23H2의 OPTIONAL 요구 사항에서는 TPM 2.0이 여전히 필수(임의가 되어 있는 것은 Secure Boot뿐)이며, TPM이 임의가 되는 것은 24H2 이후입니다.⁵
• 프로세서 요구 사항은 별도입니다. TPM과 Secure Boot가 임의여도, 지원 프로세서 목록은 별도로 정의되어 있으므로 그쪽은 반드시 확인하십시오.⁵

그리고 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가 켜져 있는가’, ‘Secure Boot가 켜져 있는가’, ‘DEP가 활성화되어 있는가’ 같은 단순한 표명(claim)으로 변환합니다. 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처럼 ‘사양 버전, 리비전, 정오표(errata)’ 형태로 반환됩니다.¹⁶ 맨 앞이 2.0인지를 보면 Windows 11의 TPM 요구 사항을 충족하는지 판정하는 데 사용할 수 있습니다(CPU·메모리·저장소 등 다른 요구 사항은 별도 확인이 필요합니다. 11장 참조). 여러 대에 대해 원격으로 실행하는 방법은 「PowerShell Remoting(WinRM) 입문」을 참조하십시오.

그 밖에 Get-TpmEndorsementKeyInfo로 EK와 인증서 정보를, Get-TpmSupportedFeature로 특정 기능의 지원 상황을 확인할 수 있습니다. 잠금 해제는 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 초기화·잠금

현장에서 TPM이 화제가 되는 것은 대개 뭔가가 잘 안 될 때입니다. 흔히 있는 3가지를 다룹니다.

그 전에, 이 글의 첫머리에서 제기한 질문 ── ‘왜 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 -->|"Secure Boot 설정을 바꿨다<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를 일시 중지하도록 안내하고 있습니다.⁹ 반대로 말하면, Secure Boot가 올바르게 구성되어 PCR 7에 결부되어 있는 단말에서는 펌웨어 업데이트로 복구 모드에 떨어지는 빈도가 낮아집니다.⁹ Modern Standby 대응 기기에서는 PCR 7 측정이 로고 요구 사항이며, TPM과 Secure Boot가 올바르게 구성되어 있으면 기본적으로 PCR 7과 PCR 11에 결부됩니다.⁹

운용상의 결론은 단순합니다. UEFI 업데이트·Secure Boot 설정 변경·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으로 보호·암호화하고 있는 데이터에 대해서는 반드시 백업과 복구 수단을 준비해 두십시오.⁷

덧붙여 실무에서 중요한 주의점이 3가지 있습니다.⁷

• 자신의 소유물이 아닌 단말(회사나 학교의 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이 2개인 시스템에서는 한쪽을 선택했다면 변경하지 않을 것을 강력히 권장하고 있습니다.⁷

9.3. TPM이 잠겼다(lockout)

PIN 입력 실수가 계속되면 TPM이 잠깁니다(lockout). Windows의 기본 구성에서는 TPM 2.0이 인증 실패 32회에서 잠기고, 10분마다 실패 1회분을 잊습니다. 잠긴 상태여도 회복 간격 동안 전원을 켠 채로 기다리면 잠금에서 벗어날 수 있습니다.² 10분은 어디까지나 Windows의 기본값이므로, 실제 간격은 해당 단말의 Get-Tpm이 반환하는 LockoutHealTime으로 확인하십시오(8장). 서둘러 재부팅을 반복하는 것보다 그대로 두는 편이 빠른 경우가 있습니다.

즉시 해제하고 싶다면 잠금 리셋 명령을 보냅니다. 여기서 오해하기 쉬운 것이 TPM 소유자 비밀번호입니다. Windows 10 버전 1607 이후, Windows는 TPM 프로비저닝 시 소유자 비밀번호를 보관하지 않습니다(무작위의 높은 엔트로피 값을 설정한 뒤 파기합니다).¹⁸ ‘관리자가 소유자 비밀번호를 가지고 있다는 전제’로 절차를 짜면 현장에서 막힙니다.

대신 사용되는 것이 잠금 인가(lockout authorization)입니다. OSManagedAuthLevel의 기본값 5는 TPM 2.0에서는 ‘잠금 인가만을 보유한다’는 것을 의미합니다.¹⁸ 즉 ‘완전한 소유자 비밀번호는 사라졌지만, 잠금을 해제하기 위한 인가는 남아 있다’는 것이 기본 상태로, tpm.msc의 잠금 시간 리셋이나 Unblock-Tpm은 보통 이 인가로 동작합니다. 소유자 비밀번호 자체를 남기는 설정(레지스트리에서 OSManagedAuthLevel을 4로 설정)도 있지만, Microsoft는 강력히 비권장하고 있습니다.¹⁸

덧붙여 소유자 비밀번호가 없더라도, UEFI에서의 물리적 존재 확인을 통해 TPM의 활성화·비활성화·초기화 같은 관리 조작을 수행하는 경로는 남아 있습니다.¹⁸ 다만 이것은 잠금을 비파괴적으로 즉시 해제하는 대체 수단이 아닙니다. 잠금 인가를 사용할 수 없는 경우에는 시간 경과에 의한 회복(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 안에 만들어지며, 프로세스의 메모리에는 나타나지 않습니다. 다만 실제 운영에서는 ‘두 번째 이후에는 기존 키를 연다’, ‘사용자 단위인가 머신 단위인가’, ‘동시 실행 경합’을 처리해야 합니다. 이를 반영한 것이 다음 코드입니다.

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))
    {
        // 두 번째 이후에는 기존 키를 연다(키는 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로 바꾸고 참조 측을 그대로 두면, 기존의 머신 키를 찾지 못해 매번 ‘같은 이름으로 다시 만들려다 실패한다’는 방식으로 망가집니다. 위 코드처럼 생성·존재 확인·열기의 3곳에서 같은 범위(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로 폴백하여 ‘보호 수준이 낮아지는’ 것을 받아들일 것인지. 혼재 환경에서는 인증서 템플릿에서 Platform Crypto Provider를 우선하면서도 소프트웨어 제공자도 허용하는 운용이 실제로 이루어지고 있습니다.³
• 키에 PIN을 붙일지는 신중하게. 사전 공격 대책이 작동하는 것은 장점이지만, TPM의 잠금은 전역(global)입니다. 개별 키마다 실패 횟수를 관리하는 것은 기술적으로 현실적이지 않기 때문에, 인증 실패가 지나치게 늘어나면 TPM 전체가 잠깁니다.² 자사 앱의 입력 실수가 같은 단말의 Windows Hello를 끌어들일 가능성이 있다는 뜻입니다.
• 자격 증명 자체의 취급은 별개의 문제로 남습니다. 스크립트나 설정 파일에 평문으로 두지 않는 설계는 「PowerShell에서 자격 증명을 안전하게 다루기」에 정리해 두었습니다.

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

12. 정리

• TPM은 ‘비밀키를 칩 밖으로 내보내지 않은 채 사용하게 하는 금고’와 ‘부팅 시 읽어들인 것을 기록하는 장부’를 겸한, 수동적인 보안 프로세서입니다.
• 측정 부팅용의 정적인 PCR은 Extend로만 값을 진행시킬 수 있고, 게다가 실행 전에 측정하기 때문에 도중의 구성 요소가 자신의 흔적을 지울 수 없습니다. BitLocker는 이 측정값에 키를 봉인하고 있습니다(TPM 2.0에는 리셋 가능한 PCR도 있지만, 봉인에 사용하는 PCR은 대상 외입니다).
• 네이티브 UEFI의 기본값에서는 PCR 0/2/4/11, Secure Boot를 사용할 수 있는 환경에서는 PCR 7/11에 봉인됩니다. PCR 7에 결부되는 쪽이 펌웨어 업데이트로 복구 모드에 떨어지기 어렵습니다.
• 구현은 디스크리트/통합/펌웨어의 3종류이며, Windows는 어느 쪽이든 동일하게 취급합니다. Pluton은 CPU 통합형으로, 펌웨어를 Windows Update 경유로도 업데이트할 수 있는 점이 운용상의 특징입니다.
• Windows 11의 요구 사항은 TPM 2.0과 ‘UEFI, Secure Boot 지원’ 펌웨어입니다. 요구 사항은 지원이지 활성화가 아니지만, 활성화하면 BitLocker가 PCR 7에 결부된다는 실리가 있습니다. TPM을 탑재하고 있어도 CSM 모드에서는 요구 사항을 충족하지 않으므로, MBR2GPT를 거친 뒤 BIOS 모드를 바꾸십시오.
• 예외는 Windows 11 IoT Enterprise로, 전용기용 완화 요구 사항에서는 TPM도 Secure Boot도 임의입니다. 다만 대상은 IoT Enterprise LTSC와 비LTSC의 24H2 이후이며, 비LTSC의 21H2~23H2는 TPM 2.0 필수, IoT가 아닌 Windows 11 Enterprise LTSC는 완화 대상이 아닙니다. 애초에 TPM을 탑재하지 않는 선택은 BitLocker나 Windows Hello의 보호를 포기하는 것이기도 합니다.
• 펌웨어 업데이트·Secure Boot 설정 변경·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 앱 데이터 저장 위치를 고르는 방법 ── SQLite / JSON / 레지스트리 / Access 판단표

관련 상담 영역

합동회사 코무라소프트는 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에서는 새로운 알고리즘을 사용할 수 있고 사전 공격 대책도 Windows가 일관되게 구성합니다. 또한 TPM 2.0은 레거시 BIOS 호환 모드(CSM)에서는 동작하지 않으므로, 네이티브 UEFI 구성이 전제가 됩니다. 예외는 Windows 11 IoT Enterprise로, IoT Enterprise LTSC와 비LTSC의 24H2 이후에서는 TPM도 Secure Boot도 임의(선택)입니다(비LTSC의 21H2~23H2에서는 TPM 2.0이 필수입니다. 이름이 비슷한 Windows 11 Enterprise LTSC(IoT 아님)는 완화 대상이 아닙니다).

dTPM, fTPM, Pluton은 무엇이 다릅니까? 어느 것을 선택해야 합니까?

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

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

BitLocker의 키는 부팅 시의 측정값(PCR)에 봉인되어 있기 때문에, 그 측정 대상이 바뀌면 키가 해제되지 않고 복구 모드로 들어갑니다. 펌웨어 업데이트는 바로 PCR 0 등의 측정값을 바꾸는 작업입니다. Microsoft도 PCR 0을 포함하는 구성에서는 펌웨어 업데이트 전에 BitLocker를 일시 중지하도록 안내하고 있습니다. 복구 키로 해제하면 다음번부터는 새로운 측정값으로 다시 봉인되므로 같은 일은 일어나지 않습니다. 운영상으로는 UEFI 업데이트·Secure Boot 설정 변경·TPM 초기화(클리어)·마더보드 교체 전에는 반드시 BitLocker를 일시 중지하고, 복구 키의 보관 위치(Active Directory, Microsoft Entra ID, Microsoft 계정)를 먼저 확인해 두십시오.

자사 앱에서 TPM으로 키를 보호하려면 어떻게 해야 합니까?

TPM 명령을 직접 호출하는 것이 아니라, CNG(Cryptography API: Next Generation)의 키 저장소 제공자(key storage provider) 'Microsoft Platform Crypto Provider'를 사용합니다. .NET이라면 CngKey.Create에 이 제공자와 ExportPolicies.None을 지정하기만 하면, 비밀키가 TPM 안에 만들어져 밖으로 반출할 수 없는 상태가 됩니다. 저수준의 TPM Base Services(TBS)도 공개되어 있지만, Microsoft 스스로가 키 보관·서명·암호화 용도에는 더 높은 수준의 키 저장소 API를 사용하도록 권장하고 있습니다. 구현 시에는 TPM 처리가 느리다는 점, TPM을 초기화(클리어)하면 키가 사라진다는 점, TPM이 없는 환경으로의 폴백을 어떻게 할지를 설계에 반영해 두십시오.

저자 프로필

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

Go Komura

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

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