SofTEE: A Software Framework to Support Trusted Execution Environment for User Applications = 유저 어플리케이션을 위한 소프트웨어 TEE 프레임워크 구성

다국어 초록 (Multilingual Abstract)

Commodity operating system kernels, such as the Linux kernel, are considered vulnerable due to many bugs. Most commodity OSes are also based on monolithic kernels, which can be easily compromised, and attackers gain complete control over all kernel functionalities. Therefore, when an application handles security sensitive
data, it is highly recommend to execute the application in a trusted execution environment. In response to this demand, hardware trusted execution environments such as Intel SGX and ARM TrustZone have been developed by major CPU vendors. However, these trusted execution environments have several limitations. In the case of Intel SGX, CPU update is essential to address design vulnerabilities or to reflect customer feedback. In the case of ARM TrustZone, the CPU provides only a single isolated execution environment called the secure
world. When ARM TrustZone is freely opened to third-party developers, the attack surface of ARM TrustZone is expanded.
In this paper, we propose a software framework called SofTEE to support a trusted execution environment (TEE) for user applications. Unlike conventional hardware-based TEEs, SofTEE has some advantages. 1) Architecture independence, 2) ease of update, 3) low overhead for memory isolation, 4) unrestricted use of memory isolation, and 5) commodity-machine support.
Designing and implementing SofTEE involves several challenges. First, SofTEE should support memory isolation and attestation. For memory isolation, SofTEE depends on kernel deprivileging which delegates the execution of privileged operations such as memory management, from a kernel to a special module called a security monitor. To reduce the overhead of switching between the deprivileged kernel and the security monitor, SofTEE proposes an ecient management mechanism of the address space identier. SofTEE supports attestation by assuming minimal hardware functionalities of random entropy and root of trust. Next, SofTEE should independently handle and manage trusted applications. Lastly, SofTEE should guarantee security properties like condentiality and integrity of trusted applications. For security analysis, we have identied security invariants that SofTEE should meet for condentiality and integrity guarantees. Based on the security invariants, we have designed and prototyped each component of SofTEE on a Raspberry Pi 3 board. To measure SofTEE performance, we executed several real-world benchmarks. SofTEE produces about 3% overhead in case of a trusted application with long execution time (called Notary) and at most 34% overhead in case of a trusted application with short execution time (called PassHash and one-time password (OTP)).

국문 초록 (Abstract)

유저 어플리케이션이 보안에 민감한 데이터를 접근 할 경우 신뢰 할 수 있는 실행 환경(TEE)이 필요하다. 이는 악의적인 사용자로부터 보안에 민감한 데이터를 보호하기 위한 방법이다. 이러한 요구에 맞게 다양한 CPU 하드웨어 제조사는 신뢰 할 수 있는 실행 환경을 제공하였다. 대표적인 예로 Intel CPU의 경우 SGX ARM의 경우 TrustZone이라는 기술을 개발하였다. 각각의 신뢰 할 수 있는 실행 환경은 악의적인 공격자에게 감염 될 수 있는 커널로부터 유저 어플리케이션을 안전하게 보호한다. 하지만 기존의 하드웨어를 통한 신뢰 할 수 있는 실행 환경은 몇가지 한계점들을 가진다. 대표적인 예로 Intel SGX의 경우 하드웨어에만 의존하는 시스템이기 때문에 모든 업데이트시에 CPU 교체가 요구 된다. 이는 어마어마한 비용이 들 뿐 아니라 보안 문제가 발생 할 경우 빠르게 대처하지 못한다는 단점을 가진다. ARM의 TrustZone의 경우는 secure world라고 불리는 안전한 실행 환경을 오직 하나만 제공한다. 그렇기 때문에 secure world에 실행되는 유저 어플리케이션은 ARM TrustZone을 공격하는 용도로 사용 될 수 있다. 이러한 문제를 막기 위해서 모바일 환경의 경우 secure world 자체를 일반 사용자에게 공개하지 않는다.

본 논문에서는 기존의 하드웨어를 통한 신뢰 할 수 있는 실행 환경이 가지는 한계점을 극복하기 위해서 소프트웨어를 통한 신뢰 할 수 있는 실행 환경 기법을 제시한다. 소프트웨어를 통한 신뢰 할 수 있는 실행 환경 기법의 경우 다음과 같은 장점들을 가진다. 첫 번째, 업데이트가 용이하다. 두 번째, 메모리 분할을 위한 오버헤드가 작다. 세 번째, 기존의 하드웨어를 통한 신뢰 할 수 있는 실행 환경의 공격 범위를 넓히지 않는다. 네 번째 하드웨어 수정이 필요 없다. 마지막으로 다양한 CPU 에 적용 가능하다.

