Untrusted Operating System Research Articles

Efficient Application Protection against Untrusted Operating Systems

Efficient Application Protection against Untrusted Operating Systems

Security Vulnerabilities of SGX and Countermeasures

Trusted Execution Environments (TEEs) have been widely used in many security-critical applications. The popularity of TEEs derives from its high security and trustworthiness supported by secure hardware. Intel Software Guard Extensions (SGX) is one of the most representative TEEs that creates an isolated environment on an untrusted operating system, thus providing run-time protection for the execution of security-critical code and data. However, Intel SGX is far from the acme of perfection. It has become a target of various attacks due to its security vulnerabilities. Researchers and practitioners have paid attention to the security vulnerabilities of SGX and investigated optimization solutions in real applications. Unfortunately, existing literature lacks a thorough review of security vulnerabilities of SGX and their countermeasures. In this article, we fill this gap. Specifically, we propose two sets of criteria for estimating security risks of existing attacks and evaluating defense effects brought by attack countermeasures. Furthermore, we propose a taxonomy of SGX security vulnerabilities and shed light on corresponding attack vectors. After that, we review published attacks and existing countermeasures, as well as evaluate them by employing our proposed criteria. At last, on the strength of our survey, we propose some open challenges and future directions in the research of SGX security.

Architectural Protection of Trusted System Services for SGX Enclaves in Cloud Computing

Data security and privacy are of great concern for users of cloud computing. In order to provide such guarantees in public clouds, hardware manufacturers have designed trusted execution environments such as Intel’s Software Guard eXtensions (SGX). Intel SGX supports privacy-preserving, tamper-proof containments called enclaves. Regrettably, an SGX enclave has to rely on the untrusted operating system or hypervisor for underlying services, which contradicts the threat model of Intel SGX. Whereas much of the previous work concentrates on protecting trusted applications by means of modifying a hypervisor, we tackle the problem by reusing existing drivers and leveraging processor-enforced protection. We propose a novel approach, named SMK, to provide trusted system services for SGX enclaves. SMK leverages existing Intel architecture features, i.e., System Management Mode (SMM) and Uniform Extensible Firmware Interface (UEFI). Specifically, we retrofit UEFI firmware and design an isolated micro-kernel inside SMM to securely provision critical system services for enclaves. To highlight the effectiveness and extensibility of SMK, we implement two system services: trusted clock and trusted network. Furthermore, we harden two real-world security-sensitive applications, OpenSSL and OpenVPN, with SMK’s system services. Our evaluation indicates that SMK can supply trusted system services for enclaves with modest runtime overheads.

Secure cryptographic functions via virtualization‐based outsourced computing

SummaryCryptographic functions, such as encryption/decryption libraries, are common and important tools for applications to enhance confidentiality of the data. However, these functions could be compromised by subtle attacks launched by untrusted operating system or other applications, and sensitive keys or cryptographic procedures could then be compromised. In this paper, based on virtualization technology, we propose a novel approach that outsources the cryptographic functions in one virtual machine (VM) into another dedicated VM, so that sensitive keys and the cryptographic procedures are only contained by this VM with specific purpose. We also propose a prototype, called cryptographic function assurance (CFA), to enhance the security of cryptographic functions. Taking OpenSSL as an example, CFA allows those applications that use OpenSSL library to transparently utilize CFA to protect the cryptographic functions. We present the detailed implementation, as well as the security analysis of CFA. We also give the performance evaluation for OpenSSL's interfaces and Apache httpd, to show the overhead caused by the integration of CFA. Copyright © 2015 John Wiley & Sons, Ltd.

Iago attacks

In recent years, researchers have proposed systems for running trusted code on an untrusted operating system. Protection mechanisms deployed by such systems keep a malicious kernel from directly manipulating a trusted application's state. Under such systems, the application and kernel are, conceptually, peers, and the system call API defines an RPC interface between them. We introduce Iago attacks , attacks that a malicious kernel can mount in this model. We show how a carefully chosen sequence of integer return values to Linux system calls can lead a supposedly protected process to act against its interests, and even to undertake arbitrary computation at the malicious kernel's behest. Iago attacks are evidence that protecting applications from malicious kernels is more difficult than previously realized.

