TEE 비교 분석 — OP-TEE·ARM CCA·SGX

#한 줄 요약

“TEE는 TrustZone이라는 방 위에 짓는 건물입니다.” — Secure World라는 격리된 메모리 영역 위에 별도의 OS(OP-TEE)가 동작하고, 그 위에서 Trusted Application(TA)이 키 조작·결제·DRM 같은 민감한 작업을 수행합니다. Rich OS(Linux)는 TEE Client API로 TA를 호출만 할 수 있을 뿐, 안을 볼 수는 없습니다.

#왜 TEE라는 또 한 층이 필요한가

Ch 4의 TrustZone은 분리 메커니즘입니다. 메모리·peripheral·interrupt에 NS 라벨을 붙여 secure side가 non-secure side로부터 보호됩니다. 그런데 그 안에서 무엇이 동작하는지는 별개의 문제입니다.

Secure side에 bare-metal 코드 하나만 두는 것도 가능하지만, 실무에서는 보통 여러 서로 다른 secure 서비스가 필요합니다. 펌웨어 서명 검증, 디스크 암호화 키 관리, DRM 라이선스 검사, mobile payment, 생체 인증 등이 한 디바이스에 다 있습니다. 이것들을 모두 한 덩어리로 만들면 한 서비스의 버그가 다른 서비스의 키를 노출시킵니다.

TEE는 secure side에 경량 OS를 깔고 *각 서비스를 격리된 TA(Trusted Application)*로 동작시키는 아키텍처입니다. TA들은 secure OS의 스케줄러 위에서 separate하게 돌고, secure storage를 통해 서로의 데이터에 직접 접근하지 못합니다.

GlobalPlatform이라는 표준화 단체가 TEE의 인터페이스를 정의했고, 가장 널리 쓰이는 오픈 소스 구현이 Linaro의 OP-TEE입니다.

#OP-TEE 아키텍처

OP-TEE의 전체 구조를 한 장으로 보면 다음과 같습니다.

각 부분의 역할:

• CA (Client Application) — non-secure에서 동작하는 일반 process. TEE Client API로 TA에 요청을 보냅니다.
• OP-TEE Linux driver — /dev/tee0을 노출하고, ioctl을 SMC로 변환합니다.
• BL31 Secure Monitor — ARM Trusted Firmware가 SMC를 받아 OP-TEE OS로 디스패치합니다.
• OP-TEE OS — S-EL1에서 동작하는 microkernel. TA를 elf로 load하고 S-EL0에서 실행합니다.
• TA (Trusted Application) — 실제 보안 로직. ELF binary 형태이고 GP TEE Internal API로 OS 기능에 접근합니다.
• pTA (Pseudo-TA) — TA처럼 보이지만 OP-TEE OS 안에 직접 link된 kernel-mode 모듈. peripheral 직접 접근이 필요할 때.

#REE와 TEE — 두 세계의 약속

REE(Rich Execution Environment)는 Linux + application 세계, TEE는 OP-TEE + TA 세계입니다. 둘 사이의 약속은 GlobalPlatform이 정의합니다.

CA는 UUID로 식별되는 TA에 세션을 열고 명령을 보냅니다. 한 TA에 여러 세션을 열 수 있고, 각 세션은 독립된 컨텍스트를 가집니다.

#TEE Client API — REE 측 호출 예제

다음은 CA가 AES 암호화 TA를 호출하는 예제입니다.

1
#include <tee_client_api.h>
2
#include <stdio.h>
3

4
// TA의 UUID — TA 빌드 시 정해서 양쪽이 공유
5
#define AES_TA_UUID \
6
    { 0x5b9e0e40, 0x2636, 0x11e1, \
7
      { 0xad, 0x9e, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x1b } }
8

9
// TA가 지원하는 명령 — 양쪽이 공유하는 헤더에서 정의
10
#define CMD_AES_ENCRYPT 1
11

