TCB (r1)

참조 모니터는 신뢰 컴퓨팅 기반(TCB)의 핵심 구성 요소로서, 시스템 내의 모든 보안 관련 접근 통제 결정을 수행하는 추상적 개념이자 구현체이다. 모든 주체(예: 사용자, 프로세스)가 객체(예: 파일, 메모리 세그먼트)에 접근하려 할 때, 그 요청은 반드시 참조 모니터를 통과해야 한다. 참조 모니터는 시스템의 보안 정책에 따라 접근을 허용하거나 거부하는 최종 판단을 내린다.

참조 모니터는 세 가지 핵심 속성을 만족해야 한다.

* 완전 중재: 모든 보안 관련 접근 요청은 반드시 참조 모니터의 검사를 받아야 한다. 우회 경로가 존재해서는 안 된다.

* 견고성: 참조 모니터 자체는 변조되거나 비활성화될 수 없어야 한다. 즉, TCB의 일부로 보호받아야 한다.

* 검증 가능성: 참조 모니터의 설계와 구현은 정확성과 완전성을 검증할 수 있어야 한다. 이는 일반적으로 정형적 검증 방법을 통해 이루어진다.

실제 시스템에서 참조 모니터는 단일 모듈이 아니라, 운영체제 커널 내의 보안 관련 코드, 파일 시스템의 접근 제어 모듈, 또는 전용 보안 커널의 형태로 분산 구현되는 경우가 많다. 예를 들어, 마이크로소프트 윈도우의 보안 참조 모니터는 커널 모드 구성 요소로, 객체에 대한 모든 접근을 감시한다[1]. 참조 모니터의 개념은 1972년 제임스 P. 앤더슨이 제안한 이후, 현대 컴퓨터 보안 아키텍처의 기본 토대가 되었다.

보안 커널은 신뢰할 수 있는 컴퓨팅 기반(TCB)의 핵심 구성 요소로서, 시스템의 보안 정책을 강제하는 핵심적인 운영체제 커널의 일부이다. 이는 시스템의 모든 보안 관련 결정을 집중적으로 처리하는 최소한의 소프트웨어 집합으로 설계된다. 보안 커널의 주요 목적은 참조 모니터 개념을 구현하여, 모든 주체(예: 프로세스)가 객체(예: 파일, 메모리 세그먼트)에 접근하려 할 때 이를 검증하고 허가 또는 거부하는 것이다. 이를 통해 시스템 전체의 보안을 보장하는 단일 통제 지점을 제공한다.

보안 커널은 일반적으로 다음과 같은 특징을 가진다.

* 검증 가능성: 크기가 작고 기능이 제한적이기 때문에 정형적 또는 비정형적 방법으로 검증하기 상대적으로 용이하다.

* 완전성: 모든 보안 관련 접근 통제 요청을 중재해야 한다.

* 격리성: 외부의 변조나 우회로부터 자신을 보호할 수 있어야 한다. 이는 하드웨어 지원(예: 프로세서 권한 모드, 메모리 보호)을 통해 달성된다.

보안 커널의 설계는 최소 권한의 원칙을 철저히 적용한다. 즉, 보안 정책을 강제하는 데 꼭 필요한 기능만을 포함하여 코드베이스를 최소화한다. 이는 잠재적인 보안 취약점 표면을 줄이고, 검증 비용을 낮추는 데 기여한다. 전통적인 모놀리식 커널이나 마이크로커널 구조와 비교할 때, 보안 커널은 보안 강제에 특화된 설계 철학을 따른다.

실제 구현에서 순수한 보안 커널만으로 완전한 운영체제를 구성하는 것은 드물며, 신뢰할 수 있는 경로 및 기타 TCB 구성 요소와 함께 통합되어 동작한다. 초기 연구 및 구현 사례로는 MIT에서 개발된 히드라(Hydra) 커널, UCLA 데이터 보안 커널 등이 있다. 이러한 개념은 이후 다중 수준 보안(MLS)을 지원하는 시스템이나 Common Criteria 평가를 받는 제품들의 설계 기반이 되었다.

신뢰할 수 있는 경로는 신뢰 컴퓨팅 기반 내에서 사용자가 시스템의 보안 기능과 직접적이고 안전하게 상호작용할 수 있도록 보장하는 메커니즘이다. 이 경로는 사용자의 인증 정보 입력이나 중요한 보안 정책 변경 명령과 같은 민감한 작업이 악의적인 소프트웨어(예: 트로이 목마나 키로거)에 의해 가로채거나 변조되지 않도록 설계된다. 시스템은 사용자에게 해당 상호작용이 진정한 보안 기능을 통해 이루어지고 있음을 명확히 인지시켜야 한다.

일반적인 구현 방식은 시스템에 의해 제어되는 특정 키 조합(예: Ctrl+Alt+Del)을 누르는 것이다. 이 키 입력은 운영체제의 보안 커널이 직접 처리하여, 위조된 로그인 화면이 아닌 진정한 인증 관리자로 사용자를 안내한다. 그래픽 사용자 인터페이스 환경에서는 신뢰할 수 있는 경로가 보안이 강화된 전용 데스크톱 세션을 활성화하는 방식으로 구현되기도 한다.

신뢰할 수 있는 경로의 존재는 시스템의 전반적인 보안 보증 수준을 평가하는 중요한 요소이다. 예를 들어, TCSEC B2 등급 이상의 시스템에서는 반드시 신뢰할 수 있는 경로의 구현이 요구된다. 이는 공격자가 사용자를 속여 권한을 상승시키는 일련의 공격을 효과적으로 차단하는 핵심 수단으로 작동한다.

최소 권한의 원칙(Principle of Least Privilege)은 신뢰할 수 있는 컴퓨팅 기반(TCB) 설계의 핵심 원칙 중 하나이다. 이 원칙은 모든 프로세스, 사용자, 프로그램이 자신의 임무를 수행하는 데 필요한 최소한의 권한만을 부여받아야 한다는 개념이다. 시스템의 보안을 강화하기 위해, 권한의 범위를 가능한 한 좁히고 제한하는 것을 목표로 한다.

이 원칙을 적용하면, 권한 상승 공격이나 악성 코드의 확산으로 인한 피해를 크게 제한할 수 있다. 예를 들어, 일반 사용자 계정으로 실행되는 응용 프로그램이 침해당하더라도, 해당 프로그램은 시스템 파일을 수정하거나 다른 사용자의 데이터에 접근할 수 있는 권한이 없기 때문에 전체 시스템으로의 피해 확산을 방지한다. TCB 내부의 구성 요소들도 각자 엄격히 정의된 역할에 필요한 권한만을 보유하며, 이는 참조 모니터와 보안 커널의 설계에 반영된다.

구현 측면에서, 최소 권한의 원칙은 다음과 같은 방식으로 적용된다.

이 원칙을 준수하는 시스템은 공격 표면(Attack Surface)이 줄어들어, 설계와 검증이 더 복잡해지는 단점이 있지만, 전체적인 보안성과 견고함이 향상된다. 따라서 TCB는 가능한 한 작은 규모로 유지되고, 그 내부의 각 구성 요소는 철저히 분리된 최소한의 권한을 가지도록 설계된다.

TCB의 계층적 설계는 시스템의 신뢰성을 높이기 위해 보안 기능을 여러 계층으로 분리하고 구조화하는 접근법이다. 이 설계는 복잡한 보안 요구사항을 관리 가능한 수준으로 나누고, 각 계층이 명확한 책임을 가지도록 한다. 계층적 설계의 핵심 목표는 참조 모니터와 같은 핵심 보안 메커니즘의 검증 가능성을 높이고, 한 계층의 결함이 전체 시스템의 무결성을 파괴하지 않도록 격리하는 것이다.

일반적으로 TCB는 가장 낮은 수준의 하드웨어 계층에서 시작하여 상위의 운영체제 커널, 그리고 신뢰할 수 있는 응용 프로그램 계층에 이르기까지 구성된다. 각 계층은 하위 계층의 서비스를 기반으로 구축되며, 상위 계층으로 갈수록 추상화 수준이 높아진다. 예를 들어, 하드웨어 계층은 메모리 보호와 명령어 실행을 담당하고, 그 위의 보안 커널 계층은 접근 제어 정책을 강제한다. 이렇게 계층을 분리함으로써, 가장 중요한 보안 기능(예: 접근 결정)을 가능한 한 작고 단순한 하위 계층에 집중시켜 검증 부담을 줄일 수 있다.

계층적 설계는 시스템의 신뢰성을 체계적으로 확립하는 데 기여한다. 하위 계층의 정확성이 검증되면, 그 위에 구축된 계층들의 보안성도 더욱 확신할 수 있게 된다. 또한, 이 방식은 모듈화와 유지보수성을 향상시킨다. 보안 요구사항이 변경되거나 새로운 위협이 발견되었을 때, 특정 계층만을 수정하거나 강화할 수 있어 전체 시스템을 재설계할 필요가 줄어든다. 이는 최소 권한의 원칙과도 맞닿아, 각 계층이 자신의 임무 수행에 꼭 필요한 권한만을 갖도록 보장하는 데 도움을 준다.

정형적 검증은 신뢰 컴퓨팅 기반(TCB)의 설계와 구현이 보안 정책을 정확히 준수함을 수학적으로 증명하는 과정이다. 이는 코드 검토나 테스트와 같은 비형식적 방법을 넘어, 시스템의 형식적 모델과 명세를 수립하고 논리적 추론을 통해 오류 가능성을 배제하는 것을 목표로 한다.

검증 과정은 일반적으로 높은 수준의 보안 정책 명세로부터 시작하여, 이를 저수준의 설계 명세와 최종적으로 실제 구현 코드에까지 매핑하며 진행된다. 각 단계에서의 정확성은 정형 증명 도구나 모델 검사기와 같은 자동화된 도구의 지원을 받아 검증된다. 이를 통해 설계상의 결함이나 구현상의 오류가 보안 속성을 위반하지 않음을 보장할 수 있다. 이러한 접근 방식은 특히 참조 모니터와 같은 TCB의 핵심 구성 요소에 적용되어, 모든 접근 통제 결정이 완전하고 조작 불가능하며 검증 가능하도록 만든다.

그러나 정형적 검증은 상당한 비용과 복잡성을 동반한다. 시스템의 규모가 커질수록 검증에 필요한 노력은 기하급수적으로 증가하며, 전문적인 지식을 가진 인력과 강력한 도구 체인이 필요하다. 또한, 검증 대상이 되는 형식적 모델과 실제 실행 코드 사이의 정확한 일치를 보장하는 것도 중요한 과제이다. 이러한 한계에도 불구하고, 높은 보증 등급이 요구되는 군사, 금융, 핵심 인프라 시스템에서는 TCB의 무결성을 입증하는 핵심 수단으로 정형적 검증을 채택하고 있다.

TCSEC는 미국 국방부가 1983년에 공표한 컴퓨터 시스템의 신뢰성 평가 기준이다. 공식 명칭은 '신뢰할 수 있는 컴퓨터 시스템 평가 기준'이지만, 표지 색상 때문에 흔히 오렌지북으로 불린다. 이 기준은 TCB의 보안 기능과 보증 메커니즘을 평가하기 위해 개발되었으며, 주로 군사 및 정부 기관에서 사용하는 시스템의 보안 요구사항을 정의하는 데 목적이 있었다.

TCSEC는 시스템을 보안 수준에 따라 네 가지 주요 등급(D, C, B, A)으로 분류하며, C와 B 등급은 다시 하위 등급으로 나뉜다. 가장 낮은 등급인 D 등급은 최소한의 보안을 갖춘 시스템을 의미한다. C 등급은 자발적 보호 체제를 요구하며, C1(선별적 접근 통제)과 C2(통제된 접근 보호)로 구분된다. B 등급은 강제적 접근 통제를 필수로 하며, B1(레이블이 부착된 보안 보호), B2(구조적 보호), B3(보안 도메인)으로 세분화된다. 최고 등급인 A 등급(검증된 설계)은 형식적 검증 방법을 통해 보안 기능이 정확하게 구현되었음을 입증해야 한다.

