Study on Migration and Adaptation of TEE Environment to AVF

TEE 환경의 AVF 기반 전환 및 적용 연구

Abstract

The ARM TrustZone-based TEE(Trusted Execution Environment) has provided hardware-level security and fulfilled Android's security requirements. However, it faces limitations due to the increasing TCB(Trusted Computing Base) and fragmentation issues. To address these challenges, Android 13 introduced the AVF(Android Virtualization Framework), which provides isolated execution environments. Nevertheless, AVF does not consider compatibility with existing TEE-based applications, making migration difficult. In this study, we extend the existing Open-TEE research that emulates GP(GlobalPlatform) compatible APIs to AVF-based, and validate the proposed system through experiments in terms of security, compatibility, performance, and ease of adaptation. The results demonstrate the feasibility of porting existing CA(client application) and TA(trusted application) to AVF environments with minimal modifications.

기존 ARM TrustZone 기반 TEE(Trusted Execution Environment)는 하드웨어 수준의 보안을 제공하며 안드로이드의 보안 요구사항을 충족해왔으나, TCB(Trusted Computing Base)의 증가 및 파편화 문제로 인해 한계에 직면해 있다. 이를 보완하기 위해 Android 13에서는 AVF(Android Virtualization Framework)를 도입했으나, 기존 TEE 기반 애플리케이션과의 호환성이 고려되지 않아 이식이 어렵다. 본 연구에서는 GP(GlobalPlatform) 호환 API를 에뮬레이션하는 기존 Open-TEE 연구를AVF 기반으로 확장하고, 보안성, 호환성, 성능 및 적용 용이성 측면에서의 실험을 통해 제안 시스템의 유효성을 검증하였다. 이를 통해, 기존의 CA(Client Application)와 TA(Trusted Application)를 최소한의 수정으로 AVF 환경에 이식하는 가능성을 제시한다.

I. 서론

현대 안드로이드 모바일 서비스 시장은 지속적으로 발전하고 있다. 이에 따라, 모바일 기기는 점점 더 다양한 서비스와 민감한 데이터를 처리하게 되면서, 보다 강력하고 유연한 보안환경이 필수적으로 요구된다.

전통적으로 ARM의 TrustZone 기반 TEE는 하드웨어 수준에서 SW(Secure World)와 NW(Normal World)를 분리하여 높은 보안성을 제공해 왔다[10]. 이를 통해, 서비스를 일반 연산과 보안이 중요한 연산을 분리하고, 격리된 공간에서 각각 수행하도록 구성하여 보안이 중요한 기능을 안전하게 운영할 수 있다. 그러나 SW와 NW의 이분법적인 분할과 SW에 부여된 과도한 권한으로 인해 취약점이 발생하면 시스템 전체가 위협받을 수 있으며, 파편화에 따른 유지보수의 복잡성 등 다양한 문제에 직면해 있다[1].

이러한 문제를 해결하고 더욱 유연한 보안 환경을 제공하기 위해, 구글은 Android 13에서는 AVF를 도입하였다[7]. AVF는 pKVM(Protected Kernelbased Virtual Machine) 하이퍼바이저를 기반으로 보호된 가상 머신(pVM)을 구성하여, 호스트와 게스트 사이뿐만 아니라 게스트와 게스트 사이의 상호 신뢰하지 않는 격리된 실행 환경을 제공한다. 그러나 AVF는 기존의 TEE의 역할을 대체하거나 호환성을 염두에 둔 기능이 아니기 때문에 기존 TEE를 기반으로 구현된 서비스를 새로운 환경에서 그대로 활용할 수 없다.

본 연구는 TrustZone 기반 TEE의 한계를 이야기하며, 기존 TEE 기반 애플리케이션을 AVF 기반의 실행 환경으로 원활한 이주 방안을 모색하는 데 초점을 맞추고 있다. 이를 위하여, 기존 소프트웨어 기반의 Open-TEE[2]을 AVF 기반으로 확장하여 호스트와 게스트 간의 격리된 실행 환경으로 분리할 수 있는 아키텍처를 제안한다. 이를 통해 기존 GP 호환 TEE API 기반으로 개발된 CA와 TA의 코드 베이스를 유지하면서도, AVF 환경에서도 안정적인 TEE 기능을 제공할 수 있도록 한다.

