DelegaTEE: Brokered Delegation Using Trusted Execution Environments

DelegaTEE: Brokered Delegation Using Trusted Execution Environments

Sinisa Matetic and Moritz Schneider and Andrew Miller and Ari Juels and Srdjan Capkun

We introduce a new concept called brokered delegation. Brokered delegation allows users to flexibly delegate credentials and rights for a range of service providers to other users and third parties. We explore how brokered delegation can be implemented using novel trusted execution environments (TEEs). We introduce a system called DelegaTEE that enables users (Delegatees) to log into different online services using the credentials of other users (Owners). Credentials in DelegaTEE are never revealed to Delegatees and Owners can restrict access to their accounts using a range of rich, contextually dependent delegation policies. DelegaTEE fundamentally shifts existing access control models for centralized online services. It does so by using TEEs to permit access delegation at the user’s discretion. DelegaTEE thus effectively reduces mandatory access control (MAC) in this context to discretionary access control (DAC). The system demonstrates the significant potential for TEEs to create new forms of resource sharing around online services without the direct support from those services. We present a full implementation of DelegaTEE using Intel SGX and demonstrate its use in four real-world applications: email access (SMTP/IMAP), restricted website access using a HTTPS proxy, e-banking/credit card, and a third-party payment system (PayPal).




Microsoft Azure introduces confidential computing

[…]With Azure confidential computing, we’re developing a platform that enable developers to take advantage of different TEEs without having to change their code. Initially we support two TEEs, Virtual Secure Mode and Intel SGX. Virtual Secure Mode (VSM) is a software-based TEE that’s implemented by Hyper-V in Windows 10 and Windows Server 2016. Hyper-V prevents administrator code running on the computer or server, as well as local administrators and cloud service administrators from viewing the contents of the VSM enclave or modifying its execution. We’re also offering hardware-based Intel SGX TEE with the first SGX-capable servers in the public cloud. Customers that want their trust model to not include Azure or Microsoft at all can leverage SGX TEEs. We’re working with Intel and other hardware and software partners to develop additional TEEs and will support them as they become available.[…]



Trust Issues: Exploiting TrustZone TEEs

by Gal Beniamini, Project Zero

Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]




Android attestation API

Shawn Willden of Google recently posted a message to the Android Security Discussions group. Someone had asked if, like a PC, Android smartphones have a TPM or Trusted Execution Environment (TEE), and if this included a public remote attestation API. Shawn’s response:

“One of the features I’m working on adding to Android TEEs for N is an attestation API. It will be implemented in our TEE, Qualcomm’s, Trustonic’s, etc. However, that will only assure the relying party that the device attesting has an officially-blessed TEE, and that the Android OS that was booted was an officially-blessed image as well. It can’t say anything about the state of Android, whether or not it has been compromised in some way that doesn’t involve modifying the boot images. The SafetyNet attestation can theoretically provide some level of assurance that the device is not compromised, though at the moment I believe it really only validates that the device is not an emulator and that it hasn’t been rooted in an obvious way.”

For more information: see the October 25th posting from Shawn on:


GlobalPlatform’s TEE Developers Workshop

Next month is the GlobalPlatform TEE conference in California; they’re also hosting a 1-day developer workshop on October 12th. GlobalPlatform, Trustonic, Intel, and Linaro are presenting; the agenda looks interesting:

1) GlobalPlatform
Kevin Gillick, GlobalPlatform Exec. Director
Gil Bernabeu, GlobalPlatform Technical Director
Christophe Colas, VP of Product Marketing at Trustonic and GlobalPlatform Device Committee Chair

2) Trustonic: Scaling Fast and Simply Across Trustonic TEE-based Devices
Rob Dyke, Senior Field Application Engineer, Trustonic

3) Intel: Open-TEE – A Virtual TEE and SDK
Brian McGillion, Security Engineer, Intel
Tanel Dettenborn, Security Engineer, Intel
Thomas Nyman, Doctoral Candidate, Aalto University, Finland
Valentin Manea, Security Engineer, Huawei

4) Linaro: TEE and TA Development the Easy Way
Joakim Bech, Technical Lead, Security Working Group, Linaro



Early bird pricing is $199 USD before 30 August 2015. $299 USD after. There is no price distinction between GlobalPlatform members and non-members for this workshop. Organizations sending two or more people will receive $50 discount per student.


TrustZone TEE vulnerability for Huawei Mate 7

Found on @ABazhaniuk’s Twitter feed:

Security Advisory – Two Privilege Escalation Vulnerabilities in Huawei Mate 7 Smartphones

The tzdriver module of Huawei Mate 7 smartphone has an input check error, which allows the user-mode application to modify kernel-mode memory data and maybe make system break down or application elevate privilege. (Vulnerability ID: HWPSIRT-2015-03011) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4421. The TEEOS module of Huawei Mate 7 smartphone which is used to realize the function of fingerprint identification has an input check error, which enables the attackers with the root permission to modify kernel-mode memory data of TEEOS module, which could make system break down, TEEOS be tampered or malicious code execution. (Vulnerability ID: HWPSIRT-2015-03012) These Vulnerabilities have been assigned Common Vulnerabilities and Exposures (CVE) ID: CVE-2015-4422.

HWPSIRT-2015-03011: Attackers can write data into an invalid address to crash the system or elevate their privileges through elaborate applications.

HWPSIRT-2015-03012: After privilege escalation, attackers can craft malicious applications to crash the TEEOS or execute arbitrary code on the TEEOS.

Temporary Fix: None

See the Huawei Security Advisory for full details:


There’s also a Github sample:

“With two vulnerabilities,any installed application is able to execute arbitrary code in TEE of Huawei Mate7 . This source code is a PoC which may read fingerprint image from sensor(FPC1020) on Mate 7.”



Linaro update on TEE kernel driver

Today Joakim Bech posted a new entry in the Linaro blog, “Evolution of a generic TEE kernel driver“. This is a good introduction to ARM Trusted Execution Environment (TEE) and it’s integration to the Linux kernel.

More Information: