Network/Zero Trust

[Zero Trust - Device] Hardware Trust: 소프트웨어로 소프트웨어를 증명할 수 없는 이유

러러 2026. 3. 25. 01:01

이 전 포스트에서 Device Posture를 다뤘다. 에이전트가 OS 버전, EDR 상태, 암호화 여부를 보고하고, 그 신호들이 접근 결정에 반영된다. 그런데 에이전트가 정직하게 보고한다는 한 가지 전제가 있다.

 

에이전트는 소프트웨어다. 소프트웨어는 교체될 수 있다. OS가 루팅되면 에이전트를 가로채거나 교체하는 것이 가능하다. 더 심각한 경우는 OS보다 아래, 부트로더나 펌웨어 레이어에 악성코드가 자리 잡는 것이다. 이 상태에서 OS는 정상으로 보이고, 에이전트도 정상으로 실행되며, "모든 것이 정상"이라는 보고가 계속 나간다. 이것이 루트킷의 본질이다. 탐지 시스템이 의존하는 레이어보다 아래에서 실행되기 때문에 탐지되지 않는다.

 

소프트웨어 레이어 안에서 순환 논리가 생긴다. 에이전트의 신뢰를 소프트웨어가 보장하려면 OS를 신뢰해야 하고, OS를 신뢰하려면 부트로더를 신뢰해야 하고, 부트로더를 신뢰하려면 펌웨어를 신뢰해야 한다. 이 체인의 시작점이 소프트웨어 안에 있으면 탈출구가 없다.

 

신뢰 체인의 출발점을 소프트웨어 밖에 두어야 한다. 외부 서버에 검증을 위임하는 것은 또 다른 소프트웨어 의존이다. 신뢰의 근거가 되려면 소프트웨어가 접근할 수 없는 물리적 경계 안에 있어야 한다.

TPM — 신뢰 체인의 앵커

TPM(Trusted Platform Module)은 메인보드에 탑재된 독립된 보안 칩이다. CPU나 OS와 물리적으로 분리된 별도의 처리 환경에서 동작하며, 내부에 저장된 키와 데이터에 OS가 직접 접근해 수정하는 것이 불가능하다. 악성코드가 OS를 완전히 장악해도 TPM 안에 있는 것은 건드릴 수 없다.

 

TPM이 하는 일은 두 가지다.

부팅 과정의 각 단계를 측정해 기록하는 것, 그리고 그 기록을 근거로 기기 상태를 외부에 증명하는 것이다.

PCR — 부팅 측정의 누적 기록

PCR(Platform Configuration Register)은 TPM 내부의 레지스터다. 각 부팅 단계는 다음 단계에서 실행될 소프트웨어를 먼저 측정하고 그 해시를 해당 PCR에 기록한 뒤 제어를 넘긴다. UEFI 펌웨어가 부트로더를 실행하기 전에 부트로더를 측정하고, 부트로더가 OS 커널로 제어를 넘기기 전에 커널을 측정하는 방식이다. UEFI 펌웨어, 부트로더, OS 커널은 각각 별도의 PCR 인덱스에 독립적으로 기록된다.

 

PCR에 값을 기록하는 방식이 일반적인 쓰기와 다르다. 임의로 덮어쓰는 것이 불가능하고, extend 연산만 허용된다.

PCR[n] = Hash( PCR[n] || 새로운 측정값 )

현재 PCR 값과 새 측정값을 이어붙인 뒤 해시를 계산하고, 그 결과가 새 PCR 값이 된다. 부트로더가 악성 버전으로 교체됐다면, 해당 PCR에 누적되는 해시 체인 전체가 달라지고 최종 PCR 값이 기대값과 일치하지 않는다. 이것이 나중에 "이 기기가 정상 상태로 부팅됐는가"를 확인할 때 드러난다.

PCR 인덱스는 역할에 따라 할당이 정해져 있다. PCR[0]에는 펌웨어, PCR[4]에는 부트로더(IPL 코드), PCR[7]에는 Secure Boot 정책 상태가 기록된다. 부팅 후 OS와 드라이버는 PCR[8] 이상에 측정값을 남긴다.

Endorsement Key와 Attestation Key

TPM에는 제조 시 주입되는 Endorsement Key(EK)가 있다. EK의 개인키는 TPM 외부로 절대 나가지 않으며, 해당 칩이 인증된 제조사의 진짜 TPM임을 증명하는 루트 키다.

 

실제 기기 증명에 쓰이는 것은 Attestation Key(AK)다. TPM이 생성하는 비대칭 키로, 개인키는 TPM 내부에만 존재하고 공개키만 외부에 공개된다. PCR 측정값에 서명할 때 AK 개인키가 사용된다. 검증자는 AK 공개키로 서명을 확인하고, 이 AK가 EK와 동일한 TPM 내에 존재한다는 것을 TPM 제조사의 EK 인증서를 통해 함께 검증함으로써 "이 서명이 실제 TPM 내부에서 생성됐다"는 것을 확인한다.