12
int main(void) {
13
    TEEC_Context  ctx;
14
    TEEC_Session  sess;
15
    TEEC_Operation op;
16
    TEEC_UUID     uuid = AES_TA_UUID;
17
    TEEC_Result   rc;
18
    uint32_t      err_origin;
19

20
    uint8_t plain[64]  = { /* 평문 */ };
21
    uint8_t cipher[64];
22

23
    // 1. TEE와 연결
24
    rc = TEEC_InitializeContext(NULL, &ctx);
25
    if (rc != TEEC_SUCCESS) return -1;
26

27
    // 2. TA에 세션 열기
28
    rc = TEEC_OpenSession(&ctx, &sess, &uuid,
29
                          TEEC_LOGIN_PUBLIC, NULL, NULL, &err_origin);
30
    if (rc != TEEC_SUCCESS) goto out_ctx;
31

32
    // 3. 명령 인자 준비 — 4개의 named parameter
33
    memset(&op, 0, sizeof(op));
34
    op.paramTypes = TEEC_PARAM_TYPES(TEEC_MEMREF_TEMP_INPUT,
35
                                     TEEC_MEMREF_TEMP_OUTPUT,
36
                                     TEEC_NONE, TEEC_NONE);
37
    op.params[0].tmpref.buffer = plain;
38
    op.params[0].tmpref.size   = sizeof(plain);
39
    op.params[1].tmpref.buffer = cipher;
40
    op.params[1].tmpref.size   = sizeof(cipher);
41

42
    // 4. 명령 호출 — 여기서 SMC가 발사돼 TEE로 들어감
43
    rc = TEEC_InvokeCommand(&sess, CMD_AES_ENCRYPT, &op, &err_origin);
44
    if (rc != TEEC_SUCCESS) {
45
        fprintf(stderr, "Invoke failed: 0x%x origin 0x%x\n", rc, err_origin);
46
    }
47

48
    // 5. 정리
49
    TEEC_CloseSession(&sess);
50
out_ctx:
51
    TEEC_FinalizeContext(&ctx);
52
    return rc;
53
}

TEEC_InvokeCommand가 호출되는 순간 다음 일이 일어납니다.