InkTag

InkTag is a virtualization-based architecture that gives strong safety guarantees to high-assurance processes even in the presence of a malicious operating system. InkTag advances the state of the art in untrusted operating systems in both the design of its hypervisor and in the ability to run useful applications without trusting the operating system. We introduce paraverification , a technique that simplifies the InkTag hypervisor by forcing the untrusted operating system to participate in its own verification. Attribute-based access control allows trusted applications to create decentralized access control policies. InkTag is also the first system of its kind to ensure consistency between secure data and metadata, ensuring recoverability in the face of system crashes.

Iago attacks

In recent years, researchers have proposed systems for running trusted code on an untrusted operating system. Protection mechanisms deployed by such systems keep a malicious kernel from directly manipulating a trusted application's state. Under such systems, the application and kernel are, conceptually, peers, and the system call API defines an RPC interface between them. We introduce Iago attacks , attacks that a malicious kernel can mount in this model. We show how a carefully chosen sequence of integer return values to Linux system calls can lead a supposedly protected process to act against its interests, and even to undertake arbitrary computation at the malicious kernel's behest. Iago attacks are evidence that protecting applications from malicious kernels is more difficult than previously realized.

InkTag

InkTag is a virtualization-based architecture that gives strong safety guarantees to high-assurance processes even in the presence of a malicious operating system. InkTag advances the state of the art in untrusted operating systems in both the design of its hypervisor and in the ability to run useful applications without trusting the operating system. We introduce paraverification , a technique that simplifies the InkTag hypervisor by forcing the untrusted operating system to participate in its own verification. Attribute-based access control allows trusted applications to create decentralized access control policies. InkTag is also the first system of its kind to ensure consistency between secure data and metadata, ensuring recoverability in the face of system crashes.

ChipLock

The increasing need for security has caused system designers to consider placing some security support directly at the hardware level. In fact, this is starting to emerge as an important consideration in processor design, because the performance overhead of supporting security in hardware is usually significantly lower than a complete software solution. In this paper, we investigate integrating some security support into hardware. We show that security support can be added at some acceptable cost in area and performance. We propose a processor extension called ChipLock. It provides hardware security support for a mostly untrusted operating system to ensure the integrity and confidentiality of all computational results. ChipLock's modular design can be easily integrated into existing hardware platforms with only slight modification to the operating system. ChipLock includes a built-in hardware Key Manager that supports symmetric key assignment, and a read-only-memory, TrustROM, that executes secure hardware routines. The software required is a small trusted portion of the operating system called Trust-Code. We modeled ChipLock's architecture on a full system simulator and showed that, for SPEC2000 benchmarks, it adds about an average of 20% to the execution time, primarily from cryptographic and verification latencies. In addition, layout studies show an area cost of about 8 mm 2 in 180 nm technology. This translates to an area overhead of 5% ~ 15% depending on the processor type.

Implementing an untrusted operating system on trusted hardware

Recently, there has been considerable interest in providing "trusted computing platforms" using hardware~---~TCPA and Palladium being the most publicly visible examples. In this paper we discuss our experience with building such a platform using a traditional time-sharing operating system executing on XOM~---~a processor architecture that provides copy protection and tamper-resistance functions. In XOM, only the processor is trusted; main memory and the operating system are not trusted.Our operating system (XOMOS) manages hardware resources for applications that don't trust it. This requires a division of responsibilities between the operating system and hardware that is unlike previous systems. We describe techniques for providing traditional operating systems services in this context.Since an implementation of a XOM processor does not exist, we use SimOS to simulate the hardware. We modify IRIX 6.5, a commercially available operating system to create xomos. We are then able to analyze the performance and implementation overheads of running an untrusted operating system on trusted hardware.