Using ARM trustzone to build a trusted language runtime for mobile applications

Santos, Nuno; Raj, Himanshu; Saroiu, Stefan; Wolman, Alec

doi:10.1145/2541940.2541949

Cited by 151 publications

(67 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…However, each mechanism should satisfy three key attributes: reliability (memory/time isolation), minimum overhead (unnecessary data copies and context switches), and protection of communication structures. In the literature, we identify three models of communication: (1) GlobalPlatform TEE Client API [26]; (2) secure RPC (Remote Procedure Call) of Trusted Language Runtime [6]; and (3) real-time RPC of SafeG [27]. Secure inter-environment communication is proposed in [28].…”

Section: Tee Building Blocksmentioning

confidence: 99%

“…We only mention seven of them: (1) Genode TEE defined by Genode Labs [35]; (2) [49]; and (7) TLR defined by Microsoft Research [6].…”

Section: B Academic Teesmentioning

confidence: 99%

“…In the literature, many names exist to this environment. Examples are closed-box VM [3], operator virtual machine (OVM) [4], TrustZone software (TZSW) [5], and trusted language runtime [6]. In this paper, we are going to refer to this environment using the term coined by GlobalPlatform in [7], that is trusted execution environment (TEE).…”

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Trusted Execution Environment: What It is, and What It is Not

Sabt

Achemlal

Bouabdallah

2015

2015 IEEE Trustcom/BigDataSE/Ispa

429

186

View full text Add to dashboard Cite

Nowadays, there is a trend to design complex, yet secure systems. In this context, the Trusted Execution Environment (TEE) was designed to enrich the previously defined trusted platforms. TEE is commonly known as an isolated processing environment in which applications can be securely executed irrespective of the rest of the system. However, TEE still lacks a precise definition as well as representative building blocks that systematize its design. Existing definitions of TEE are largely inconsistent and unspecific, which leads to confusion in the use of the term and its differentiation from related concepts, such as secure execution environment (SEE). In this paper, we propose a precise definition of TEE and analyze its core properties. Furthermore, we discuss important concepts related to TEE, such as trust and formal verification. We give a short survey on the existing academic and industrial ARM TrustZone-based TEE, and compare them using our proposed definition. Finally, we discuss some known attacks on deployed TEE as well as its wide use to guarantee security in diverse applications.

show abstract

Section: Tee Building Blocksmentioning

confidence: 99%

“…We only mention seven of them: (1) Genode TEE defined by Genode Labs [35]; (2) [49]; and (7) TLR defined by Microsoft Research [6].…”

Section: B Academic Teesmentioning

confidence: 99%

See 1 more Smart Citation

Trusted Execution Environment: What It is, and What It is Not

Sabt

Achemlal

Bouabdallah

2015

2015 IEEE Trustcom/BigDataSE/Ispa

429

186

View full text Add to dashboard Cite

show abstract

“…While ARMlock prevents code from reading the contents of other sandboxes, it cannot support our use-case of preventing read accesses to code inside the sandbox. Santos et al [44] use the ARM TrustZone feature to build a trusted language runtime (TLR); while this greatly reduces the TCB of an open source .NET implementations the performance cost is high. Unlike LR 2 , these approaches rely on features that limit their applicability to certain hardware platforms.…”

Section: Related Workmentioning

confidence: 99%

Leakage-Resilient Layout Randomization for Mobile Devices

Braden¹,

Crane

Davi

et al. 2016

Proceedings 2016 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-Attack techniques based on code reuse continue to enable real-world exploits bypassing all current mitigations. Code randomization defenses greatly improve resilience against code reuse. Unfortunately, sophisticated modern attacks such as JIT-ROP can circumvent randomization by discovering the actual code layout on the target and relocating the attack payload on the fly. Hence, effective code randomization additionally requires that the code layout cannot be leaked to adversaries.Previous approaches to leakage-resilient diversity have either relied on hardware features that are not available in all processors, particularly resource-limited processors commonly found in mobile devices, or they have had high memory overheads. We introduce a code randomization technique that avoids these limitations and scales down to mobile and embedded devices: Leakage-Resilient Layout Randomization (LR 2 ).Whereas previous solutions have relied on virtualization, x86 segmentation, or virtual memory support, LR 2 merely requires the underlying processor to enforce a W⊕X policy-a feature that is virtually ubiquitous in modern processors, including mobile and embedded variants. Our evaluation shows that LR 2 provides the same security as existing virtualization-based solutions while avoiding design decisions that would prevent deployment on less capable yet equally vulnerable systems. Although we enforce execute-only permissions in software, LR 2 is as efficient as the best-in-class virtualization-based solution. I. MOTIVATIONThe recent "Stagefright" vulnerability exposed an estimated 950 million Android systems to remote exploitation [21]. Similarly, the "One Class to Rule them All" [40] zero-day vulnerability affected 55% of all Android devices. These are just the most recent incidents in a long series of vulnerabilities that enable attackers to mount code-reuse attacks [37,43] against mobile devices. Moreover, because these devices run scripting capable web browsers, they are also exposed to sophisticated code-reuse attacks that can bypass ASLR and even finegrained code randomization by exploiting information-leakage vulnerabilities [11,20,48,50]. Just-in-time attacks (JIT-ROP) [50] are particularly challenging because they misuse run-time scripting to analyze the target memory layout after randomization and relocate a return-oriented programming (ROP) payload accordingly.There are several alternatives to code randomization aimed to defend against code-reuse attacks, including control-flow integrity (CFI) [1] and code-pointer integrity (CPI) [28]. However, these defenses come with their own set of challenges and tend to have high worst-case performance overheads. We focus on code randomization techniques since they are known to be efficient [18,25] and scalable to complex, real-world applications such as web browsers, language runtimes, and operating system kernels without the need to perform elaborate static program analysis during compilation.Recent code randomization defenses offer varying degrees of resilience to JIT...

show abstract

“…This approach requires a redesign of operating systems, thereby requiring nontrivial modifications to port existing applications. Third, the dual-execution-environment approach (dual-EE), such as TLR [22], solves the problem by multiplexing the feature-rich OS and a specialized OS with restricted functionalities on the same smart device. It relies on the specialized OS to provide tamper-resistant capabilities.…”

Section: Introductionmentioning

confidence: 99%

The Dual-Execution-Environment Approach: Analysis and Comparative Evaluation

Sabt

Achemlal

Bouabdallah

2015

ICT Systems Security and Privacy Protection

View full text Add to dashboard Cite

Abstract. The dual-execution-environment approach (dual-EE) is a trusted model that was defined to allow mobile smart devices to guarantee tamper-resistant execution for highly sensitive applications. Although various solutions implementing dual-EE have been proposed in the literature, this model has not been formalized yet. In this paper, we revisit the dual-EE approach and propose a theoretical framework to systematize the design of dual-EE solutions regarding well-established primitives defined in the Multiple Independent Levels of Security (MILS) architecture. We provide a general classification of the different dual-EE proposals based on their isolation properties. We introduce a comparative framework allowing dual-EE solutions to be evaluated across a common set of criteria. The relevance of our framework is examined by applying it on three technologies, each one represents one category in our classification. Results are consistent and explain some hidden and unexpected properties of each technology. For instance, we find that bare-metal hypervisors are ill-adapted to provide high assurance security even though they might improve the overall security level of the system.

show abstract

Using ARM trustzone to build a trusted language runtime for mobile applications

Cited by 151 publications

References 20 publications

Trusted Execution Environment: What It is, and What It is Not

Trusted Execution Environment: What It is, and What It is Not

Leakage-Resilient Layout Randomization for Mobile Devices

The Dual-Execution-Environment Approach: Analysis and Comparative Evaluation

Contact Info

Product

Resources

About