TCSEC는 체계적인 보안 평가의 초기 표준으로서 큰 영향을 미쳤으나, 몇 가지 한계를 지녔다. 기준이 주로 기밀성 보장에 치중되어 무결성과 가용성은 상대적으로 소홀히 했다는 비판이 있다. 또한 평가 과정이 복잡하고 비용이 많이 들어 상용 제품에 광범위하게 적용하기 어려웠다. 이러한 한계로 인해 이후 다수의 국가와 국제 기구가 참여하는 공통 평가 기준과 같은 새로운 평가 체계가 개발되는 계기가 되었다.

공통 평가 기준(Common Criteria, CC)은 정보 기술 제품 및 시스템의 보안 기능을 평가하기 위한 국제 표준(ISO/IEC 15408)이다. 이는 미국의 TCSEC[2], 유럽의 ITSEC[3] 등 기존의 여러 국가별 평가 기준을 통합하여 1999년에 제정되었다. CC는 보안 요구사항을 명세하는 보호 프로파일(Protection Profile, PP)과 특정 제품의 구현을 기술하는 보안 목표 명세서(Security Target, ST)를 중심으로 평가가 이루어진다. 평가 보증 등급(Evaluation Assurance Level, EAL)은 제품이 평가된 신뢰성 수준을 1(EAL1)부터 7(EAL7)까지의 등급으로 나타낸다.

CC 평가는 크게 두 가지 축으로 구성된다. 첫째는 기능 요구사항(Functional Requirements)으로, 제품이 제공해야 할 보안 기능(예: 식별 및 인증, 접근 통제, 감사)을 정의한다. 둘째는 보증 요구사항(Assurance Requirements)으로, 제품의 보안 기능이 올바르게 구현되고 효과적이라는 것을 입증하기 위한 개발 과정, 테스트, 취약점 분석 등의 활동 수준을 규정한다. 높은 EAL 등급(예: EAL5 이상)을 획득하기 위해서는 TCB의 정형적 설계 및 검증과 같은 엄격한 공학적 절차가 요구된다.

CC 인증 제도는 평가 대상 제품(타겟 오브 평가, Target of Evaluation, TOE)을 독립적인 제3자 평가 기관(평가 기관)이 검증하며, 그 결과는 CC 상호인정 협정(Common Criteria Recognition Arrangement, CCRA)에 가입한 국가들 간에 상호 인정된다. 이는 글로벌 시장에서 보안 제품의 신뢰성을 객관적으로 비교할 수 있는 기준을 제공한다. 그러나 CC 평가는 시간과 비용이 많이 소요되며, 주로 정적 시스템에 초점을 맞추어 동적인 위협 환경을 완전히 반영하지 못한다는 비판도 존재한다.

TCB 개념은 운영체제의 보안 기능을 강화하는 여러 구현체의 기반이 된다. 대표적인 예로 SELinux와 TrustedBSD가 있으며, 이들은 각각 리눅스 커널과 FreeBSD 커널에 강제 접근 통제를 구현하여 시스템의 신뢰할 수 있는 컴퓨팅 기반을 확장한다.

SELinux는 미국 국가안보국이 주도하여 개발한 리눅스 보안 모듈 기반의 보안 아키텍처다. 기존의 임의 접근 통제를 보완하여, 모든 프로세스와 파일 객체에 대해 보안 컨텍스트를 부여하고 정책에 따라 엄격하게 접근을 통제한다. 이는 참조 모니터의 개념을 구현하여, 사용자나 프로세스의 권한과 무관하게 시스템 전반의 보안 정책을 강제한다. 초기에는 복잡성으로 인해 도입 장벽이 높았으나, 현재는 안드로이드 및 주요 리눅스 배포판에 널리 통합되어 있다.