본 논문에서는 먼저 기존 TrustZone 기반 TEE 및 AVF의 배경지식과 문제점, 그리고 관련 연구의 한계 등을 서술한다. 이를 기반으로 제안하는 새로운 아키텍처를 설명한 후, 제안된 시스템의 설계 및 구현 방안을 구체적으로 기술하며, Pixel 6 기기를 대상으로 보안성, API 호환성, 성능 및 적용 용이성 측면에서 실험을 수행하여 아키텍처의 유효성을 검증한다. 마지막으로, 연구 결과를 바탕으로 기존 TEE 환경과 AVF 환경 간의 원활한 전환 가능성을 제시하고, 향후 연구를 서술하며 마무리한다.

II. 배경 및 관련 연구

2.1 TrustZone

TrustZone은 ARM에서 개발한 하드웨어 기반 보안 기술로, 프로세서 내에 TEE을 제공한다[10]. 이 기술은 시스템을 SW와 NW로 격리하여 NW가 침해당하더라도 SW의 코드와 데이터가 침해되지 않도록 설계되었다. 이러한 특징을 활용하여 TrustZone 기반의 TEE는 암호 키 관리, 보안 인증, DRM 등 중요한 보안 작업을 NW와 격리하여 실행하는 데 활용되고 있다.

TrustZone은 많은 모바일 기기에서 보안 메커니즘의 기초를 수행하지만, 진화하는 모바일 서비스의 보안 요구사항을 충족하는 데 본질적인 한계가 있다. TrustZone의 보안성을 저해하는 두 가지 주요 문제는 SW에 부여된 높은 권한과 TEE의 유지보수 복잡성 증가를 들 수 있다[1, 4, 5, 6].

보안 세계에 부여된 높은 권한: TrustZone은 SW에서 실행되는 코드에 높은 수준의 권한을 부여하고 있으며, 그 예로 NW의 물리 메모리에 접근할 수 있는 보안 운영체제의 시스템 콜이 TA에 허용되어 있다. 또한, SW에서 실행되는TA조차 입력 검증 오류나 버퍼오버플로우와 같은 버그를 포함하고 있으며, 이러한 취약점은 보안 세계에 부여된 높은 권한과 결합하여 치명적인 보안 결함으로 이어질 수 있다[1, 4].

예를 들어, Widevine TA에서 발생한 버퍼오버플로우 취약점인 CVE-2015-6639는 공격자가 해당 TA의 임의 코드 실행 권한을 획득하도록 만들었다[12]. 이 상태에서 공격자는 QSEE SecureOS의 시스템 콜 인터페이스 입력값 검증 미흡으로 발생한 CVE-2016-2431을 악용하여, TA 권한만으로도 Secure OS 커널 메모리 영역을 덮어쓰는 방식으로 TEE 커널 자체를 장악할 수 있다[13].

또 다른 경로로는, TA 권한을 이용해 일반 세계(NW)의 물리 메모리를 접근할 수 있는 QSEE 시스템 콜을 악용하는 방법이 있다. 이 경우 공격자는 TA에서 NW 물리 메모리 전체를 스캔해 리눅스 커널이 로드된 영역을 찾아낸 뒤, 해당 메모리 값을 직접 패치하여 REE 커널을 완전히 장악할 수 있다[11].

TEE의 유지 보수 복잡성 증가: TrustZone 기반 TEE는 SoC(System on Chip) 업체 및 모바일 기기 제조사의 개별 구현 방식에 따라 파편화가 발생하며[5], 이는 유지보수 복잡성을 가중하는 요인으로 작용하고 있다. 모바일 서비스 시장의 고도화로 TA를 활용하는 서비스가 급증하고 있으며, 이에따라 TEE의 전체적인 TCB도 함께 증가하고 있다. 이러한 추세는 TrustZone기반의 보안 환경을 더욱 복잡하게 만들고, 유지보수를 어렵게 만들고 있다[1, 4, 5].

2.2 AVF(Android Virtualization Framework)

AVF는 모바일 환경에 유연한 보안 환경의 수요에 대응하고자 Android 13에서 도입된 가상화 기반 보안 프레임워크이다[7]. 기존의 하드웨어 기반 보안 솔루션인 TrustZone은 시스템을 SW과 NW으로 단순히 구분하는 이분법적 구조를 취함에 따라, 세밀한 격리에 한계가 있다.

운영체제로부터의 격리가 필요한 사용 사례가 늘어날수록 공격 표면이 확대되고, 취약점이 SW에 부여된 높은 권한 문제와 맞물려 모바일 기기 전체의 침해로 이어질 가능성이 높아진다. 이에 비해, AVF는 가상화 기술을 활용하여 서로 신뢰하지 않는 실행 환경 간의 독립성을 보장하고, 서비스 간 공격 위험을 효과적으로 완화할 수 있는 아키텍처를 제공한다.

Fig.1.은 AVF의 핵심 요소를 보여준다. AVF는 pKVM을 기본 하이퍼바이저로 채택하여 pVM을 관리하며 pKVM은 호스트와 각 pVM 간의 자원 접근을 엄격하게 제어함으로써, 단일 pVM 또는 호스트 시스템이 침해되더라도 다른 실행 환경의 무결성이 유지되도록 설계되었다. 이러한 설계는 세분된 격리 실행 환경을 제공하여 전통적인 TrustZone 기반 TEE의 한계를 보완한다.

Fig. 1. Android Virtualization Framework Architecture

2.3 관련 연구

Open-TEE는 기존 하드웨어 기반 TEE의 폐쇄성과 접근성 문제를 해결하고, 개발 및 디버깅 환경을 개선한 소프트웨어 기반 TEE 에뮬레이터를 제공한다[2]. 이 시스템은 GP 표준[8]을 준수하며, 일반적인 소프트웨어 개발 도구를 활용하여 TA의 개발 및 디버깅이 가능하도록 설계되었다. 이를통해, 개발자는 하드웨어에 의존하지 않고 TA의 개발 및 테스트가 가능하고, 이를 활용하여 실제 하드웨어 기반 TEE에 배포할 수 있다. 연구진은 Open-TEE를 오픈 소스로 공개하여 연구 및 실험을 위한 환경을 제공한다[9].

WhiteBox-TEE는 Open-TEE를 확장하여 보안성을 강화한 소프트웨어 기반 TEE으,Open-TEE에 화이트박스 암호화를 적용하여 기존 Open-TEE의 보안 한계를 보완한다[3]. WhiteBox-TEE는 키 보호 및 보안성을 강화하는 동시에 GP 표준을 준수하는 구조를 유지하도록 설계되었다.

그러나 기존 Open-TEE 및 WhiteBox-TEE와 같은 소프트웨어 기반 TEE 솔루션의 근본적인 한계점은 TrustZone 기반 TEE가 제공하는 보안성을 완전히 대체하지 못한다는 점이다. 구체적으로, 격리된 실행 환경을 제공하지 못한다. 따라서, 실질적인 모바일 서비스의 보안 요구사항을 만족시키며 서비스의 적용이 어렵다는 한계를 가진다.

ReZone은 SW가 가지는 과도한 권한 문제를 해결하기 위해 TEE를 여러 개의 격리된 Zone으로 분할하는 시스템을 제안하였다[6]. 그러나 SoC 업체 또는 모바일 기기 제조사에 따라 다른 TEE 구현에 의한 파편화 문제에서 여전히 자유롭지 못하다.

본 연구는 기존 연구들의 한계를 극복하고, AVF 기반의 격리된 소프트웨어 기반 TEE를 설계하여 GP 표준을 준수하면서도 격리된 실행 환경을 제공하여 보안성을 강화하는 방안을 제안한다. 이를 통해 TrustZone 기반 TEE에서 소프트웨어 기반 TEE로 TA의 이주를 장려하여 전체 TEE의 TCB를 감소시켜 TEE 전반의 보안성과 확장성을 동시에강화하는 가능성을 탐색한다.

III. 설계 및 구현

Open-TEE는 CA, LibTEE, TA, TEE Emulator로 구성된다[2]. Fig. 2.는 Open-TEE의 전체적인 구조를 나타낸다. 그림에서 볼 수 있듯이 CA와 TA가 모두 같은 실행 환경에서 실행된다. 즉, 격리된 실행 환경을 제공하지 않는다. 따라서 Open-TEE는 연구 및 실험을 위한 환경 또는 TA 개발을 위한 에뮬레이터로써 활용될 수 있으나, 보안성이 요구되는 실제 서비스 환경에서의 적용에는 제약이 따른다.

Fig. 2. Overall Architecture of Open-TEE

본 장에서는 Open-TEE를 AVF 기반에서 동작하도록 확장하여, CA와 TA가 각각 격리된 실행 환경에서 동작할 수 있는 시스템을 제안한다. 제안하는 시스템은 Open-TEE 구성요소 사이에 TEEMediator를 추가하여 두 실행 환경 사이의 제약을 조율한다. Fig.3.은 본 시스템의 전체적인 구조를 나타내며 AVF 기반 확장을 통해 CA와 TA를 독립된 실행 환경에서 운영함으로써 기존 Open-TEE의 실행 격리 부족 문제를 해결하였다.

Fig. 3. Overall Architecture of AVF based Open-TEE