Secure Boot — 부팅 경로의 서명 검증

TPM이 부팅 과정을 측정하고 기록하는 역할이라면, Secure Boot는 서명되지 않은 소프트웨어의 실행 자체를 차단한다. UEFI 펌웨어에 내장된 기능으로, 부팅의 각 단계에서 다음 단계 소프트웨어의 디지털 서명을 검증한다. 서명이 유효하지 않으면 실행이 거부된다.

 

Secure Boot는 단순한 허용 목록이 아니라 계층적 키 구조로 관리된다.

부트로더의 서명이 db에 있으면 실행을 허용하고, dbx에 있으면 차단한다. 공격자가 악성 부트로더를 실행하려면 자신의 서명 키를 db에 추가해야 하는데, 이는 KEK 소유자만 할 수 있다. KEK 변경은 PK 소유자만 할 수 있다.

 

dbx에는 또 다른 역할이 있다. 취약점이 발견된 부트로더 버전을 dbx에 추가하면 영구히 차단할 수 있다. 2020년 발견된 BootHole 취약점은 GRUB2의 버퍼 오버플로우를 통해 악성 부트로더 삽입이 가능했다. 취약한 버전의 서명이 dbx에 등록되면서 해당 부트로더는 Secure Boot가 활성화된 기기에서 더 이상 실행되지 않는다. Secure Boot가 정적인 허용 목록이 아니라 동적으로 갱신 가능한 구조인 이유가 여기에 있다.

 

Secure Boot가 주는 보장은 하나다. "이 기기는 신뢰할 수 있는 서명 체인으로 부팅됐다." 이것이 성립할 때, 그 위에서 실행되는 OS와 에이전트의 신호를 신뢰할 기반이 생긴다.

Remote Attestation — 원격에서 부팅 상태 증명

Secure Boot와 PCR은 기기 로컬의 보장이다. 원격 서버가 "이 기기가 정상 상태로 부팅됐는가"를 확인하려면 그 기록을 외부로 전달하고 검증해야 한다. 이것이 Remote Attestation이다.

서버가 확인하는 것은 두 가지다. AK 공개키로 Quote의 서명을 검증해 응답이 실제 TPM 내부에서 생성됐음을 확인한다. 그리고 PCR 값이 기대값과 일치하는지 확인해 부팅 체인의 무결성을 검증한다.

 

nonce의 역할이 중요하다. 서버가 요청마다 다른 난수를 보내고, TPM이 그 nonce를 포함해 서명한다. Quote에 nonce가 포함돼 있기 때문에, 이전에 캡처한 Quote를 나중에 재사용하는 재전송(replay) 공격이 불가능하다. 정상 기기의 Quote를 탈취해뒀더라도, 다음 요청의 nonce가 달라지면 그 Quote를 사용할 수 없다.

Sealed Storage — PCR 값에 키를 봉인하다

Remote Attestation이 "외부에서 기기 상태를 확인"하는 메커니즘이라면, Sealed Storage는 "기기 내부에서 특정 부팅 상태에만 키를 공개"하는 메커니즘이다.

 

BitLocker가 대표적인 사례다. 디스크 암호화 키를 TPM에 봉인할 때 특정 PCR 값과 함께 봉인한다. 기기가 정상 부팅 경로로 부팅됐을 때 PCR 값이 봉인 시점의 값과 일치하면 키가 자동으로 해제돼 디스크가 복호화된다. Secure Boot를 비활성화하거나 부트로더가 교체되면 PCR[7]과 PCR[4] 값이 달라지고, 봉인이 해제되지 않아 디스크를 읽을 수 없다. 기기를 탈취해 다른 OS로 부팅하는 방식의 공격을 원천 차단한다. 이 구조 덕분에 정상 부팅 경로라면 사용자가 별도의 PIN을 입력하지 않아도 TPM이 PCR 조건을 확인하고 자동으로 잠금을 해제한다 — 사용자는 암호화가 동작하고 있다는 사실을 인식하지 못한 채 정상적으로 작업할 수 있다.

플랫폼별 구현