1. libteec가 ioctl(/dev/tee0, TEE_IOC_INVOKE, ...)
2. OP-TEE Linux driver가 SMC 발사 (smc #0)
3. EL3 BL31이 받아 OP-TEE OS로 world switch
4. OP-TEE core가 UUID로 TA를 찾아 (이미 load 안 됐으면 load)
5. TA의 invoke entry를 호출
6. TA가 작업 후 return
7. OP-TEE core가 결과를 REE 측 driver에 RPC로 전달
8. 다시 SMC return → ioctl return → libteec return

이 round trip의 latency는 platform에 따라 다르지만 일반적으로 수십 µs입니다. AES 한 블록을 호출하면 blocksize/latency가 압도적으로 latency가 큽니다. 따라서 큰 단위로 호출하는 것이 효율적입니다.

#TA 개발 — Hello World

TA는 ELF binary로, OP-TEE OS가 S-EL0에서 동작시키는 일종의 user space process입니다. 빌드는 optee_os/ta/의 toolchain을 씁니다.

기본 TA의 entry point들:

1
#include <tee_internal_api.h>
2

3
#define CMD_AES_ENCRYPT 1
4

5
// TA 생성 시 한 번
6
TEE_Result TA_CreateEntryPoint(void) {
7
    DMSG("TA created");
8
    return TEE_SUCCESS;
9
}
10

11
// TA 종료 시 한 번
12
void TA_DestroyEntryPoint(void) {
13
    DMSG("TA destroyed");
14
}
15

16
// 새 세션이 열릴 때
17
TEE_Result TA_OpenSessionEntryPoint(uint32_t param_types,
18
                                    TEE_Param params[4],
19
                                    void **sess_ctx) {
20
    *sess_ctx = NULL;
21
    return TEE_SUCCESS;
22
}
23

24
// 세션이 닫힐 때
25
void TA_CloseSessionEntryPoint(void *sess_ctx) {
26
    (void)sess_ctx;
27
}
28

29
// 명령 dispatch
30
TEE_Result TA_InvokeCommandEntryPoint(void *sess_ctx,
31
                                       uint32_t cmd_id,
32
                                       uint32_t param_types,
33
                                       TEE_Param params[4]) {
34
    (void)sess_ctx;
35
    switch (cmd_id) {
36
    case CMD_AES_ENCRYPT:
37
        return do_aes_encrypt(param_types, params);
38
    default:
39
        return TEE_ERROR_BAD_PARAMETERS;
40
    }
41
}

실제 AES 작업은 OP-TEE Internal API로 합니다.

1
static TEE_Result do_aes_encrypt(uint32_t param_types, TEE_Param params[4]) {
2
    const uint32_t expected = TEE_PARAM_TYPES(
3
        TEE_PARAM_TYPE_MEMREF_INPUT,
4
        TEE_PARAM_TYPE_MEMREF_OUTPUT,
5
        TEE_PARAM_TYPE_NONE, TEE_PARAM_TYPE_NONE);
6

7
    if (param_types != expected) return TEE_ERROR_BAD_PARAMETERS;
8

9
    void  *in  = params[0].memref.buffer;
10
    size_t in_len = params[0].memref.size;
11
    void  *out = params[1].memref.buffer;
12
    size_t out_len = params[1].memref.size;
13

14
    // 1. 키 객체 생성
15
    TEE_ObjectHandle key;
16
    TEE_AllocateTransientObject(TEE_TYPE_AES, 128, &key);
17

18
    uint8_t key_material[16];
19
    // secure storage에서 키를 읽어 채우거나, fixed key를 사용
20
    load_device_key(key_material);
21

22
    TEE_Attribute attr;
23
    TEE_InitRefAttribute(&attr, TEE_ATTR_SECRET_VALUE, key_material, 16);
24
    TEE_PopulateTransientObject(key, &attr, 1);
25

26
    // 2. 암호화 operation
27
    TEE_OperationHandle op;
28
    TEE_AllocateOperation(&op, TEE_ALG_AES_CTR, TEE_MODE_ENCRYPT, 128);
29
    TEE_SetOperationKey(op, key);
30

31
    uint8_t iv[16] = { /* random */ };
32
    TEE_CipherInit(op, iv, sizeof(iv));
33

34
    TEE_Result rc = TEE_CipherDoFinal(op, in, in_len, out, &out_len);
35

36
    // 3. 정리
37
    TEE_FreeOperation(op);
38
    TEE_FreeTransientObject(key);
39
    TEE_MemFill(key_material, 0, sizeof(key_material));  // zeroize
40

41
    params[1].memref.size = out_len;
42
    return rc;
43
}

TA의 manifest는 user_ta_header_defines.h에서 정의합니다.

1
#define TA_UUID \
2
    { 0x5b9e0e40, 0x2636, 0x11e1, \
3
      { 0xad, 0x9e, 0x00, 0x02, 0xa5, 0xd5, 0xc5, 0x1b } }
4

5
#define TA_FLAGS                  (TA_FLAG_EXEC_DDR | TA_FLAG_SINGLE_INSTANCE)
6
#define TA_STACK_SIZE             (4 * 1024)
7
#define TA_DATA_SIZE              (32 * 1024)
8

9
#define TA_VERSION                "1.0"
10
#define TA_DESCRIPTION            "AES encryption TA"

빌드는 OP-TEE의 TA dev kit을 씁니다.

1
export TA_DEV_KIT_DIR=/opt/optee_os/out/arm-plat-vexpress/export-ta_arm64
2
export CROSS_COMPILE_TA=aarch64-linux-gnu-
3

4
make -C ta O=out
5

6
# 결과: out/5b9e0e40-2636-11e1-ad9e-0002a5d5c51b.ta

생성된 .ta 파일은 OP-TEE의 secure signed 형식입니다. OP-TEE OS는 부팅 시 등록된 TA 서명 키로 검증한 뒤에만 load합니다.

#Secure Storage — TA가 데이터를 저장하는 방법

TA는 자기만의 영구 저장소를 가질 수 있습니다. GP TEE Internal API의 Trusted Storage입니다.

1
TEE_ObjectHandle obj;
2
const char     id[] = "user_credential_v1";
3

4
// 새 객체 생성 또는 기존 객체 열기
5
TEE_Result rc = TEE_OpenPersistentObject(
6
    TEE_STORAGE_PRIVATE,
7
    id, sizeof(id) - 1,
8
    TEE_DATA_FLAG_ACCESS_READ | TEE_DATA_FLAG_ACCESS_WRITE,
9
    &obj);
10

11
if (rc == TEE_ERROR_ITEM_NOT_FOUND) {
12
    uint8_t initial[64] = { /* 초기값 */ };
13
    TEE_CreatePersistentObject(
14
        TEE_STORAGE_PRIVATE,
15
        id, sizeof(id) - 1,
16
        TEE_DATA_FLAG_ACCESS_READ | TEE_DATA_FLAG_ACCESS_WRITE,
17
        TEE_HANDLE_NULL,
18
        initial, sizeof(initial),
19
        &obj);
20
}
21

22
uint8_t buf[64];
23
uint32_t bytes_read;
24
TEE_ReadObjectData(obj, buf, sizeof(buf), &bytes_read);
25

26
TEE_CloseObject(obj);

저장 위치는 플랫폼별입니다.

• RPMB partition — eMMC의 Replay Protected Memory Block. eMMC controller가 monotonic counter로 replay 방어. 가장 안전.
• REE filesystem — Linux의 /data/tee/ 같은 디렉터리. OP-TEE가 암호화 + 인증해서 저장. REE가 파일을 삭제할 수는 있지만 내용을 읽을 수는 없음.
• Secure storage of SE — 외부 secure element. 일부 플랫폼.

TA마다 키가 다릅니다. OP-TEE의 Trusted Key Derivation이 huk(hardware unique key) + TA UUID로 storage key를 유도하므로, 한 TA의 secure storage 파일을 다른 TA가 열어도 복호화 못 합니다.

#Build & test workflow

OP-TEE 전체 빌드의 흐름은 다음과 같습니다.

1
# manifest 기반 통합 빌드 (Linaro repo)
2
mkdir optee && cd optee
3
repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
4
repo sync -j8
5

6
# 빌드 — toolchain까지 자동
7
cd build
8
make -j$(nproc) toolchains
9
make -j$(nproc) all
10

11
# QEMU로 실행
12
make run-only

부팅 후 두 개의 콘솔이 뜹니다. 하나는 normal world Linux, 다른 하나는 secure world OP-TEE. Linux에서 example TA를 호출해 봅니다.

1
# normal world
2
$ xtest                 # 전체 회귀 테스트
3
$ optee_example_hello_world
4
D/TC:? 0 main:39 Invoke command
5
D/TC:? 0 main:65 hello world
6

7
$ optee_example_aes
8
D/TC:? 0 prepare_aes:131 Prepare encode operation
9
D/TC:? 0 set_aes_key:153 Load key in TA
10
D/TC:? 0 cipher_buffer:222 Encrypt buffer from TA
11
Text successfully encrypted/decrypted

xtest는 GlobalPlatform compliance test의 일부를 포함해 약 50,000개 테스트를 돌립니다. 새 platform port의 검증에 표준으로 쓰입니다.

#ARM CCA — Confidential Compute Architecture

ARMv9-A의 새로운 보안 아키텍처가 CCA(Confidential Compute Architecture)입니다. TrustZone과 완전히 다른 추가 차원의 격리를 도입합니다.

1
                    Non-secure           Secure        Realm        Root
2
  EL3 (Monitor)  ────────────────────────────────────────────────── Root
3
  EL2 (Hyper)    │ KVM/Xen        │ Secure Partition │ RMM       │
4
  EL1 (OS)       │ Linux           │ OP-TEE OS        │ Realm OS  │
5
  EL0 (User)     │ Apps            │ TAs              │ Realm     │
6
                                                       Apps

기존 두 세계(Non-secure, Secure)에 Realm world와 Root world가 추가됩니다.

• Realm world — 사용자가 만든 confidential VM. 호스트 hypervisor가 메모리를 볼 수 없음.
• Root world — 위 세 세계 모두를 monitor하는 EL3 펌웨어 세계.

Realm은 원격 attestation과 암호화된 메모리를 받아, 클라우드의 multi-tenant 환경에서 host operator도 못 보는 VM을 만들 수 있게 합니다. Intel SGX, AMD SEV, NVIDIA H100 confidential compute의 ARM 대응입니다.

CCA의 핵심 컴포넌트:

• RMM (Realm Management Monitor) — Realm world의 R-EL2 펌웨어. 메모리 ownership 관리.
• GPC (Granule Protection Check) — 4KB granule 단위로 어느 world가 소유하는지를 하드웨어가 강제.
• Attestation — RMM이 발행하는 cryptographic evidence가 realm의 무결성을 원격으로 증명.

CCA는 2026년 현재 ARMv9.2-A 일부 SoC에 처음 양산되기 시작했고, 향후 5~10년에 걸쳐 모바일·서버 양 쪽에 확산할 것으로 예상됩니다.

#Intel SGX / AMD SEV / NVIDIA CC 비교

ARM CCA와 같은 confidential compute 카테고리의 다른 접근들입니다.

Intel SGX의 한 시기 큰 인기에 비해, 산업의 흐름은 VM 단위 confidential compute로 옮겨가는 추세입니다. 그 이유는 기존 application을 거의 그대로 돌릴 수 있기 때문입니다. SGX는 application을 enclave에 맞게 재작성해야 했습니다.

#자주 하는 실수

• TA를 작은 호출 단위로 자주 invoke합니다. SMC round trip이 수십 µs라 throughput이 떨어집니다. 배치해서 큰 단위로 호출합니다.
• TA의 stack/heap을 작게 잡습니다. TA는 default heap이 수 KB 수준입니다. crypto 작업에 충분치 않아 TEE_ERROR_OUT_OF_MEMORY가 납니다. manifest에서 TA_STACK_SIZE, TA_DATA_SIZE를 적절히 늘립니다.
• REE 측 포인터를 TA가 직접 dereference합니다. GP API의 memref는 OP-TEE OS가 shared memory로 mapping해 줍니다. mapping 안 된 raw 포인터는 secure fault를 일으킵니다. 인자는 params[i].memref로만 접근합니다.
• TA의 secure storage를 백업 안 합니다. RPMB든 REE filesystem이든 파일 자체를 잃을 수 있습니다. 중요한 키는 KMS로 sealed back-up하거나, 키 회전 정책으로 잃어도 복구 가능하게 설계합니다.
• xtest를 안 돌리고 platform port를 commit합니다. OP-TEE는 platform-specific 코드가 매우 많아, xtest 통과 여부가 port 완성도의 거의 유일한 객관적 척도입니다.
• TA 서명 키를 제품 빌드와 개발 빌드가 공유합니다. 개발 키로 서명된 TA가 양산 디바이스에 load되지 않도록 빌드 시스템에서 분리합니다.
• CCA realm 안에서 host I/O를 무조건 신뢰합니다. realm은 메모리는 격리되지만 I/O는 host hypervisor가 매개합니다. 디스크 데이터는 realm 안에서 따로 암호화·인증해야 합니다.

#정리

• TEE는 TrustZone 위에 secure OS를 깔고 격리된 Trusted Application들을 동작시키는 아키텍처입니다.
• OP-TEE는 Linaro의 오픈 소스 TEE OS로, ARM Trusted Firmware의 BL32 자리에 들어가 S-EL1에서 동작합니다.
• REE(Linux)와 TEE 사이의 인터페이스는 GlobalPlatform TEE Client API와 TEE Internal API로 표준화돼 있습니다.
• TA는 ELF binary이며 UUID로 식별되고, REE의 CA가 세션을 열어 명령을 invoke하는 방식으로 호출됩니다.
• Secure storage는 RPMB(가장 안전), REE filesystem(암호화·인증), secure element 중 하나에 저장됩니다.
• ARM CCA는 ARMv9-A의 새 보안 아키텍처로, Realm world와 GPC로 confidential VM을 가능하게 합니다.
• Intel SGX/TDX, AMD SEV-SNP, NVIDIA H100 CC가 같은 confidential compute 카테고리의 경쟁 기술입니다.
• TEE 활용의 핵심은 secure storage·키 관리·attestation 세 service의 조합이며, 결제·DRM·생체 인증·fTPM 같은 영역에서 표준화돼 있습니다.

다음 편은 Ch 6: OTA 업데이트 — 안전한 펌웨어 배포. 지금까지 다진 secure boot·crypto·TEE 기반 위에서, 양산 디바이스에 펌웨어를 원격으로 안전하게 갱신하는 메커니즘을 봅니다.

#관련 항목

• Ch 2: Secure Boot — 부트 체인 검증
• Ch 3: MCU 크립토 — HW accelerator
• Ch 4: TrustZone — Cortex-A / Cortex-M
• Ch 6: OTA 업데이트
• Ch 7: 사이드채널 공격
• Practical RTOS Internals — Part 4-11: TrustZone & TF-M
• AUTOSAR Adaptive — 차량 보안
• DO-178C — 항공 SW 보증