제안한 설계는 CA별로 호스트와 다른 pVM과 격리되는 pVM 내 TEE 환경을 구성하여, 기존 TrustZone TEE 구조에서 개별 TA의 실패가 시스템 전반으로 전파되는 위험을 효과적으로 차단한다. 또한, GP 호환성을 유지함으로써 기존 TA를 AVF 기반 TEE로 이주하는 작업을 용이하게 한다. 이는 결과적으로 SW의 TCB 증가에 영향을 미치는 TA를 줄여 SW의 TCB 감소에 기여한다.

더불어, 기존에는 모바일 기기 제조사나 SoC 업체 등 제한된 환경에서만 가능했던 TA 개발을 보다 개방된 환경에서 수행할 수 있도록 하여, TA 개발 경험의 접근성을 크게 향상한다. 이는 TA 개발자의 전반적인 기술 성숙도를 높일 기회를 제공한다.

결과적으로, 본 설계는 모바일 단말의 보안성을 종합적으로 향상하는 동시에 개발자 접근성을 개선하여 보다 유연한 TEE 활용을 실현한다. 이를 통해 기존 시스템의 한계를 극복하고 실질적인 서비스 환경에 적용할 수 있는 새로운 방향을 제시한다.

3.1 CA(Client Application)

CA는 TEE에서 실행되는 TA와 통신하며, 보안 연산을 요청하고 결과를 전달받아 서비스를 제공하는 애플리케이션이다.

본 연구에서는 Open-TEE의 conn_test_ca를 사용하여, GP 호환 API 세트를 기반으로 TEE와의 상호작용 및 TA와의 연동을 검증하였다. 또한, CA의 기존 로직을 변경하지 않은 상태에서, CA가 참조하는 LibTEE의 인터페이스 내부 구현만을 수정하였다.

이러한 설계를 통해, 제안한 시스템의 CA는 LibTEE를 교체하는 것만으로 AVF 기반의 TEE 환경에서 일관된 동작을 보장하도록 실행 환경을 효과적으로 분리하고, CA의 코드베이스의 재사용성을 극대화할 수 있다.

3.2 LibTEE

LibTEE는 GP 호환 API 세트를 제공하는 라이브러리로, CA와 TEE 사이의 인터페이스 역할을 수행한다. 이를 통해 CA는 TEE의 내부 구현 방식과 관계없이 동일한 방식으로 TA와 통신하여 결과를 받을 수 있다. 기존 Open-TEE에서는 Unixsocket을 활용하여 동일 실행 환경에서 CA와 TEE-Engine 간의 통신을 처리한다. 그러나 Open-TEE를 AVF 기반으로 실행 환경을 분리하도록 확장하는 과정에서 두 가지 주요한 문제가 발생했다.

3.2.1 통신 프로토콜

기존 Open-TEE는 Unix socket을 이용하여 TEE-Engine과 직접 통신하는 방식으로 구현되었으나, 호스트 운영체제에서 실행되는 LibTEE와 게스트 운영체제에서 실행되는 TEE-Engine간의 직접적인 Unix socket 통신은 실행 환경의 제약으로 인해 불가능하다. 이를 해결하기 위해, 기존 Unix socket 기반 통신을 AIDL(Android Interface Definition Language) 인터페이스 기반으로 재설계하고, pVM에서 TEEMediator가 Open-TEE 데몬 프로세스와 통신을 중재하도록 구성하였다.

3.2.2 공유메모리

기존 Open-TEE에서는 CA와 TA 간 공유 메모리 할당을 위해 SCM_RIGHTS 방식으로 파일 디스크립터를 전달한 후, 이를 기반으로 메모리 매핑을 수행한다. 그러나, 호스트와 게스트가 서로 다른 운영체제 환경을 사용하기 때문에, 기존 파일 디스크립터 전달 방식은 적용할 수 없다.

본 연구에서는 이러한 문제를 해결하기 위해, TEE-Engine이 실행되는 pVM에서 동작하는 TEEMediator가 공유 메모리를 직접 관리하도록 설계하였으며, LibTEE가 해당 메모리에 간접적으로 접근할 수 있도록 하는 API를 추가하였다.

이러한 두 가지 주요 문제를 해결하는 설계를 통해, LibTEE는 호스트와 게스트 간의 원활한 통신을 지원할 뿐만 아니라, 기존 Open-TEE의 TEE-Engine 구조를 유지할 수있었다.

3.3 TEEMediator

TEEMediator 는 Table 1.에서 정의된 API의 구현체로서, pVM 상에서 RPC(Remote Procedure Call) 서버로 동작하며, LibTEE로부터 전달되는 요청을 중재하는 핵심 컴포넌트역할을 한다.