신뢰 할 수 있는 실행 환경을 구성하기 위해서는 기본적으로 메모리 분할과 검증 기법이 필요하다. 메모리 분할의 경우 악의적인 공격자가 접근 할 수 없는 곳에 유저 어플리케이션을 위치 시키는 것이고 검증은 유저 어플리케이션이 구동 전에 악의적인 공격자에 의해서 무결성이 깨졌는지 확인하는 작업이다. 메모리 분할의 경우 본 논문에서는 커널 권한 제거 기법을 통해서 구현하였다. 커널 권한 제거 기법은 커널이 가지고 있는 다양한 권한 중에서 메모리 관리 권한을 제거하는 것이다. 커널로 부터 해당 권한을 제거하기 위해서 본 논문에서는 바이너리 스캐닝과 새도우 페이지 테이블을 사용하였다. 커널 권한 제거를 통해서 시스템은 논리적으로 일반 모드와 안전 모드로 나누어진다. 일반 모드의 경우 기존의 커널과 일반 어플리케이션들이 실행 되는 환경이고, 안전 모드는 추가 된 커널 모듈인 security monitor와 신뢰 할 수 있는 어플리케이션이 실행 되는 환경이다. 이 때 security monitor라고 불리는 안전 모듈은 독립적으로 주소 공간 아이디 (ASID)를 관리 함으로써 일반 모드와 안전 모드 간에 주소 공간을 완전히 분리 하였다. 또한 이는 TLB 캐쉬에 올라가는 ASID를 분리하기 때문에 일반 모드와 안전 모드 간에 변환 시 캐쉬를 비우는 작업을 생략 할 수 있다. 이것은 모드 전환 시에 상당한 성능 향상을 가져다 준다.

검증의 경우 본 논문에서는 기본적으로 최소한의 하드웨어 도움을 가정한다. 이는 난수 생성과 Root-of-trust의 경우 소프트웨어로 구현하는 것에 한계가 있기 때문이다. 실제 구현에서는 하드웨어 혹은 소프트웨어 신뢰 모듈 (TPM)을 이용하여 난수 생성과 Root-of-trust를 제공 받았다.

본 논문에서는 시스템의 안전성을 도모하기 위해서 7가지의 안전 불변을 정의 하였다. 그리고 7가지 불변에 기초하여 시스템을 디자인 구현하였다. 또한 7가지 불변을 통하여 유저 어플리케이션의 무결성과 기밀성을 보장함을 보였다. 마지막으로 실제 사용되는 어플리케이션을 테스트 함으로서 시스템의 성능과 정상 작동을 보였다.

목차 (Table of Contents)

• I. Introduction 1
• II. Background 5
• 2.1 Hardware-based TEE . . . . . . . . . . . . . . . . . . . . . . . . . 5
• 2.2 Software Memory Isolation . . . . . . . . . . . . . . . . . . . . . . 8
• III. Threat Model and Assumptions 11
• IV. SofTEE Design 13
• 4.1 Memory Isolation by Kernel Deprivileging . . . . . . . . . . . . . . 13
• 4.2 Entry and Exit Gates . . . . . . . . . . . . . . . . . . . . . . . . . 20
• 4.3 TA Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
• 4.4 TA Service Handler . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
• 4.5 Cache Side-Channel Attack . . . . . . . . . . . . . . . . . . . . . . 32
• V. SofTEE Implementation 35
• 5.1 Security Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
• 5.2 Minimum Hardware Support . . . . . . . . . . . . . . . . . . . . . 37
• VI. Security Analysis 39
• 6.1 Security Invariants . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
• 6.2 Supporting Invariants . . . . . . . . . . . . . . . . . . . . . . . . . 40
• 6.3 Condentiality and Integrity . . . . . . . . . . . . . . . . . . . . . . 42
• VII. Performance Evaluation 45
• 7.1 Micro-benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
• 7.2 Real Workload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
• VIII.Discussion 53
• 8.1 Cost of Manual Eort . . . . . . . . . . . . . . . . . . . . . . . . . 53
• 8.2 Dependency on Hardware . . . . . . . . . . . . . . . . . . . . . . . 53
• 8.3 Advanced development environment . . . . . . . . . . . . . . . . . 54
• 8.4 Formal Verication . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
• 8.5 Security Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
• 8.6 Performance Optimization . . . . . . . . . . . . . . . . . . . . . . . 58
• 8.7 Comparison with Hardware-based TEEs . . . . . . . . . . . . . . . 59
• IX. Conclusion 61
• APPENDIX 63
• Summary (in Korean) 64
• References 67