TrustedBSD 프로젝트는 FreeBSD 운영체제에 다양한 보안 확장 기능을 추가하는 것을 목표로 한다. 이 프로젝트는 MAC 프레임워크, 감사 이벤트 로깅, 역할 기반 접근 통제와 같은 TCB 구성 요소를 제공한다. 특히 MAC 프레임워크는 커널에 모듈화된 보안 정책을 로드할 수 있는 기반을 마련하여, 다양한 강제 접근 통제 모델을 유연하게 구현할 수 있게 한다. TrustedBSD의 기술은 이후 애플의 macOS와 iOS의 보안 하위 시스템 개발에 기여하기도 했다.

이 두 구현체는 다음과 같은 공통점과 차이점을 보인다.

두 시스템 모두 운영체제의 TCB를 강화하여, 애플리케이션의 결함이나 관리자 실수가 시스템 전체로 전파되는 것을 방지하는 것을 핵심 목표로 삼는다. 이를 통해 권한 상승 공격과 같은 위협으로부터 핵심 시스템 자원을 보호한다.

하드웨어 기반 TCB는 소프트웨어만으로는 보장하기 어려운 근본적인 보안 기능을 물리적 칩셋이나 프로세서 내부의 보호된 영역을 통해 제공한다. 이 접근 방식은 신뢰할 수 있는 컴퓨팅 베이스의 루트를 하드웨어 수준에 두어, 시스템이 부팅되는 순간부터 무결성과 기밀성을 검증할 수 있는 기반을 마련한다. 소프트웨어는 변조될 수 있지만, 전용 하드웨어 회로는 외부 공격에 훨씬 더 강력한 저항성을 가지므로, TCB의 핵심 요소를 하드웨어로 구현하면 전체 시스템의 보안 강도가 크게 향상된다.

대표적인 구현 사례로는 신뢰 플랫폼 모듈(TPM)이 있다. TPM은 마더보드에 장착된 전용 마이크로컨트롤러로, 암호화 키 생성, 저장, 관리 및 플랫폼 무결성 측정(Measured Boot)을 담당한다. 시스템 부팅 시 각 구성 요소(BIOS, 부트로더, 운영체제 커널 등)의 해시 값을 TPM 내부의 플랫폼 구성 레지스터(PCR)에 누적하여 저장한다. 이 측정값을 통해 시스템이 신뢰할 수 있는 상태로 부팅되었는지를 후속 소프트웨어(예: 원격 증명 서버)가 검증할 수 있다[4].

또 다른 주요 사례는 시큐어 엔클레이브(Secure Enclave)와 같은 프로세서 기반 보안 기술이다. 이는 CPU 내에 물리적으로 격리된 보안 영역을 생성하여, 민감한 데이터와 코드(예: 생체 인증 정보, 암호 키)가 주 운영체제나 다른 응용 프로그램으로부터 완전히 차단된 상태에서 실행되도록 한다. 이 영역에 대한 접근은 매우 제한된 명령어 집합을 통해서만 가능하며, 외부에서 메모리를 직접 읽거나 엔클레이브 내 코드를 변조하는 것이 불가능하다. 애플의 A 시리즈 칩에 탑재된 시큐어 엔클레이브나 인텔의 소프트웨어 가드 익스텐션(SGX)이 이 범주에 속한다.

이러한 하드웨어 기반 TCB 기술들은 다음과 같은 이점을 제공한다.

하드웨어 기반 TCB는 강력한 보안 기반을 제공하지만, 구현 비용이 증가하고 하드웨어 자체의 설계 결함이 발견될 경우 패치가 어려울 수 있다는 한계도 존재한다. 또한, TPM과 시큐어 엔클레이브는 서로 보완적인 역할을 하기도 하는데, TPM은 시스템 전반의 무결성을, 시큐어 엔클레이브는 특정 응용 프로그램 데이터의 기밀성과 무결성을 보호하는 데 각각 특화되어 있다.

TCB는 시스템의 보안을 보장하기 위해 모든 보안 관련 작업을 검사하고 통제해야 합니다. 이 과정에서 추가적인 검증 절차와 접근 제어 메커니즘이 수행되며, 이는 필연적으로 시스템의 전반적인 성능에 부하를 초래합니다. 예를 들어, 참조 모니터는 모든 보안 관련 시스템 호출을 가로채어 정책에 부합하는지 검사하는데, 이는 모든 시스템 호출에 대해 추가적인 처리 시간을 요구합니다.

