Ginseng: Keeping Secrets in Registers When You Distrust the Operating System

Abstract

Many mobile and embedded apps possess sensitive data, or secrets. Trusting the operating system (OS), they often keep their secrets in the memory. Recent incidents have shown that the memory is not necessarily secure because the OS can be compromised due to inevitable vulnerabilities resulting from its sheer size and complexity. Existing solutions protect sensitive data against an untrusted OS by running app logic in the Secure world, a Trusted Execution Environment (TEE) supported by the ARM TrustZone technology. Because app logic increases the attack surface of their TEE, these solutions do not work for third-party apps. This work aims to support third-party apps without growing the attack surface, significant development effort, or performance overhead. Our solution, called Ginseng, protects sensitive data by allocating them to registers at compile time and encrypting them at runtime before they enter the memory, due to function calls, exceptions or lack of physical registers. Ginseng does not run any app logic in the TEE and only requires minor markups to support existing apps. We report a prototype implementation based on LLVM, ARM Trusted Firmware (ATF), and the HiKey board. We evaluate it with both microbenchmarks and real-world secret-holding apps. Our evaluation shows Ginseng efficiently protects sensitive data with low engineering effort. For example, a Ginsengenabled web server, Nginx, protects the TLS master key with no measurable overhead. We find Ginseng's overhead is proportional to how often sensitive data in registers have to be encrypted and decrypted, i.e., spilling and restoring sensitive data on a function call or under high register pressure. As a result, Ginseng is most suited to protecting small sensitive data, like a password or social security number.

A Personal Computer for a Distrustful World

“…Therefore, we do not protect against physical attacks. However, if the program does not use any I/O devices, it can use on-chip computation and memory encryption to protect its secrets against physical attacks [87][88][89]. These are orthogonal to our design and hence can simply be added to our machine.…”

SoK: Understanding the Prevailing Security Vulnerabilities in TrustZone-assisted TEE Systems

“…TEEv [78] PrOS [79] SANCTUARY [80] Ginseng [81] K. Ryan [61] Table VIII Examples of representative papers that contribute with relevant defense techniques (Dxx) for overcoming reported TrustZone-assisted TEE issues. For architectural issues, filled circle in attack surface, world isolation, memory protection, or trust bootstrapping: the paper proposes D01, D02, D03, D04, respectively.…”

“…To bridge this gap, CaSE [71] allows TAs to run entirely from the cache and ensures that their state is encrypted while written back to main memory. Along the same vein, Ginseng [81] protects variables tagged by the application programmer as "sensitive", by allocating them on CPU registers and encrypting them at runtime before saving them in memory.…”

“…Given that Rust provides memory and thread-safety, RustZone can help prevent validation bugs and some concurrency bugs responsible for crippling TA software (see I11). The Rust programming language has also been used in Ginseng [81] for implementing a large part of the software that runs in monitor mode, i.e., the GService (see I10). D07.…”

Trusted computing theory and technology in innovation-driven development

“…第 2 种方式的代表性方案是 CaSE [36] , 该方案使用 TrustZone 和缓存作为 RAM 的技术创建了一个基于缓存的执行环境, 解决了 TrustZone 无法抵御冷启动攻击的问题. 其他方案还有 Ginseng [37] , 其思路与前者类似. 现有的这些方案可以解 决 TCB 过大的问题, 但并没有考虑受保护应用如何安全地调用不可信 REE 系统服务的问题, 实用性 方面存在较大缺陷.…”