Trusted Execution Environment Tee

Hardware threats: ARM's architecture design

Software threats

Tee is a medium security level

The trusted execution Environment (TEE) is the concept presented by Global Platform (GP). For the open environment of mobile devices, security issues are becoming more and more popular, not only for end users, but also for service providers, mobile operators, and chip manufacturers. Tee is a running environment that coexists with the rich OS (usually Android, etc.) on the device and provides security services to Rich OS. It has its own execution space, which is higher than that of the rich OS, but is less secure than the security element (SE, usually smart card). But tee can meet the security needs of most applications. From a cost perspective, tee provides a balance between security and cost. Tee is focused on security as follows:

The use of open environment, so that equipment burst into the various attacks;

Privacy, personal information such as contacts, short messages, photos, videos, etc., need not be stolen, lost or attacked by malicious software;

Content protection, for DRM, conditional access services or content protection licensing, etc. also tend to use hardware-level protection;

Protection of company data, such as the credentials of a login VPN;

Connectivity protection, in the 3g,4g,wifi, and even NFC, the protection of key resources;

Financial risks, such as user interaction data in financial transactions (transaction content, turnover, user input pin, etc.).

Tee participants include SP, operator, OS and mobile application developer, device manufacturer, chip maker, etc.

As mentioned earlier, Tee is co-existing with rich OS and is visible.

The hardware and software resources that tee can access are separate from rich OS. Tee provides a secure execution environment for authorized security software (trusted applications, TA), while also protecting the confidentiality, integrity and access rights of TA's resources and data. To ensure that the tee itself has a trusted root, tee is validated during secure boot and isolated from rich OS. In tee, each TA is independent of each other and cannot be accessed without authorization.

GP in tee standardization, the basic specifications have tee internal Api,tee Client API, of course, there are a series of complementary functional API specifications, as well as application management, debugging functions, security outline and other specifications are being developed.

The tee internal API mainly includes key management, cryptographic algorithms, secure storage, secure clock resources and services, and an extended, trusted UI API. A trusted UI is when the display of critical information and user-critical data (such as a password) are entered, and hardware resources such as screen displays and keyboards are fully controlled and accessed by tee, and software in Rich OS is inaccessible. The internal API is the programming interface that tee provides to TA;

The Tee external API is the underlying communication interface that allows client applications (CAS) running in rich OS to access TA services and data.

Location of Tee

Tee is a framework that runs in the device and provides security between normal richos and SE (smart card). Many of the current security architectures are based on the rich OS + se approach, which does not provide a "just-in-good" fit for both convenience and cost. Because some small payments, DRM, Enterprise VPN, and so on, the need for security is not high, do not need a separate se to protect, but can not be placed directly in the rich OS, because the latter's openness makes it vulnerable to attack. So for this type of application, Tee provides the right level of protection and balances cost and ease of use. This can be seen from the analysis.

For anti-aggression, the SE is the highest, the rich OS is very low, and for access control love is similar to anti-aggression, but rich OS can do more, for the user interface, SE is powerless, and rich OS is the richest, the easy to develop, rich OS, of course, if the tee standard is good, It can also be done "fairly" easily; the speed of the tee is comparable to that of the rich OS, because the same physical processor used, SE is certainly slow; Finally, se is physically removable.

From a balance of cost and security, a presentation is given.

It can be seen that the additional cost increase is low when the tee is added, and it achieves a moderate level of protection, and additional costs are required if high-level protection is to be achieved. The analysis of this graph does not mean that the advent of tee does not require SE on the device, but as a level of medium security to meet the corresponding security objectives.

Specific Use Cases

Corporate Security Use cases : When users use mobile devices to access e-mail, intranet, and corporate documents, they need to have trustworthy end-to-end security to ensure that company data is protected on the device and that network authentication data is not misused. By separating key assets from the development environment, tee can increase the security of your company's applications in the following ways:

Corporate applications, such as email manager can rely on TA, to achieve sensitive functions such as encrypted storage and email access control;

VPN authentication can rely on TA, allow the security of VPN credentials and authentication algorithm implementation;

Access policies can be implemented in a trusted UI. When the need to access encrypted data and establish a network connection, users need to enter a password;

A one-time password (OTP) can be implemented by TA to use the smartphone as a secure authentication token, which is applicable when using a PC to log into the corporate network (two-factor authentication method).

Content Protection Use cases: for high-quality content such as music, video, books, and games, the appropriate SP also needs to have a content protection mechanism to prevent illegal copying and propagation. For content protection, there are several ways to do this:
Prevent copying systems (such as digital watermarks);

Digital Rights management system (such as Microsoft's PlayReady or OMA DRM);

Conditional receiving systems (such as nagra,nds,irdeto, etc.).

These content protection systems can also rely on the following functions of TA:

Store keys, credentials, and certificates;

Execute key software;

Perform critical content protection functions and/or delegate securely to SE.

Mobile Payment use case : mobile payment can be divided into remote mobile transactions, and near-field payment of two classes. The risk is that the malicious code in the device can do the following things without the user's knowledge:

Gets the user password or pin;

Modify the transaction data, such as the transaction amount;

Generate a transaction without user confirmation.

Tee provides protection for user authentication, transaction confirmations, and transaction processing with the help of the trusted UI features of tee.

The concept of tee is based on ARM's Trustzone technology, although GP has not explicitly documented this point. The Trustzone architecture is designed by arm system, and has full functionality and security considerations in terms of processor core and debugging functions. As a result, both arm and GP consider the security threats to OMTP's electronic consumer devices and the extended security threats mentioned in Omtp TR1. In the case of hardware security threats, ARM has made its attack more difficult and more costly in architecture design, and for software security threats it is no longer a game that takes root privileges of the operating system, but separates the execution space and resources of the rich OS and tee, unless the tee itself is flawed. Or TA contains malicious code, or software attacks can be very difficult. Of course, tee itself should be through a certain level of certification (EAL2 or EAL3, special industry applications EAL4 and above), and TA is sure to need the appropriate agency certification and signature to deploy to the device up. Whether it is tee certification, or TA's trusted management, is another heavyweight topic. Before that, how to implement rich OS and tee communication mechanism, efficient memory sharing mechanism, as well as the problems caused by multi-core architectures are all challenging topics.

Trusted execution Environment Tee (RPM)