Table 1. AIDL Definition of APIs for TEEMediator

LibTEE는 AIDL 인터페이스를 통해 TEEMediator에 TEE 관련 요청을 전달하며, TEEMediator는 내부적으로 Unix socket을 이용하여 게스트 운영체제 내에서 실행 중인 TEE-Engine과의 통신을 수행한다. 이후, TEE-Engine에서 처리된 결과가 Unix socket을 통해 TEEMediator로 전달되면, TEEMediator는 이를 다시 AIDL 인터페이스를 통해 LibTEE로 반환하여 호스트와 게스트 사이의 원활한 상호작용을 보장한다.

또한, TEEMediator는 공유 메모리를 직접 관리하며, LibTEE가 이를 UUID 기반으로 식별하고 접근할 수 있도록 한다. 구체적으로, TEEMediator는 공유 메모리를 생성하고, 해당 메모리를 UUID와 매핑하여 관리하며, UUID를 기반으로 특정 메모리에 대한 읽기 및 쓰기 작업을 수행할 수 있는 API를 제공한다.

이러한 설계를 통해, 호스트와 게스트 간 운영체제 차이로 인한 문제를 극복하고, 기존 TEE-Engine의 코드 베이스를 유지하면서도 격리된 환경에서 안정적으로 TEE 요청을 처리할 수 있는 기반을 마련하였다. 이를 통해, AVF 환경으로의 TEE 제공 가능성을 확보할 수 있도록 설계하였다.

3.4 TEE-Engine

TEE-Engine은 Open-TEE의 핵심 구성요소로, 데몬 프로세스로 실행되며 TEE 기능을 에뮬레이션한다.

본 연구에서는 기존 Open-TEE의 TEE-Engine 코드 베이스를 수정하지 않고 유지하면서도, 실행 환경을 호스트와 게스트로 분리 적용하였다.

이를 통해, 기존 연구의 결과를 그대로 활용하면서도, AVF 기반 호스트와 게스트 간의 분리 실행 환경에서도 동일한 방식으로 안정적인 동작을 보장할 수 있음을 확인하였다.

3.5 TA

TA는 CA의 요청을 수신하여 암호 연산, 인증, 키 관리 등과 같은 핵심 보안 기능을 수행하는 애플리케이션으로, TEE 내의 보호된 환경에서 실행된다.

본 연구에서는 기존 Open-TEE 기반 TA의 코드 베이스를 수정하지 않고 그대로 활용하여, 기존 연구의 결과를 유지하면서도 새로운 아키텍처 환경에서의 원활한 동작을 확인하였다.

이를 통해, 기존 Open-TEE 기반 시스템과의 호환성을 보장하는 동시에, AVF 환경에서의 확장 가능성을 제시하였다.

IV. 평가

본 연구는 Pixel 6의 userdebug 빌드를 기반으로 실험을 진행했다. 실험 환경은 AVF를 이용해 pVM을 부팅하도록 구성했다. 이 pVM의 운영체제로는 AVF에서 기본 제공되는 경량화된 Android 배포판인 마이크로드로이드 OS를 사용했다. 또한, Open-TEE Engine 구동을 위해 마이크로드로이드 커널에 ashmem 지원을 추가했으며, 관련 실행 파일과 공유 라이브러리를 마이크로드로이드 OS가 탑재된 VM 이미지의 파일시스템에 포함하여 실험 환경을 구축했다.

4.1 제안 시스템의 보안 평가

제안 시스템의 보안성은 AVF의 pKVM 하이퍼바이저가 제공하는 강력한 격리 보장과 3장에서 기술한 설계 선택에 기초한다.

구체적으로 TEE-Engine과 TA를 전용 pVM으로 격리함으로써, 이들 구성 요소는 CA가 실행되는 호스트 운영체제와 완전히 분리된다. pKVM은 스테이지-2 페이지 변환을 통해 호스트와 pVM 간 메모리 접근을 엄격히 통제한다. 이러한 상호 불신 격리 메커니즘을 통해, pVM 내부 구성요소는 잠재적으로 손상될 수 있는 호스트로부터 보호받는다. 동시에, pVM 내 TA나 TEE-Engine의 버그 또는 설계 결함으로 인한 공격이 호스트 시스템에 영향을 미치는 것 또한 원천적으로 차단된다. 궁극적으로 pKVM이 제공하는 이러한 강력한 격리는 pVM 내부에서 처리되는 TEE 컴포넌트, TA 코드, 데이터의 무결성과 기밀성을 보장하는데핵심적인 역할을 한다.

