Commercial TEE solutions using ARM’s TrustZone technology have been used for many years now. Are they enough on their own to guarantee security though?
Trusted Execution Environments (TEE) have been an important part of the industry for over a decade, and the most commercially successful TEEs use ARM’s TrustZone. TrustZone technology allows for the partition of a device’s System-on-Chip hardware and software into two worlds, the Secure World and the Normal (ie Non-Secure) World.
Theoretically, this provides software designers with a secure space to operate within and ensures that sensitive assets such as financial information or DRM keys are not accessible from the rest of the device.
However, as our recent white paper Security Analysis of TEEs on TrustZone shows, there are weaknesses in relying solely on TrustZone to maintain a secure TEE and DRM providers might find difficulties in relying solely on a TEE implementation to protect their assets.
A full discussion of the issues with supporting evidence is available in the white paper, but here we thought it might be valuable to briefly outline a selection of the recent vulnerabilities that have affected TEE implementations.
Assessing the vulnerabilities
There have been more than several published vulnerabilities on TEE implementations that illustrate the use of bugs in SMC handlers (SMC = Secure Monitor Calls, in charge of switching from the Normal World to the Secure World) and TAs handlers (Trusted Applications) to compromise the Trusted OS.
A lot of attention has been paid to vulnerabilities affecting SMC handlers, mainly because they may enable code execution in the most privileged mode of the processor: the monitor mode.
After having analyzed the format of the TEE image, for instance, Gal Beniamini took a special interest in the SMC opcodes, and realized he could erase the memory in the Trusted OS by issuing an SMC command formatted incorrectly (Beniamini, Exploring Qualcomm’s TrustZone implementation, 2015).
Altogether, research on the National Vulnerability Database for ‘TEE’ yielded 296 results as of 1 June 2020, either listed under the name of the TEE implementation or as 'TrustZone’. Our white paper delves into further detail on Beniamini’s example above, as well as others.
Another sector of vulnerabilities regarding TEE implementations is found in Trusted Applications themselves. While they directly only give access to the context of the TA, they can be used to further compromise the system by being chained with vulnerabilities in system calls or drivers.
For example, a complete chain of exploitation in Kinibi from high privilege in the Normal World to code execution in monitor mode (the previously-mentioned highest privileged mode of the processor) was presented at Blackhat in 2019 (see Breaking Samsung's ARM Trustzone). The authors used a stack-based buffer overflow in the command handler of the SEM Trusted Application (little is known about this application except that it performs cryptographic operations) to gain code execution in the Secure World with no privilege, and used several other vulnerabilities to chain exploitation until they gained code execution in the monitor mode.
This exploitation illustrates well how, while one avenue for hacking can be closed off, determined hijackers can still find a way around the new obstacles. At the time of the Blackhat submission, it was possible to place the secure monitor code in unprivileged memory. More recent versions of Kinibi contain a blacklist of addresses that should not be mapped, closing this off. However, the authors found this could be circumvented by erasing all the addresses of the blacklist. This gave the team the possibility to modify a SMC handler and gain code execution in monitor mode.
Over-reliance on TEE
The notion of the security of TEEs has been an important one underpinning much of the secure growth in many mobile computing solutions, from payments to DRM. However, as our paper shows, there are a growing number of vulnerabilities that can be exploited to lead to the compromise of the Trusted OS. This in turn can lead, for example, to surrendering access to the assets of the DRM to third parties and compromising the TEE.
Side-channel vulnerabilities and bugs based on speculative execution, such as Meltdown and Spectre, only serve to exacerbate the problem.
Our headline recommendation, therefore, is not to rely solely on TEEs, but to consider solutions using hardware resources such as keyladders and dedicated secure processors to handle the most critical secrets and decisions in addition to the TEE.