TPM 기반 하드웨어 신뢰는 플랫폼마다 구체적인 형태가 다르다.

  • Windows Hello for Business: 조직에서 발급한 기기 인증서의 개인키를 TPM에 저장한다. 키가 TPM 밖으로 나가지 않기 때문에 기기 도용이나 키 파일 추출이 불가능하다. Intune과 연동 시 TPM 기반 기기 인증서 발급 여부를 Device Posture 신호로 활용할 수 있다. Microsoft Health Attestation Service가 PCR 값을 기반으로 기기 상태를 원격 검증하고, 그 결과를 Conditional Access 정책에 반영하는 파이프라인이 이 구조 위에서 동작한다.

  • macOS Secure Enclave: Apple Silicon(M1/M2)과 T2 칩에 내장된 별도의 보안 프로세서다. 물리적으로 분리된 구조는 TPM과 유사하지만 Apple의 독자 구현이다. Secure Boot 체인(iBoot → 커널 서명 검증)을 구현하며, 기기 인증서의 개인키를 Secure Enclave 내부에 보관한다. Jamf와 연동 시 Secure Enclave 기반 기기 인증서가 MDM 등록의 암호학적 증거로 활용된다.

  • fTPM(Firmware TPM): 별도의 물리 칩 없이 프로세서 내부의 보안 실행 환경(AMD PSP, Intel ME 등)에서 소프트웨어로 구현된 TPM이다. TCG 표준 TPM 2.0 인터페이스를 그대로 제공하므로 애플리케이션 입장에서는 물리 칩과 동일하게 사용할 수 있다. 비용이 낮아 보급형 장치에 많이 탑재되지만, 별도 칩보다 공격 표면이 넓다. 프로세서 펌웨어 취약점이 fTPM의 신뢰 경계를 침범할 가능성이 있기 때문이다. 일반 기업 환경에서는 충분하지만, 최고 수준의 보안이 요구되는 환경에서는 독립 칩(discrete TPM)이 권장된다.

세 구현 모두 TPM 2.0 인터페이스를 통해 Remote Attestation과 연동할 수 있다. 구현 형태가 다를 뿐, PCR 측정, EK/AK 기반 서명, 부팅 무결성 보증과 같은 핵심 구조는 동일하다.

Device Posture와의 연결

Vol.6의 Device Posture 신호들은 소프트웨어 레이어에서 온다. EDR이 "위협 없음"이라고 보고하고, MDM 에이전트가 "정책 준수"라고 보고한다. 하드웨어 신뢰는 이 소프트웨어 보고의 전제 조건을 보증한다.

두 레이어는 서로 다른 질문에 답한다. 하드웨어 신뢰는 "이 기기가 조작되지 않은 소프트웨어로 부팅됐는가"를 보장하고, 소프트웨어 Posture는 "부팅 이후 현재 기기 상태가 정책을 충족하는가"를 측정한다. 하드웨어 신뢰 없이 소프트웨어 Posture만 있으면 측정 도구 자체의 신뢰를 보장할 방법이 없다. 소프트웨어 Posture 없이 하드웨어 신뢰만 있으면 정상 부팅 이후의 런타임 상태를 추적할 수 없다.

 

이 전 포스트에서 기기 인증서가 강력한 신뢰 지표라고 했는데, 그 강도는 개인키가 어디에 저장되느냐에 따라 달라진다. TPM 기반 기기 인증서는 개인키가 TPM 밖으로 나갈 수 없으므로, 인증서가 유효하다는 것이 물리 기기의 존재와 동일한 의미를 가진다. 소프트웨어 키스토어에 저장된 인증서는 파일 복사로 탈취가 가능하다. 같은 X.509 인증서처럼 보여도 키가 어디에 있느냐에 따라 신뢰 수준이 완전히 다르다.

단계적으로 접근하는 방법

TPM 2.0은 현재 제조되는 대부분의 비즈니스 노트북과 데스크톱에 탑재돼 있다. Windows 11이 TPM 2.0을 필수 요건으로 지정하면서 보급이 빠르게 확산됐다. 하지만 하드웨어가 있다고 해서 Attestation을 자동으로 활용하는 것은 아니며 구현과 인프라가 필요하다.

 

현실적인 시작점은 TPM 기반 기기 인증서와 소프트웨어 기반 인증서를 구분하는 것이다. 고위험 리소스 접근 시 TPM에 개인키가 저장된 인증서를 요구하는 정책만으로도, 전체 Remote Attestation 파이프라인을 구축하기 전에 하드웨어 신뢰의 일부를 접근 결정에 반영할 수 있다.

 

Remote Attestation 파이프라인을 도입할 때 빠뜨리기 쉬운 것이 PCR 기대값 관리다. Attestation 서버는 "이 기기가 정상 상태로 부팅됐는가"를 확인하기 위해 기대 PCR 값을 알고 있어야 한다. OS 업데이트, 펌웨어 업데이트, 드라이버 변경이 발생할 때마다 관련 PCR 값이 바뀐다. 업데이트 배포 직후 Attestation 서버의 기대값을 갱신하지 않으면 정상 업데이트를 마친 기기가 Attestation에 실패해 접근이 차단된다. PCR 기대값 데이터베이스를 소프트웨어 배포 파이프라인과 연동해서 함께 관리하는 것이 현실적이다.

참고 자료