또한, 제안 시스템의 아키텍처 설계 자체도 보안성을 한층 더 강화한다. 호스트의 CA와 pVM 내부의 TEE-Engine/TA 간 모든 상호작용은 명확히 정의된 AIDL 인터페이스(Table 1. 참조)를 통해 TEEMediator 컴포넌트로 집중된다. 이러한 설계 선택은 시스템 경계를 넘나드는 통신 채널을 단일화하여, 보안 정책 적용 및 시스템 감사를 위한 명확한 통제 지점을 제공한다. 또한, 원본 Open-TEE의 TEE-Engine 및 TA 코드베이스를 수정없이 이식하도록 한 설계 원칙은 이미 안정성이 검증된 컴포넌트에 의도치 않은 취약점을 유입시킬 위험을 최소화하는 효과를 가진다. 즉, 원본 컴포넌트의 보안성은 이미 성숙한 것으로 전제하며, 이는본 연구가 제안하는 확장 아키텍처의 직접적인 평가 범위에 포함되지 않는다.

이러한 보안 속성을 바탕으로 제안한 시스템이 실제 위협에 얼마나 효과적으로 대응하는지 검증하기 위해 주요 공격 시나리오를 상정하고 방어 능력을 분석한다. 각 시나리오의 분석을 통해 제안 시스템이 pKVM의 격리 경계와 아키텍처 설계를 기반으로 어떻게 위협의 전파를 차단하고 시스템 전체의 안정성을 유지하는지 구체적으로 보일 것이다.

호스트 손상 시나리오: 호스트 OS가 커널 수준에서 완전히 손상되더라도, pKVM 하이퍼바이저는 호스트보다 높은 예외 레벨(EL2)로 동작하며, pKVM은 스테이지-2 페이지 테이블을 독점적으로 관리하므로, 손상된 호스트는 pVM의 메모리 공간에 대한 읽기 또는 쓰기 접근이 하드웨어 수준에서 원천적으로 차단된다.

TA 손상 시나리오: TA 내부 취약점이 악용되더라도 pKVM은 호스트와 게스트를 상호 불신 실행환경으로 격리하므로, 손상된 TA의 모든 외부 접근 시도를 원천적으로 차단한다. 결과적으로 공격의 영향 범위는 해당 pVM의 경계 내로 완벽히 격리되며, 이로써 손상된 TA가 호스트의 메모리나 CPU 상태와 같은 시스템 자원에 접근하거나 실행 흐름에 개입하는 등의 모든 외부 전파 경로는 근본적으로 봉쇄된다.

Open-TEE 손상 시나리오: 제안 구조에서는 TEE-Engine, TEEMediator 등 pVM 내부에서 실행되는 모든 TEE 컴포넌트가 특별한 권한이 없는 일반 사용자 프로세스로 동작한다. 따라서 이들 중 어떤 컴포넌트가 손상되더라도, 그 영향력은 TA 손상 시나리오와 마찬가지로 pKVM 하이퍼바이저가 강제하는 가상 머신의 경계를 넘어설 수 없다. 즉, pVM 내부 컴포넌트의 손상은 시스템 전체를 위협하는 치명적인 실패로 이어지지 않으며, 그 모든 피해는 해당 pVM 내부로 국한된다.

TrustZone 손상 시나리오: TrustZone이 손생된 공격 시나리오에서는 현존 모델의 명백한 구조적 한계를 드러낸다. 하드웨어 수준에서 TrustZone이 pVM의 메모리에 접근하지 못하도록 통제할 수 있다면 pVM은 안전하지만, 현재 아키텍처에서는 이것이 불가능하다. 따라서 제안 시스템의 핵심 방어 접근법은 손상된 TrustZone으로부터 시스템을 직접 보호하는 것이 아니라, 오히려 TA를 pVM 기반 TEE로 이주시켜 TrustZone의 TCB를 최소화함으로써, TrustZone 내부 취약점이 시스템 전체로 확산될 위험 자체를 줄이는 것에 있다. 즉, 방어의 초점은 TrustZone의 막강한 권한을 제어하려는 시도가 아니라, 그 권한이 탈취될 가능성을 근본적으로 낮추는 데 맞추어진다.