성능 오버헤드는 주로 두 가지 형태로 나타납니다. 첫째는 처리량 감소와 응답 시간 지연입니다. 각 보안 커널을 통한 접근 통제 결정은 CPU 사이클을 소모하며, 특히 입출력이 빈번한 환경에서는 지연이 두드러집니다. 둘째는 시스템 자원의 추가 점유입니다. TCB 구성 요소 자체가 메모리 공간을 차지하고, 보안 감사 로그를 저장하기 위한 디스크 공간도 필요로 합니다.

이러한 오버헤드는 보안 수준과 성능 사이의 균형(trade-off) 문제를 제기합니다. 설계자는 보안 요구사항을 충족시키면서 오버헤드를 최소화하기 위해 TCB의 크기를 최소화하고, 검사 알고리즘을 효율적으로 구현하며, 하드웨어 가속을 활용하는 등의 최적화 기법을 적용해야 합니다. 그러나 근본적으로 완전한 제로 오버헤드 TCB는 존재하지 않으며, 이는 TCB 기반 시스템 설계의 지속적인 도전 과제로 남아 있습니다.

TCB 설계는 시스템의 모든 보안 메커니즘을 하나의 논리적 단위로 통합하고 검증해야 하므로 본질적으로 복잡성을 수반한다. 이 복잡성은 설계 단계에서 시작되어 검증 과정까지 이어진다. 시스템이 거대해지고 기능이 다양해질수록 참조 모니터와 보안 커널의 규모와 상호작용도 증가하여, 모든 가능한 상태 전이와 접근 제어 결정을 완벽하게 정의하고 구현하는 것이 어려워진다. 설계 오류나 누락은 TCB 자체에 취약점을 만들어낼 수 있으며, 이는 전체 시스템 보안의 근간을 위협한다.

검증의 복잡성은 특히 높은 보안 등급을 요구하는 시스템에서 두드러진다. 정형적 검증과 같은 방법론은 수학적 모델을 통해 설계의 정확성을 증명하려 시도하지만, 이 과정은 매우 많은 시간과 전문적인 지식을 요구한다. 실제 구현 코드가 정형적 명세와 완전히 일치하는지 검증하는 것도 주요 과제이다. 또한, 공통 평가 기준(CC)과 같은 평가 제도에서 높은 보증 수준(EAL6/EAL7)을 획득하기 위해서는 극도로 엄격하고 비용이 많이 드는 검증 활동이 필수적이다.

이러한 복잡성은 실용적인 도전 과제를 야기한다. 복잡한 TCB 설계와 검증에는 막대한 개발 비용과 긴 시간이 소요되며, 고도로 훈련된 인력이 필요하다. 결과적으로, 강력한 보안을 갖춘 시스템의 가격은 상승하고 시장에의 보급이 제한될 수 있다. 설계와 검증의 복잡성은 TCB 개념의 이론적 우수성에도 불구하고, 실제 광범위한 적용을 가로막는 주요 장벽 중 하나로 지적된다.

클라우드 컴퓨팅 환경에서 신뢰할 수 있는 컴퓨팅 기반(TCB)의 개념은 물리적 경계가 모호해지고 가상화 기술이 광범위하게 사용됨에 따라 크게 확장되고 재정의된다. 기존의 단일 시스템 내에서 보호 메커니즘을 구현하는 방식에서 벗어나, 클라우드의 TCB는 하이퍼바이저, 가상 머신 모니터, 클라우드 관리 플랫폼, 그리고 이를 구동하는 하드웨어까지 포함하는 다계층적 신뢰 체인을 구축하는 것을 목표로 한다. 이는 단일 테넌트(사용자)가 전체 물리적 인프라를 통제하지 않는 다중 테넌트 환경에서 데이터의 기밀성, 무결성, 가용성을 보장하기 위한 필수 조건이다.

