본문 바로가기

정보보안

TEE(Trusted Execution Environment)

728x90

TEE(Trusted Execution Environment)의 발단

TEE(신뢰 실행 영역)은 2009년 OMTP라는 단체에서 발간한 Advanced Trusted Environment에 처음으로 등장한 개념이다.

 

TEE의 요구사항은 5가지가 있다.

요구사항 설명
Secure Storage 민감 데이터의 안정한 저장
Secure Boot 부팅시 실행 코드의 무결성 검증
Run-time Integrity Checking (RIC) 런타임시 실행환경 모니터링
Secure User Input/Output 사용자 입/출력에 대한 보호
Secure Debug 승인되지 않은 디버그 포트 접근 제어

 

이 TEE가 처음 등장한 후 ARM에서 이를 실체화한 TrusZone이라는 이름의 HW/SW 아키텍처를 정의하게 된다.

 

그리고 2010년 글로벌플랫폼이라는 단체에서 TEE API와 아키텍처의 표준화를 시작했다. 그 이후에는 인텔에서도 SGX라는 기술을 발표했다.

TEE의 개념

 

 

TEE는 두 개의 실행환경으로 분리된 메인 프로세서에서 보안을 담당하는 실행 영역이다.

 

메인 프로세서를 두 개의 실행환경으로 나눠 그중 하나를 보안을 담당하는 전용 영역으로 할당하는 기술이다. 여기서 보안을 담당하는 영역이 TEE, 일반 영역을 Rich Execution Environment(REE)라고 한다.

 

이때 TEE에서는 secure boot, secure storage, attestation과 같은 기술을 통해 TEE에서 실행하는 SW의 안전한 실행을 보장하게 된다.

 

프로세서가 두 개의 실행 영역으로 분리되기 때문에 애플리케이션을 개발할 때도 REE와 TEE에서 작동하는 코드를 각각 개발해야 한다.

 

개발 예시

  • REE: UI, 네트워크 등의 처리
  • TEE: 키 관리, 서명, 암호화 처리

 

여기서 인텔은 TEE에는 보안을 위한 최소한의 콘텐트를 담을 것을 권장하고 있다.

TEE의 동작

 

 

TEE를 지원하는 프로세서는 NS 비트라는 걸 가지고 있어 이를 통해 현재 실행 중인 코드가 TEE나 REE 중 어디에서 실행되는지 알 수 있다.

 

 

그리고 모니터 모드에서 NS 비트를 변경할 수 있다.

 

다시 ARM 아키텍처 이미지에서 버스 부분을 보자.

 

 

버스는 데이터를 실어나르는 역할을 하게 되는데, 이 데이터도 각각 NS 비트를 가지고 있어 이 데이터가 어느 환경에서 사용되어야 하는지 구분할 수 있다.

 

또한 Protected Componenet가 있는데, 램, 카메라, 터치패드와 같은 터치패드의 접근을 관리하는 방화벽 역할을 한다.

 

예를 들어, REE에 작동 중인 코드에서 어떤 secure 한 메모리에 접근하려는 경우, 이를 Protected Component가 차단하게 된다. 반대로 TEE에서 작동 중이라면 접근을 허용한다.

TEE의 기본 기능

Secure Boot

Secure Boot는 현 디바이스에서 실행 중인 코드가 변조되지 않았는지 증명하는 기술이다.

 

일반적으로 부팅 과정은 ROM -> 부트로더 -> OS 순으로 이뤄진다. 여기서 부트로더의 코드를 실행 전, 부트로더의 디지털 서명을 확인하고, 다음으로 OS의 디지털 서명을 검증하게 된다.

 

실제 시스템의 구현에 따라 여러 기술이 적용될 수 있다.

Secure Storage

데이터를 안전하게 저장하는 기술이다.

 

핵심은 TEE에서만 관리할 수 있는 암호화 키를 통해 저장하려는 데이터를 암호화를 하는 것이다.

 

애플리케이션에서 중요한 정보를 저장하고 싶을 때 TEE에 있는 키로 암호화를 한 뒤 REE의 파일 시스템에 저장하게 된다.

 

이에 더불어서 안티 롤백이 지원되는데, 업데이트 되기 전 파일을 덮어쓰는 유형의 공격을 막을 수 있게 해 준다.

Provisioning & Remote Attestation

Provisioning은 내가 만든 Trusted App에 어떤 키를 발급하는 것이다.

 

Attestation은 TEE로부터 온 메시지의 인증성을 검증하는 것이다.

 