결론적으로, pKVM을 기반으로 구축된 제안 시스템 아키텍처는 TEE와 CA가 동일 실행 환경에서 동작하는 원본 Open-TEE의 주요 한계를 극복한다. pKVM이 강제하는 분리된 실행 경계는 잠재적 공격이 다른 실행 환경에 영향을 줄 수 있는 가능성을 효과적으로 제한한다. 다시 말해, AVF의 기본 격리 모델을 효과적으로 활용함으로써 제안한 시스템은 안전하면서도 실용적인 TEE 환경을 제공한다.

4.2 API 호환성 평가

이 절에서는 제안 시스템의 GP TEE 클라이언트 API 호환성을 검증한다. 호환성 검증은 GP 표준을 준수하는 기존 Open-TEE와의 기능적 동등성을 입증하는 방식으로 수행된다. 평가는 CA가 호출하는 핵심 GP TEE 클라이언트 API들이 제안 시스템에서도 기존 Open-TEE와 동일하게 처리되고, 동일한 결과를 반환하는지 확인하는데 초점을 맞춘다.

Fig. 4.에 명시된 주요 GP TEE 클라이언트 API를 체계적으로 테스트했다. Table 2.는 테스트에 사용된 API 목록과 각각의 기능 설명, 그리고 기존 Open-TEE와의 기능적 동등성 분석 결과를 요약한다. 기능적 동등성은 제안 시스템에서의 API 호출이 기존 Open-TEE 환경과 동일한 동작 결과를 보였음을 의미한다. 동작 결과의 확인은 반환 코드나 로그(Fig. 5. 참조)를 통해 확인한다.

Table 2. Functional Equivalence of Tested GP TEE Client APIs

Fig. 4. APIs Invoked by Client Application

Fig. 5. CA Test Result

이처럼 핵심 API 호출에서 기존 Open-TEE와의 기능적 동등성을 입증한 것은 제안 시스템이 GP API 호환성을 충족함을 뒷받침한다. 이는 제안 시스템이 AVF의 pVM을 통해 강력한 보안 격리 이점을 확보하는 동시에, 기존 TEE 표준을 준수하여 개발자의 쉬운 도입 및 이주를 보장함을 의미한다.

4.3 성능 평가

이 절에서는 제안 시스템이 AVF의 pVM 환경에 도입되면서 발생하는 성능 오버헤드를 분석한다. 평가는 TEE 클라이언트 API의 호출 지연 시간을 비격리 환경의 기존 Open-TEE를 베이스라인으로 비교하여 정량화했으며, 그 결과는 Table. 3과 같다.

Table 3. Performance Comparison of Key TEE Client API Calls

분석 결과, VM 경계를 넘나드는 환경 간 통신으로 인해 전반적인 오버헤드가 발생하는 것으로 나타났다. 이는 TEEMediator의 AIDL 기반 RPC, 데이터 마샬링/언마샬링, 그리고 VM 경계를 가로지르는 자원 관리의 복잡성에 주로 기인한다. 하지만 절대적인 지연 시간 수치를 보면, 제안 시스템의 성능은 대다수 TEE 사용 사례에서 충분히 실용적인 수준이다. TA에서의 연산을 요청하는 TEEC_InvokeCommand API의 호출 지연 시간은 약 15-20ms로 측정되었다. 이는 대부분의 보안 연산이 UI 반응성과 독립적으로 동작하는 것을 고려할 때, 오버헤드가 실제 사용자 경험에 체감될 수준의 영향을 주지 않음을 시사한다. 초기화 시의 높은 오버헤드는 시스템 시작 시 단 한번만 발생하는 설정 비용이므로, 반복적인 연산의 성능과는 분리해서 고려해야 한다.

결론적으로 측정된 오버헤드는 실행환경 격리를 위한 필연적인 비용이며, 이는 보안성 강화를 위해 감수할 수 있는 합리적인 수준의 트레이드오프로 평가된다.

4.4 적용 용이성 평가

이 절에서는 제안 시스템의 도입 용이성을 개발자 관점의 필요성과 이식 노력 측면에서 평가한다.

AVF가 제공하는 pVM은 그 자체로 강력한 격리 환경이지만, 개발자가 이를 직접 사용하려면 AVF 고유의 API에 맞춰 보안 애플리케이션을 새로 개발해야 한다. 이는 GP TEE 표준에 따라 이미 개발된 수많은 기존 TA 자산을 재사용하기 어렵게 만드는 높은 진입 장벽이다.