주요 구현 접근 방식으로는 하이퍼바이저 수준의 강화와 하드웨어 기반 신뢰 기술의 활용이 있다. 예를 들어, 하이퍼바이저 자체를 최소화된 TCB로 설계하여 공격 표면을 줄이는 연구가 진행된다. 또한, 신뢰 실행 환경(TEE)이나 인텔 SGX 같은 기술은 클라우드 내의 개별 가상 머신이나 애플리케이션에 대해 하드웨어 차원의 보호된 실행 공간을 제공하여, 심지어 호스트 운영체제나 하이퍼바이저가 악의적이더라도 내부 코드와 데이터의 안전을 보장하려고 시도한다. 이러한 기술은 "신뢰할 수 없는" 클라우드 인프라 위에서 "신뢰할 수 있는" 연산을 가능하게 하는 핵심 요소로 주목받는다.

그러나 클라우드 TCB는 고유한 도전 과제에 직면한다. 가장 큰 문제는 신뢰 체인의 확장과 검증이다. 클라이언트 디바이스부터 클라우드 애플리케이션, 가상화 계층, 물리적 서버에 이르기까지 모든 구성 요소의 상태를 검증하고 신뢰를 입증하는 것은 극도로 복잡하다. 이를 해결하기 위해 원격 증명(Remote Attestation) 프로토콜이 중요해진다. 이 프로토콜은 클라우드 서비스 제공자가 플랫폼의 소프트웨어 및 하드웨어 상태가 정책을 준수함을 원격의 신뢰 당사자에게 암호학적으로 증명할 수 있게 한다.

결과적으로, 클라우드 환경에서의 TCB는 정적이고 단일한 것이 아니라, 동적이고 계층적이며 암호학적 증명으로 뒷받침되는 확장된 개념으로 진화하고 있다. 이는 클라우드 컴퓨팅의 보안 모델이 인프라 자체의 완전한 신뢰를 가정하기보다, 신뢰를 검증하고 필요한 부분만을 최소화하는 방향으로 전환되고 있음을 반영한다.

사물인터넷 환경은 수많은 임베디드 시스템이 네트워크로 연결되어 있어, 전통적인 TCB 개념을 적용하기에 고유한 도전 과제를 제시한다. IoT 디바이스는 일반적으로 제한된 컴퓨팅 자원, 낮은 전력 소비 요구사항, 그리고 다양한 제조사와 프로토콜로 인한 이기종 환경을 특징으로 한다. 이러한 제약 조건은 강력한 참조 모니터나 보안 커널을 구현하는 데 어려움을 초래하며, 결과적으로 공격 표면이 넓어지게 된다.

IoT 보안에서 TCB의 범위는 디바이스의 하드웨어, 펌웨어, 통신 스택, 그리고 제한된 애플리케이션까지 확장되어 정의된다. 핵심 설계 목표는 가능한 한 작고 검증 가능한 TCB를 구축하는 것이다. 이를 위해 마이크로커널 아키텍처를 채택하거나, 하드웨어 기반 격리 메커니즘(예: ARM TrustZone)을 활용하여 중요한 보안 기능(예: 암호화 키 관리, 부팅 무결성 검증)을 최소한의 신뢰할 수 있는 코드 기반으로 분리하는 접근법이 사용된다.

IoT 시스템의 계층적 특성은 TCB 설계에도 영향을 미친다. 단일 디바이스의 TCB뿐만 아니라, 디바이스-게이트웨이-클라우드 서버 간의 상호작용을 포함하는 전체 시스템의 신뢰 체인을 고려해야 한다. 각 계층의 TCB는 하위 계층의 보안 가정에 의존하게 되므로, 신뢰할 수 있는 경로는 종단간 암호화와 안전한 인증 프로토콜을 통해 구축되어야 한다.

결과적으로, IoT 보안에서의 TCB는 단일의 강력한 보호 메커니즘이 아니라, 하드웨어에서 애플리케이션에 이르는 여러 계층에 걸쳐 분산되고 최소화된 신뢰 기반을 구축하는 것을 목표로 한다. 이는 공통 평가 기준과 같은 전통적인 평가 체계가 IoT 디바이스의 특수성을 반영하도록 진화해야 함을 의미한다.