TIMBER-V: Tag-Isolated Memory Bringing Fine-grained Enclaves to RISC-V

Weiser, Samuel; Werner, Mario; Brasser, Ferdinand; Malenko, Maja; Mangard, Stefan; Sadeghi, Ahmad‐Reza

doi:10.14722/ndss.2019.23068

Cited by 63 publications

(61 citation statements)

References 31 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Comparison with Hardware-based TEEs. There are many hardware-based TEE solutions [6], [9], [17], [50], [51], [56], [70], [72]- [75] available on ARM, Intel, and RISC-V processors. In particular, we compare SofTEE with ARM TrustZone which is widely used on mobile devices.…”

Section: Discussionmentioning

confidence: 99%

SofTEE: Software-Based Trusted Execution Environment for User Applications

Lee

Park

2020

IEEE Access

View full text Add to dashboard Cite

Commodity operating systems are considered vulnerable. Therefore, when an application handles security-sensitive data, it is highly recommended to run the application in a trusted execution environment. In response to this demand, hardware-based trusted execution environments such as Intel SGX and ARM TrustZone have been developed in commodity computers. However, hardware-based approaches cannot be quickly upgraded to address design vulnerabilities or to reflect customer feedback. In this paper, we propose SofTEE, a software framework to support a trusted execution environment for user applications. For a trusted execution environment, SofTEE should support memory isolation and attestation. For memory isolation, SofTEE relies 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 efficient management mechanism of the address space identifier. SofTEE supports attestation by assuming minimal hardware functionalities of random entropy and root of trust. The main challenge of SofTEE is to guarantee security properties like confidentiality and integrity of security-sensitive applications. For security analysis, we have identified security invariants that SofTEE should meet for confidentiality and integrity guarantees. Based on the security invariants, we have designed and prototyped each component of SofTEE on a Raspberry Pi 3 board. SofTEE produces about 3% overhead in case of a security-sensitive application with long execution time and 23% overhead in case of a security-sensitive application with short execution time.

show abstract

Section: Discussionmentioning

confidence: 99%

SofTEE: Software-Based Trusted Execution Environment for User Applications

Lee

Park

2020

IEEE Access

View full text Add to dashboard Cite

show abstract

“…Komodo [32] and Sanctum [30,64] propose verifiable TEEs on ARM and RISC-V respectively. Timber-V [73] and and Ginseng [75] are two recent TEE implementations for memory efficiency and low-TCB. OpenSGX [39] is an SGX emulator for research.…”

Section: Related Workmentioning

confidence: 99%

Uranus

Jiang

Chen

et al. 2020

Proceedings of the 15th ACM Asia Conference on Computer and Communications Security

View full text Add to dashboard Cite

Applications written in Java have strengths to tackle diverse threats in public clouds, but these applications are still prone to privileged attacks when processing plaintext data. Intel SGX is powerful to tackle these attacks, and traditional SGX systems rewrite a Java application's sensitive functions, which process plaintext data, using C/C++ SGX API. Although this code-rewrite approach achieves good efficiency and a small TCB, it requires SGX expert knowledge and can be tedious and error-prone. To tackle the limitations of rewriting Java to C/C++, recent SGX systems propose a code-reuse approach, which runs a default JVM in an SGX enclave to execute the sensitive Java functions. However, both recent study and this paper find that running a default JVM in enclaves incurs two major vulnerabilities, Iago attacks, and control flow leakage of sensitive functions, due to the usage of OS features in JVM. In this paper, Uranus creates easy-to-use Java programming abstractions for application developers to annotate sensitive functions, and Uranus automatically runs these functions in SGX at runtime. Uranus effectively tackles the two major vulnerabilities in the code-reuse approach by presenting two new protocols: 1) a Java bytecode attestation protocol for dynamically loaded functions; and 2) an OS-decoupled, efficient GC protocol optimized for data-handling applications running in enclaves. We implemented Uranus in Linux and applied it to two diverse data-handling applications: Spark and ZooKeeper. Evaluation shows that: 1) Uranus achieves the same security guarantees as two relevant SGX systems for these two applications with only a few annotations; 2) Uranus has reasonable performance overhead compared to the native, insecure applications; and 3) Uranus defends against privileged attacks. Uranus source code and evaluation results are released on https://github.com/hku-systems/uranus. CCS CONCEPTS • Security and privacy → Software security engineering.

show abstract

“…This is different from classic enclave systems which either use cryptography to enforce access control [9] or keep track of enclave ownership in a shadow page table [10]. Timber-V uses the idea of tagged memory to protect enclaves but does not consider side channels as a part of the threat model [33]. Praesidio shows how tagged memory can be used in conjunction with physically isolated enclaves to protect enclaves from side-channel attacks.…”

Section: Related Workmentioning

confidence: 99%

“…As operating systems become richer and more complicated, their attack surface increases, and it becomes more likely that they will be compromised by an attacker [7]. Previous enclave solutions show that a combination of hardware enforcement and software management is a powerful and flexible solution to allow any application to protect trusted code [3,6,9,10,15,19,29,33]. However, the degree to which these solutions protect against side-channel attacks differs widely.…”

Section: Introductionmentioning

confidence: 99%

Protecting Enclaves from Intra-Core Side-Channel Attacks through Physical Isolation

Maas

Moore

2020

Proceedings of the 2nd Workshop on Cyber-Security Arms Race

View full text Add to dashboard Cite

Systems that protect enclaves from privileged software must consider software-based side-channel attacks. Our system isolates enclaves on separate secure cores to stop attackers from running on the same core as the victim, which mitigates intra-core side-channel attacks. Redesigning the memory hierarchy based on enclave ownership protects enclaves against inter-core side-channel attacks. We implement this system and evaluate it in terms of communication performance, memory overhead and hardware area. Combining physical isolation and a redesigned memory hierarchy protects enclaves against all known software-based side-channel attacks.

show abstract

TIMBER-V: Tag-Isolated Memory Bringing Fine-grained Enclaves to RISC-V

Cited by 63 publications

References 31 publications

SofTEE: Software-Based Trusted Execution Environment for User Applications

SofTEE: Software-Based Trusted Execution Environment for User Applications

Uranus

Protecting Enclaves from Intra-Core Side-Channel Attacks through Physical Isolation

Contact Info

Product

Resources

About