제안된 시스템은 CA와 TA 모두에게 높은 이식성을 제공한다. 마이그레이션 과정에서 CA는 기존의 핵심 로직을 변경할 필요가 없다. 단지 CA가 사용하는 LibTEE 라이브러리를 내부적으로 pVM의 TEEMediator와 AIDL 통신을 관리하는 새로운 버전으로 교체하는 작업만으로 충분하다. 이는 conn_test_ca를 통해 진행한 실험으로 입증되었으며, 제안 시스템의 LibTEE가 내부 구현을 변경하였지만 기존 인터페이스는 그대로 유지하였기에 가능하다. 또한, TA의 경우에는 코드 수정 없이 기존 소스코드를 새로운 실행 환경에 맞추어 재빌드만 진행하면 된다.

이러한 이식성을 지원하기 위해 새로 구현된 TEEMediator와 LibTEE의 수정 코드는 2K LoC 수준이다. 이는 새로운 코드 추가로 인한 TCB의 증가를 크지 않고, 시스템 확장 시 신규 보안 위험이 도입될 가능성을 최소화하면서도 높은 호환성을 달성했음을 의미한다.

결론적으로, 제안 시스템은 개발자가 기존 TEE 생태계의 자산을 최대한 활용하면서 AVF의 강력한 보안 환경을 누릴 수 있도록 하는 실용적인 가교 역할을 수행한다. 이는 단순히 또 다른 격리 환경을 제공하는 것을 넘어, 기존 TEE 표준과 최신 보안 모델을 연결한다는 점에서 그 필요성이 강조된다.

V. 결론

본 연구는 기존 TrustZone TEE의 구조적 한계를 극복하기 위한 대안으로서, 구글의 차세대 보안 모델인 AVF 환경에 기존 TEE 애플리케이션을 원활히 이주시키는 방안을 제시하고자한다.

이러한 목표를 달성하기 위해, 본 논문은 기존 Open-TEE를 AVF 환경에 맞게 확장하는 새로운 시스템을 제안 및 구현하였다. 제안 시스템은 TEEMediator라는 새로운 컴포넌트를 통해 CA와 TA의 분리된 실행 모델을 구현하면서도, 기존 Open-TEE의 구조적 장점과 GP 표준 호환성은 그대로 유지한다.

제안 시스템의 보안성과 실효성은 4장에서의 종합적인 평가를 통해 검증되었다. 평가 결과, 제안 시스템은 GP API 호환성과 기능적 동등성을 만족시켰으며, CA는 LibTEE 교체만으로, TA는 코드 수정 없이 마이그레이션이 가능함을 입증하여 높은 도입 용이성을 보였다. AVF의 강력한 격리로 인한 성능 오버헤드는 측정되었으나, 실제 TEE 연산의 절대적 실행 시간은 대부분의 상용 애플리케이션에서 수용 가능한 범위 내에 있음을 확인하였다.

본 연구는 제안 시스템의 설계, 구현, 그리고 종합적인 평가를 통해 제안 시스템이 TA를 격리된 pVM으로 이전시키는 효과적인 이주 방안을 제공하며, 결과적으로 Secure World의 TCB를 축소하여 모바일 플랫폼 전체의 보안을 강화하는데 기여한다는 점에서 그 의의가 있다.

5.1 한계 및 향후 연구

Open-TEE는 소프트웨어 기반의 가상 TEE 환경으로, 기존 하드웨어 기반 TEE가 제공하던 키 생성, 난수 생성, 암복호화 등 보안 기능을 소프트웨어로 구현하여 제공한다. 이러한 방식은 하드웨어 특화 기능의 직접적인 이점을 온전히 반영하지 못하며, 보안성과 성능 측면에서 본질적인 한계를 내포한다. 특히, 보안 민감 기능인 키 생성, 암복호화와 난수 생성의 경우, 소프트웨어 구현은 하드웨어 기반 솔루션에 비해 취약할 수 있으며, 실제 하드웨어 TEE가 제공하는 고유의 보안 및 성능 이점을 완벽하게 대체하지 못하는 한계를 지니고 있다.

향후 연구: 본 연구의 성과를 토대로, 향후 AVF 기반 TEE 환경에서 동작하는 TA와 기존 TA간의 상호작용을 연구할 계획이다. 또한, TA별로 격리된 실행 환경 등 보다 세밀한 격리 실행 환경을 구현하여 전체 시스템의 보안성을 한층 강화할 방안을 모색하고자 한다. 더불어, 하드웨어 TEE가 제공하는 키 생성, 난수 생성, 암복호화 등의 고유 기능을 AVF 기반 TEE에서도 효과적으로 활용할 수 있도록 관련 연구를 진행할 예정이다. 이러한 후속 연구를 통해 소프트웨어 기반 TEE의 한계를 보완하고, 실제 환경에서의 성능 및 보안성을 극대화할 수 있을 것으로 기대한다.