CaSE: Cache-Assisted Secure Execution on ARM Processors

Zhang, Ning; Sun, Kun; Lou, Wenjing; Hou, Yunfei

doi:10.1109/sp.2016.13

Cited by 80 publications

(59 citation statements)

References 44 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…Sentry [7] was developed to maintain data in the cache or internal memory in SoC chip. CaSE [36] was proposed to keep sensitive data using TrustZone from both physical and software-based memory disclosure attacks.…”

Section: Mitigation For Memory Disclosure Attackmentioning

confidence: 99%

Removing Secrets from Android's TLS

Lee¹,

Wallach

2018

Proceedings 2018 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

Abstract-Cryptographic libraries that implement Transport Layer Security (TLS) have a responsibility to delete cryptographic keys once they're no longer in use. Any key that's left in memory can potentially be recovered through the actions of an attacker, up to and including the physical capture and forensic analysis of a device's memory. This paper describes an analysis of the TLS library stack used in recent Android distributions, combining a C language core (BoringSSL) with multiple layers of Java code (Conscrypt, OkHttp, and Java Secure Sockets). We first conducted a black-box analysis of virtual machine images, allowing us to discover keys that might remain recoverable. After identifying several such keys, we subsequently pinpointed undesirable interactions across these layers, where the higherlevel use of BoringSSL's reference counting features, from Java code, prevented BoringSSL from cleaning up its keys. This interaction poses a threat to all Android applications built on standard HTTPS libraries, exposing master secrets to memory disclosure attacks. We found all versions we investigated from Android 4 to the latest Android 8 are vulnerable, showing that this problem has been long overlooked. The Android Chrome application is proven to be particularly problematic. We suggest modest changes to the Android codebase to mitigate these issues, and have reported these to Google to help them patch the vulnerability in future Android systems.

show abstract

Section: Mitigation For Memory Disclosure Attackmentioning

confidence: 99%

Removing Secrets from Android's TLS

Lee¹,

Wallach

2018

Proceedings 2018 Network and Distributed System Security Symposium

View full text Add to dashboard Cite

show abstract

“…In this work, we attempt to protect the TEE by securing the communication channel between the CA and the TA. Notably, our work is differentiated from previous TrustZone-based work [17], [18], [19], [20], [21], [23], [26], [27], [28], [29] in that we partially escalate the privilege of the CA, enable application-level TEE-service invocation, and verify the legitimacy of the invocation, whereas the previous work depended on the potentially malicious OS kernel to invoke the SMC instruction for access to the TEE.…”

Section: Trustzone Service Invocation and Vulnerabilitymentioning

confidence: 97%

“…We also assume the presence of IOMMU and its proper configuration [40]; therefore, DMA attacks such as direct manipulation of the physical memory are not available. Finally, attacks based on physical access [29], [41] and side channels are beyond the scope of our attack model. On the other hand, an adversary can arbitrarily send malicious messages to the TEE.…”

Section: Attack Model and Assumptionsmentioning

confidence: 99%

Retrofitting the Partially Privileged Mode for TEE Communication Channel Protection

Jang

Kang

2020

IEEE Trans. Dependable and Secure Comput.

View full text Add to dashboard Cite

ARM TrustZone provides a Trusted Execution Environment (TEE) to isolate security-critical services, which are generally invoked from the Rich Execution Environment (REE) through a communication channel established by executing the Secure Monitor Call (SMC) with the general registers configured as input parameters. Unfortunately, the communication channel has been abused by adversaries to incur misbehavior of the TEE, to analyze the internal working of the TEE, and to exploit its vulnerabilities. We therefore propose the TEE defense (TFence) framework that enables the creation of a partially privileged (par-priv) process, which benefits from the coordination of the system mode and virtualization extension. More specifically, on ARM architecture, direct invocation of hypercall and SMC is not allowed in the user process; however, we limitedly escalate the privilege of the process to enable it to directly communicate with trust anchors such as hypervisor and TrustZone. This approach enabled us to remove the kernel dependency when the process communicates with the TEE, which also reduces the attack surface to the critical part of the application involved in the communication. Besides, direct communication with the hypervisor facilitates the adoption of application-shielding approaches to protect the critical part and to restrict arbitrary access to the TEE. Security area including OS kernel integrity monitor, trusted execution environment, hardware-assisted security, botnet malware defense, and DNS analytics. He is currently a member of the IEEE, the USENIX and the ACM.

show abstract

“…It provides security against both physical and software attacks. SoftME [26], CaSE [27], TrustShadow [28], and CryptMe [29] provide TEE system with approaches to resist physical attacks.…”

Section: A Arm Trustzone Technologymentioning

confidence: 99%

MicroTEE: Designing TEE OS Based on the Microkernel Architecture

Zhang

Zhao

et al. 2019

2019 18th IEEE International Conference on Trust, Security and Privacy in Computing and Communications/13th IEEE International

View full text Add to dashboard Cite

ARM TrustZone technology is widely used to provide Trusted Execution Environments (TEE) for mobile devices. However, most TEE OSes are implemented as monolithic kernels. In such designs, device drivers, kernel services and kernel modules all run in the kernel, which results in large size of the kernel. It is difficult to guarantee that all components of the kernel have no security vulnerabilities in the monolithic kernel architecture, such as the integer overflow vulnerability in Qualcomm QSEE TrustZone and the TZDriver vulnerability in HUAWEI Hisilicon TEE architecture. This paper presents MicroTEE, a TEE OS based on the microkernel architecture. In MicroTEE, the microkernel provides strong isolation for TEE OS's basic services, such as crypto service and platform key management service. The kernel is only responsible for providing core services such as address space management, thread management, and inter-process communication. Other fundamental services, such as crypto service and platform key management service are implemented as applications at the user layer. Crypto Services and Key Management are used to provide Trusted Applications (TAs) with sensitive information encryption, data signing, and platform attestation functions. Our design avoids the compromise of the whole TEE OS if only one kernel service is vulnerable. A monitor has also been added to perform the switch between the secure world and the normal world. Finally, we implemented a MicroTEE prototype on the Freescale i.MX6Q Sabre Lite development board and tested its performance. Evaluation results show that the performance of cryptographic operations in MicroTEE is better than it in Linux when the size of data is small.

show abstract

CaSE: Cache-Assisted Secure Execution on ARM Processors

Cited by 80 publications

References 44 publications

Removing Secrets from Android's TLS

Removing Secrets from Android's TLS

Retrofitting the Partially Privileged Mode for TEE Communication Channel Protection

MicroTEE: Designing TEE OS Based on the Microkernel Architecture

Contact Info

Product

Resources

About