인텔의 문서에서 제공하는 SGX의 attestation 과정을 보자.

  1. Attestation Request (검증자의 인증 요청): 검증자(Challenger)가 애플리케이션에 인증 요청(attestation request)을 보낸다. 이 검증자는 플랫폼 외부에 있으며, 앱이 신뢰할 수 있는 환경에서 실행 중인지 확인하고 싶어 한다.
  2. Request to produce local attestation: 애플리케이션은 자신의 enclave에 attestation을 생성하도록 요청한다. 여기서 enclave는 보안이 강화된 환경으로, 실행 중인 코드와 데이터를 보호하는 역할을 한다.
  3. 로컬 attestation 생성: Enclave는 자체적으로 로컬 attestation을 생성하는데, 이는 현재 enclave의 상태가 안전한지 증명하는 정보이다.
  4. 로컬 attestation을 Quoting Enclave(QE)로 전달: 애플리케이션은 생성된 attestation을 QE로 전송한다. QE는 신뢰할 수 있는 환경에서 동작하여, attestation을 quote로 변환한다.
  5. Quote 생성: QE는 받은 로컬 attestation을 검증하여 asymmetric attestation key를 사용해 서명한다. 이러면 attestation은 quote로 변환되며, 플랫폼 외부에서도 검증할 수 있는 인증 정보가 된다.
  6. Challenger get Quote: 애플리케이션은 생성된 quote를 검증자에게 전달한다.
  7. Verify Quote: 검증자는 attestation verification service를 사용하여 quote를 검증한다.
    1. 서명된 quote의 유효성 확인(비대칭 키 검증)
    2. quote에 포함된 enclave의 보안 상태 분석
    3. quote 무결성 검증

TEE SW의 개발

 

TEE 소프트웨어를 개발하기 위해선 다음과 같은 것들이 필요하다.

 

TEE Driver on REE

Trusted Code 설치 권한(인증서 혹은 서명키)

C/C++ 스펙의 API들

Enclave Definition Language(EDL)

Trusted code의 엔트리 포인트를 미리 정의해야 한다.

 

인텔의 SGX는 EDL이라는 형식을 통해 자기가 제공하려는 TEE는 이런 것이다. 를 정의한다. 정의되지 않은 함수가 다른 엔트리 포인트로 들어오려 하면 인텔의 하드웨어가 보호하는 역할을 한다.

 

이를 통해 REE에서 사용할 수 있는 코드, TEE에서 사용할 수 있는 코드를 나누고 각 사이드에 대해 개발을 진행하게 된다.

 

이 둘의 코드는 각각의 환경에서 빌드되며 REE 용으로는 exe와 같은 실행 파일, TEE 용으로는 dll과 같은 dynamic 라이브러리로 산출된다.

Switch to Trusted code

 

REE 쪽 코드에서 TEE 코드를 호출하려면 enclave 생성 함수를 호출하여 enclave에서 trusted function을 호출하도록 한다.

TEE의 표준화 동향

글로벌플랫폼은 아키텍처와 API를 중심으로 표준화를 진행하고 있으며, 최근에는 사용자 인터페이스에서 TEE의 기능을 제공하는 표준화가 이뤄지고 있다.

 

또한 OP-TEE와 같은 오픈소스 프로젝트도 이뤄지고 있다. 깃허브

 

IETF에서는 provisioning에 대한 프로토콜의 표준화를 진행하고 있으며 그 이름은 Open Trusted Protocol이다.

 

출처

이 포스트는 기본적으로 아래 유튜브 영상을 기반으로 만들었다.

 

https://youtu.be/wQ29tyzcXgg?si=Sg_2XhDjUyDuQswH

 

추가로 이미지 자료를 참고하기 위해 ARM이나 인텔의 문서를 참고했다.

 

https://www.google.com/url?sa=t&source=web&rct=j&opi=89978449&url=https://documentation-service.arm.com/static/5f212796500e883ab8e74531&ved=2ahUKEwjGp8fDz-WLAxXne_UHHdWaIIoQFnoECAQQAQ&usg=AOvVaw1Pe2c9ygxbbg8PjsGQV9XZ

 

https://www.google.com/url?opi=89978449&rct=j&sa=t&source=web&url=https%3A%2F%2Fdocumentation-service.arm.com%2Fstatic%2F5f212796500e883ab8e74531&usg=AOvVaw1Pe2c9ygxbbg8PjsGQV9XZ&ved=2ahUKEwjGp8fDz-WLAxXne_UHHdWaIIoQFnoECAQQAQ

 

www.google.com

 

https://globalplatform.org/wp-content/uploads/2022/05/GPD_SPE_009-GPD_TEE_SystemArchitecture_v1.3_PublicRelease_signed.pdf

 

https://tianocore-docs.github.io/Understanding_UEFI_Secure_Boot_Chain/draft/secure_boot_chain_in_uefi/uefi_secure_boot.html#2-1-uefi-secure-boot

 

UEFI Secure Boot · GitBook

UEFI Secure Boot UEFI Secure Boot is a feature defined in the UEFI Specification. It guarantees that only valid 3rd party firmware code can run in the Original Equipment Manufacturer (OEM) firmware environment. UEFI Secure Boot assumes the system firmware

tianocore-docs.github.io

 

https://www.intel.com/content/www/us/en/content-details/671314/supporting-third-party-attestation-for-intel-software-guard-extensions-data-center-attestation-primitives.html

 

Supporting Third Party Attestation for Intel® Software Guard Extensions Data Center Attestation Primitives

Intel® Software Guard Extensions (SGX) has an attestation and sealing capability that can be used to remotely provision secrets and secure secrets to an enclave. Intel describes how Intel® Enhanced Privacy Identifier (EPID) based attestation keys are pro

www.intel.com

 

728x90

'정보보안' 카테고리의 다른 글

TLS(Transport Layer Security)  (0) 2025.03.01
AUTOSAR SecOC 알아보기  (0) 2025.02.27
MACsec 알아보기 (802.1AE)  (0) 2025.02.26