GlobalPlatform TEE White Paper Feb2011

8/13/2019 GlobalPlatform TEE White Paper Feb2011

1/26

White Paper

February 2011

The Trusted Execution Environment:

Delivering Enhanced Security at a LowerCost to the Mobile Market

[email protected] | www.globalplatform.org | 2011 GlobalPlatform Inc.

TM

GlobalPlatform is a Trademark of GlobalPlatform, Inc.


2/26

2011 GlobalPlatform Inc. 2

About GlobalPlatform

Table of Contents

Publication Acknowledgements

Executive Summary

SECTION 1: The Need for Security in Mobile Handsets

1.1. Evolution of Security Needs

1.2. The Perspective from Different Actors

SECTION 2: Introducing the Trusted Execution Environment

SECTION 3: Positioning of the TEE

SECTION 4:

Detailed Use Case Implementation

4.1. Corporate Use Case

4.2. Content Management Use Case

4.3. Mobile Payment Use Case

4.4. Service Deployment in a TEE

SECTION 5: Why Standardize the TEE (proprietary vs. standard)?

SECTION 6: TEE Roadmap

SECTION 7: Conclusion

APPENDIX A: Abbreviations

APPENDIX B: Definitions

APPENDIX C: Comparing Rich OS, TEE, and SE

APPENDIX D: Table of Figures

APPENDIX E: Table of Tables


3/26


About GlobalPlatform

GlobalPlatform is a cross industry, not-for-profit association which identifies,develops and publishes specifications which facilitate the secure and interoperable

deployment and management of multiple embedded applications on secure chiptechnology. Its proven technical specifications are regarded as the internationalindustry standard for building a trusted end-to-end solution which serves multipleactors and supports several business models.

The freely available specifications provide the foundation for market convergenceand innovative new cross-sector partnerships. The technology has been adoptedglobally across finance, mobile/telecom, government, healthcare, retail and transitsectors. GlobalPlatform also supports an open compliance program ecosystem toensure the long-term interoperability of secure chip technology.

As a member-driven association with cross-market representation from all worldcontinents, GlobalPlatform membership is open to any organization operating withinthis landscape. Its 60+ members contribute to technical committees and market-ledtask forces.

Fo r f u r t h e r i n f o r m a t i o n , v i s it w w w . g l o b a lp l a t f o r m . o r g .


4/26


Publication Acknowledgements

GlobalPlatform wishes to offer special thanks to the members of the TrustedExecution Environment Task Force within the Device Committee and their respectiveorganizations for their involvement in developing this white paper.

Contributors include the following:

Full Members:

Samuel A. Bailey American ExpressDon Felton ARM ltdVirginie Galindo GemaltoFranz Hauswirth Giesecke & DevrientJanne Hirvimies NokiaMilas Fokle OrangeFredric Morenius ST EricssonChristophe Colas Trusted Logic (a subsidiary of Gemalto)

Participating Members:

Jean-Philippe Galvan Texas Instruments

GlobalPlatform Team Members:

Alliances Management Operations Secretariat

Gil Bernabeu GlobalPlatform Technical Director

Kevin Gillick Executive Director of GlobalPlatform


5/26


Executive Summary

This document explains the context and benefits related to the introduction of theTrusted Execution Environment (TEE).

As the mobile market matures and expands, an increasing number of securityconcerns demand attention. With end-users using their smartphone for a variety of

lifestyle applications, there is a proliferation of security needs that result from theuse of an open environment. Content protection, corporate environments,connectivity, and the rise of financial transactions in the mobile market exacerbatethese security concerns, which are relevant not just to the end-user. Serviceproviders, mobile network operators, OS and application developers, devicemanufacturers, platform providers, and silicon vendors are all key stakeholders inthis marketand thus have a vested interest in seeing proper security implemented.

The Trusted Execution Environment (TEE) offers the best route to meeting thesesecurity objectives and simultaneously addressing the needs of key stakeholders.The TEE is a separate execution environment that runs alongside the Rich OS and

provides security services to that rich environment. The TEE offers an executionspace that provides a higher level of security than a Rich OS; though not as secureas a Secure Element (SE), the security offered by the TEE is sufficient for mostapplications. In this way, the TEE delivers a balance allowing for greater securitythan a Rich OS environment with considerably lower cost than an SE.

Having established this high-level understanding, it is possible to recognize how theTEE delivers value for a host of use cases: corporate environments, contentmanagement, mobile payments, and service deployment (including servicedevelopment and service administration).

After recognizing the number of actors and use cases that benefit from TEEimplementation, it becomes apparent that standardization in this area brings a hostof benefits to the industry: better interoperability, greater certainty, and lower costs.Given GlobalPlatforms experience in this area (having delivered the TEE Client API1.0 specification in July 2010), it makes sense for GlobalPlatform to continue workingon the specification for the TEE Internal API as well as higher-level functional APIsfor the TEE Client API. An initial version is expected to be completed in 2011; givenGlobalPlatforms status as representing the entire mobile ecosystem, the resultingspecifications are sure to deliver all necessary market requirements.


6/26


SECTION 1: The Need for Security in Mobile Handsets

Prior to discussing the specifics of the Trusted Execution Environment, it is importantto note that the TEE has evolved as a result of security concerns in the mobilehandset market. The TEE as a separate execution environment is critical not onlybecause of the number of factors involved, but also because of the broad range ofactors that is impacted by these security factors. Understanding these securityconcerns will help to lay the foundation for the need of the TEE in mobile handsets.

1 . 1 . Ev o l u t i o n o f S e cu r i t y N e e d s

Theft and fraud are ever-present in the mobile market. To support the widespreadadoption of new services and to address the convergence between the mobileecosystem and the Internet, increased levels of device security are essential.

Consider that todays phone handsets have evolved from the basic communicationdevices of the past; they have become lifestyle devices that include multimediaplayers, cameras, location devices, portable offices, and, in the near future, m-walletand tele-healthcare functionality. They help us perform our daily working tasks,entertain us, capture the memories we cherish, and facilitate routine transactions. Asusers accumulate a wealth of valuable personal data and information, we arereminded that it needs to be protected so as to maintain trust.

As we delve deeper into the security requirements for mobile devices, there are anumber of factors and situations that serve to expand the landscape for our securityconcerns:

Use of Open Environment : New devices are generally built with operatingsystems that provide an open environment. A key benefit of this is that userscan add applications at any time, often with little concern as to the impact onthe stability and security of the device. This new environment, however,exposes devices to an expanding variety of attacks. Device manufacturers

want to take advantage of such Operating Systems but need to be in controlof how the software that runs on the device behaves.

Privacy: Devices store increasing amounts of personal information (such ascontacts, messages, photos, video clips) and even sensitive data (credentials,passwords, medical data, etc.). To prevent exposure of this information in theevent of loss, theft, or another negative event (such as malware), sufficientsecurity is needed to store and distribute personal data.

Content Protection : Todays devices offer HD video playback andstreaming, mobile TV broadcast reception, and console-quality 3-D games. Allof this functionality requires content protection, Digital Rights Management(DRM), or Conditional Access (CA) services to protect high-value HD content.The DRM and CA schemes are often associated with content management andprotection models, such as Content Management License Administrator(CMLA) or Content Protection for Recordable Media (CPRM), which favorhardware-strengthened content protection. They are also often associatedwith penalty clauses so as to further motivate OEMs to adopt strongprotection schemes.


7/26


Corporate Data : Enterprise-type devices that enable push e-mail access andoffice applications give employees a work anywhere, anytime ability thatrequires a secure and fast link to their workplace applications through VirtualPrivate Networking (VPN), secure storage of their data, and remotemanagement of the device by the IT department. Company IT professionalsare often wary of enabling connectivity access to their internal networks,

fearing that the devices could carry malware and create attacks from withinthe internal network when used outside of company premises. Therefore, ITdepartments frequently establish green-lists and red-lists of devices based ontheir security capabilities. They are also concerned by the always-on nature ofthese devices and the enforcement of password protection and device lockingwhen not actively in use.

Connectivity Protection : Networking through multiple technologiessuchas 3G, 4G or Wi-Fi/WiMAX, as well as personal communication means, suchas Bluetooth and Near Field Communication (NFC)increasingly enablesconsumers to use their devices for peer-to-peer communication and to accessthe Internet. Such access, including web services or remote storageimplemented thanks to cloud computing, typically uses SSL/TLS or IPSecinternet secure protocols. In some use cases, the weak point of suchcommunication is the handling of the key material that needs to be secured.In other use cases, the client end of the session needs to be secured.

Financial Risks : Financial transactions are emerging, including ticketing,remote payment, and proximity payment functionalities. In some cities, it ispossible to instantly purchase transportation or movie tickets or pay for asmall purchase in a retail outlet by waving a mobile device next to a Point ofSale (POS) terminal. These transactions are typically capped at a specificpurchase limit in order to manage risk, with higher levels of security requiredfor payments above a certain amount. In some economic models, the deviceitself becomes the POS terminal.

All of these factors present security concerns that must be addressed in the mobilemarket, and as we shall see, the TEE is capable of addressing each.

1 . 2 . T h e Pe r s p e c t i v e f r o m D i f f e r e n t A c t o r s

As described in the previous, security measures are becoming an inherentrequirement of mobile applications and services for many market segments in themobile market. Furthermore, the TEEs value can be better understood whenconsidering that it offers solutions to all actors of the value-chain:

Service Providers : All smartphone users know that deploying services indevices has become commonplace. Service providers face new requirements

in this evolving market, such as privacy, strong authentication, guaranteedquality of service with limited (or rupture of) network connectivity, protectionof value-added content, deployment of services in an open environment,security regulation, etc. In this context, a controlled and trusted executionenvironment becomes a key demand from Service Providers to protect theirbusiness.


8/26


9/26


Regardless of the actor being discussed, one thing is certain: security is critical. Asis alluded to above, the TEE provides a path to resolving these security needs whilestill enabling the key performance that is required.


10/26


SECTION 2: Introducing the Trusted Execution Environment

Addressing the security concerns discussed in the previous section is most easilydone via the Trusted Execution Environment (TEE). The TEE is a separate executionenvironment that runs alongside the Rich OS and provides security services to thatrich environment. The TEE isolates access to its hardware and software securityresources from the Rich OS and its applications. The Figure below shows thearchitecture of the TEE.

Hardware Platform

Rich OS Application Environment

Rich OS

GlobalPlatformTEE Client API

Trusted Execution Environment

Trusted CoreEnvironment

GlobalPlatformTEEInternal API

TrustedFunctions

Payment Corporate

GlobalPlatformTEE Functional API

GlobalPlatformTEE Functional API

Client Applications

GlobalPlatform TEE Client API

Trusted Applic atio n

DRM

Trusted Applic atio n

Payment

Trusted Applic ation

Corporate

HW Keys,Secure Storage,Trusted UI (Keypad,Screen),

Crypto accelerators,NFC con troller,

Secure Element, etc.

HW SecureResources

EnvironmentTrusted Core Trusted

Functions

GlobalPlatformTEE Internal

TEE Kernel

API

Figure 1 : Architecture of the TEE

As this Figure illustrates, the TEE offers safe execution of authorized securitysoftware, known as Trusted Applications ; it also enforces protection,confidentiality, integrity, and access rights of the resources and data belonging tothose Trusted Applications. In order to guarantee the root of trust of the TEE, theTEE is authenticated and then isolated from the rest of the Rich OS during the secureboot process.

Inside the TEE, each Trusted Application is independent from the others, and aTrusted Application cannot perform unauthorized access to security resources fromanother Trusted Application. Trusted Applications can originate from differentapplication providers, and it is expected that the TEE standardization will enable alarge ecosystem of Trusted Application providers.

Trusted Applications are given controlled access to security resources and servicesvia the TEE Internal API , which is currently being standardized by GlobalPlatform(the TEE Client API was standardized by GlobalPlatform in 2010). Such resources andservices may include key injection and management, cryptography, secure storage,secure clock, Trusted UI, Trusted keyboard stroke, etc.


11/26


As defined by GlobalPlatfom, a TEE will undergo a qualification process, which willinclude functional testing (compliance) and security evaluation testing (certification).This qualification process is being defined and will be based on the securityrequirements of OMTP TR1 Profile 2.

The public/available/published TEE Client API is a low level communication

interface designed to enable a Client application running in the Rich OS to access andexchange data with a Trusted Application running inside a Trusted ExecutionEnvironment. The specification for the TEE Client API can be downloaded from theGlobalPlatform website.

Finally, in order to complete the ecosystem, a TEE Functional API will offer Clientapplications a set of Rich OS-friendly APIs. These will allow access to some TEEservices, such as cryptography or secure storage, with a programming model familiarto Rich OS application developers. The definition of the TEE Functional API is part ofthe GlobalPlatform TEE deliverables roadmap.


12/26


SECTION 3: Positioning of the TEE

The TEE provides a framework for security within the device, offering a layer ofsecurity between a typical Rich OS and a typical SE.

At present, serious mobile security solutions rely primarily on an SE. This is requiredmainly to provide a secure control mechanism that is supported by most financialinstitutions, including banks and credit card companies. However, several use caseshave less stringent security requirements and, further, cannot be executed becauseof the performance, interaction, and user experience limitations of an SE.

In general, the level of security required should be proportional to the importance ofthe asset. A higher level of security should be balanced against a faster, easier, andmore attractive device use experience. The following are a few examples of how toposition the TEE vis--vis an SE:

Although the SE brings a higher level of security to execute mobile financialtransactions, not all transactions actually require that level of risk mitigation.The need for security depends on the type of the operation, the amount of the

transaction, and/or the users profile and history. For example, one study onthis topic 2

Enterprise networking can be appropriately protected with authentication andencryption that can be provided by the TEE while offering a level ofperformance comparable to the Rich OS.

has shown that most of the financial transactions people do withtheir mobile devices are below $10.

The TEE is an ideal environment to host DRM agents that protect content orapplications downloaded from an app store. By contrast, this environmentwould be easy to forge in a Rich OS.

So, if we understand a Rich OS to be a rich environment that is vulnerable toattacks, and an SE as resilient to attacks but somewhat limited, the TEE serves as aneeded compromise between Rich OS performance and SE security.

2 Mobile Financial Services: Banking & Payment Markets 2007-2011 Juniper Research September 2008.


13/26


Rich OS

TrustedExecutionEnvironment (TEE)

SecureElement (SE)

UserInterface

PhysicallyRemovable

Ease ofDevelopment

ProcessingSpeed

AttackResistance AccessControl

Figure 2 : Rich OS, TEE and SE Positioning

Figure 2 represents the security and usability characteristics in particularenvironmentsa Rich OS, TEE, and SE. However, the capabilities indicated are not ofthe same strength on the whole range of a particular implementation of anenvironment. The diagram reflects this through the given width and height of thearrows.

In very general terms, the TEE offers an execution space that provides a higher levelof security than a Rich OS; though not as secure as an SE, the security offered bythe TEE is sufficient for most applications. Moreover, the TEE provides a morepowerful processing speed capability and greater accessible memory space than anSE (these are, in fact, quite similar to that of a Rich OS).

Because the TEE supports more user interface capabilities and peripheral connectionsthan an SE, it allows development of security applications that enable a rich userexperience. In addition, since the TEE is isolated from the Rich OS environments (asa result of software partitioning), it leverages the Rich OS functionality whilemaintaining adequate security. In particular, the TEE is able to resist softwareattacks occurring in the Rich OS (e.g. OS rooting, jailbreaking, malware, etc.).

By contrast, the SE supports physical robustness and high tamper resistance againstside channel attacks; therefore, it is certifiable at the highest security levels (EAL4+and above with SmartCard Protection Profile). Removable SEs can support securityand data mobility (such as UICC or MicroSD) and are therefore transferable from onedevice to another. NFC-enabled SEs can be used in low-power or no-power modeswhen device electrical power is low or drained.


14/26


Ultimately, this discussion makes obvious the conclusion that security is acompromise: it requires balancing the cost of the protection with the cost of theattack. Embedded within this high-level conclusion are several other driving factors:

The inconvenience to the user

The cost of training and supporting the user The direct and indirect value of the asset being protected

The cost to attack the asset in other manners

The awareness of the attackers that there is an asset to be attacked

Figure 3 below illustrates the security positioning for the TEE as compared to a RichOS alone or an SE.

Figure 3 : Security vs. investment

It is important to note that the TEE is not mutually exclusive to an SE. Rather, it canserve as a complementary security countermeasure and integrating nucleus (i.e.

glue technology) for services that depend on partial identities distributed acrossSEs, such as Active Stickers, Secure Micro SD Cards, UICCs, and Embedded SEs. TheTEE combines these into integrated solutions, which assures seamless interactionand security of processes that are executed in the periphery of the respective SE.

Together with the TEE, SEs can reach unprecedented levels of certified security whiledelivering convenient, integrated solutions to the end consumer. For example, the

TEE can enable Secure User Interfaces (UIs) and OTA credential provisioning tosecurely isolated Security Domains, as well as the different Applications stored ineach one of these.


15/26


SECTION 4: Detailed Use Case Implementation

To better understand the TEE, it will be valuable to explore a number of use caseseach with distinct needs that can be met by the TEE.

4 . 1 . Co r p o r a t e U s e Ca s e

A primary driver of the security development in the mobile Internet is theconfidentiality required for corporate use situations. When the end-user uses amobile device to access email, intranet, and corporate documents, there is a need forreliable, end-to-end security that ensures the following:

That corporate data is protected when stored on the device That corporate network authentication data (i.e. cryptographic certificates and

keys) is not misused

By isolating the critical assets from the open environments, the TEE is a layer ofprotection that enables secure usage of smartphones in enterprises. The TEE can beused in different ways to increase security for corporate applications:

Corporate applications such as an e-mail manager or CRM application can relyon Trusted Applications, which require implementation of the sensitivefunctionalities, such as encrypted storage and controlled access to e-mail orcustomer information.

VPN authentication can rely on Trusted Applications, which allow for secureVPN credential provisioning and reliable authentication cryptographiccalculation.

A corporate access policy rule can be implemented thanks to a TEE-basedTrusted User Interface. One such implementation would require the user toenter a password prior to accessing the encrypted corporate data andconnecting to the corporate network.

A One-Time-Password (OTP) application can be securely implemented in theform of a Trusted Application, and thereby use the smartphone as a secureauthentication token; this could happen, for example, when logging -on to thecorporate network from a PC (two-factor authentication method).

Furthermore, the TEE provides an execution environment with a speed of executioncomparable to the Rich OS. Therefore, the security features required to support thecorporate use case will not significantly impact the overall user experience.

4 . 2 . Co n t e n t M a n a g e m e n t U s e Ca s e

Smartphones, tablets, and portable multimedia players enable users to enjoy highquality content, such as music, video, books, and games. While the user benefits

from this increased smartphone capability, businesses that provide such contentrequire content protection mechanisms to shield their businesses from illegal copyingor distribution. Below are a few core types of content protection available:

Copy protection systems that prevent digital duplication (e.g. watermarking) Digital rights management systems that control access to the multimedia

content when being used (e.g. Microsoft PlayReady or OMA DRM)


16/26


Conditional access systems that control broadcast content reception andusage (e.g. Nagra, NDS, Irdeto, Viaccess, and OMA BCAST)

These content protection systems would benefit from the TEE by relying on TrustedApplications for the following:

Storing keys, credentials, and certificates Executing the critical software of the on-device content protection system Executing the critical content protection functions and/or securely delegating

to the Secure Element and its secured access

4 . 3 . M o b i l e P a y m e n t U s e Ca s e

A majority of market analysts are predicting large growth in the area of mobile-based financial services. Smartphones are personal and convenient platforms toperform such financial transactions.

There are specific types of mobile financial services that tend to be targeted atsmartphones. They include mobile banking, mobile payment, mobile money transfer,and mobile authentication (e.g. use with One-Time Password OTP technology). Forthe purpose of discussing the value that the TEE brings to the table, let us focus hereon mobile payment.

It is important to note that mobile payment covers many types of transactions thatfit into two categories: 1) transactions with a remote merchant or entity, and 2)transactions that are a proximity payment at a merchant site.

The first scenario, remote payments, involves an online transaction where the usersmoney is transferred to another entity to pay for a good or a service. In a remotepayment scheme on the smartphone, the most sensitive operations are userauthentication and transaction validation.

The second scenario, proximity payments with mobile phones, is expected to becomewidespread with the deployment of Near-Field Communication (NFC) technology.NFC enables transactions to be processed quicklyby just bringing the phone inproximity of a readerresulting in a streamlined user experience. Because thesetransactions are generally offline, they require a security component in the handsetthat is capable of mitigating the risk usually handled by online risk management.This security component is the Secure Element, which can take the form of a UICC,an embedded Secure Element, or a microSD card. Additionally, in NFC-basedtransactions, some sensitive operations are directly performed on the smartphone,such as the transaction validation when the payment amount value is above acertain threshold amount.

As more financial transactions take place within a smartphones open platform, thedoor is opened to an increased risk of malware that could induce the following:

Retrieval of user passwords and PIN codes for user authentication andtransaction validation

Modification of transaction essential data, such as transaction amount Generation of transactions without user validation


17/26


The TEE is a unique environment that is capable of increasing the security andassurance level of these transactions if the transaction is conducted online or coupledwith a Secure Element. Areas that the TEE is protecting include the following:

User Authentication : through its Trusted User Interface feature, the TEEmakes it possible to securely collect a user password or PIN code that willthen be verified locally, on a remote server, or within a Secure Element.

Transaction Validation : through its Trusted User Interface, the TEE makesit possible to ensure that the information displayed accurately portrays theapplications requestas opposed to displaying misinformation offered by arogue application. Furthermore, it prevents transaction validation without theexplicit authorization of the user (e.g. through a user PIN code).

Transaction Processing : any processing that needs to reside on thehandset can be isolated from any untrusted software attack by beingexecuted in the TEE and leveraging any of the devices resources.

When the payment application resides in the SE, the TEE complements the SE by

providing functionality such as the Trusted User Interface. This highlights the need tomake sure that richer applications that may interact with the application residing inthe SE can assure confidentiality and integrity with a friendly user experience, suchas a user entering a PIN.

4 . 4 . S er v i c e D e p l o y m e n t i n a T E E

4.4.1. Service Development

A Trusted Application is the means for a Service Provider to deploy secure services ina smartphone that supports a TEE. The Trusted Application is executed in a securemanner in the TEE and relies on the TEEs Internal API. Examples of servicesavailable in the TEE include key management, key storage, secure storage of data,

and cryptographic operations. Nevertheless, all of the operations of a given servicedo not need to be executed in the Trusted Application that is located in the TEE.Thanks to a distributed architecture, the Rich OS can execute part of thefunctionalities.

A traditional smartphone application is split into two parts when using the TEE: onepart will be executed in the Rich OS while the other part will use the security-centricTEE Internal APIs. The limitation of such an architecture is that the service will bedeveloped for a given smartphone while all Trusted Applications that rely onstandardized TEE Internal API will be portable on any TEE that is compliant withGlobalPlatform specifications.

Standardization of the TEE Internal API is underway, and as of this writing, thestatus is as follows:

The communication between the distributed parts of a service is based on astandardized TEE Client API, issued by GlobalPlatform in Summer 2010. Ahigher-level TEE Functional API is expected by end-2011.


18/26


The complete set of features available to Trusted Applications will bedescribed in the TEE Internal API, which is under construction withinGlobalPlatform and is expected to be issued in 2011.

TEE compliance tests are expected to be developed by GlobalPlatform in2011.

4.4.2. Service AdministrationToday, the standard way for deploying secure services that rely on TEE technology iswhile the TEE is being integrated into the device. However, this model needs to bechanged so that several parties can load new Trusted Applications.

As part of its 2011 deliverables, GlobalPlatform plans on defining an interoperableway to administrate Trusted Applications in the TEE.

4.4.3. An Example of Service Development: Corporate Use Case

A Trusted Application can support the deployment of Corporate Services. In caseswhere the Corporate Services rely on a VPN, credentials need to be securely storedin the memory managed by the TEE. Additionally, sensitive documents managed inthe framework of office tools should be stored securely in the same kind of memory.One possible architecture that would provide a solution would be to have a TrustedApplication, stored and executed in the TEE, which would be in charge of VPNchannel establishment and access control to sensitive documents. Those Trustedfunctions, implemented in the Trusted Application, would be accessed thanks to aTEE Client API running on the Rich OS.


19/26


SECTION 5: Why Standardize the TEE (proprietary vs. standard)?

Standardization of the TEE is key to both avoid fragmentation of APIs and protectdifferentiation. Fragmentation would lead to the proliferation of non-compatible,proprietary security features, applications, and management systems platform,which would in turn lead to the following:

Higher costs to develop or change applications/solutions when creating oradapting to proprietary platforms

The need for very specialized skills Extended time-to-market due to longer development times and potential

integration issues

Standardization enables simplified and unified implementation, limits complexities,and improves interoperability between stakeholders. Furthermore, standardizationallows for multiple business partners and, because it ensures long-term stability andsurvivability, protects investment in a way that proprietary solutions cannot. It alsodefines a basis for evaluating and comparing different solutions. Lastly,standardization creates a foundation for a certification process.

Created in 1999 to standardize smart card infrastructure, GlobalPlatform cardspecifications are now embedded in more than 5 billion Secure Elements. As arecognized standards body, GlobalPlatform represents the full ecosystem, includingchip manufacturers, IP providers, software developers, OEMs, network operators,service providers, certification laboratories, and more.

Following its OMTP and TCG standardization efforts, GlobalPlatforms DeviceCommittee delivered the TEE Client API 1.0 specification in July 2010. TheCommittee is now actively working on the specification for the TEE Internal API, aswell as higher-level functional APIs for the TEE Client API.


20/26


21/26


SECTION 7: Conclusion

There are today increasing security concerns resulting from increased mobilehandset usage, and the TEE offers the market a solution that addresses many ofthese concerns without imposing an undue burden on applications.

The TEE is a separate execution environment that runs alongside the Rich OS andprovides security services to that rich environment. This is accomplished whileprotecting and isolating access to hardware and software security resources from theRich OS and its applications.

The TEE protects the assets that fall between a secure element and Rich OS. Itprovides robust, hardware-backed, scalable-consistent, OS-independent security.Furthermore, it offers device features and performance that cannot be delivered by asecure element.

The definition of the TEE is an effort in progress and follows a roadmap for thedevelopment of standardized security features in mobile devices. Following the TEE

Client API 1.0 specification delivered by GlobalPlatforms Device Committee in July2010, the Committee is now actively working on the specification for the TEE InternalAPI, as well as higher-level functional APIs for the TEE Client API. It is expected thatthese will be completed in 2011.

The result of this activity will be a standardized TEE that will not be subject to thewhims of proprietary solutions. Multiple business partners across all relevant marketsegments will benefit from the standardization: greater long-term continuity, greaterstability, and lower costs.


22/26


APPENDIX A: Abbreviations

Abbreviation Meaning

CA Conditional AccessCC Common Criteria

CMLA Content Management License Administrator

CPRM Content Protection for Recordable Media

DRM Digital Rights Management

EAL Evaluation Assurance Level

HD High-Definition

HLOS High-Level Operating System

IPsec Internet Protocol SecurityMNO Mobile Network Operator

MFS Mobile Financial Services

NFC Near Field Communication

OEM Original Equipment Manufacturer

OMTP Open Mobile Terminal Platform

OS Operating System

OTA Over-the-Air

OTP One-Time-Password

POS Point Of Sale

SE Secure Element

SSL Secure Socket Layer

TEE Trusted Execution Environment

TLS Transport Layer Security

UI User Interface

UICC Universal Integrated Circuit Card

VPN Virtual Private Network


23/26


APPENDIX B: Definitions Rich OS:

A High-Level Operating System (HLOS) environment with a rich capability set;further, it allows consumers to download and run applications. Android, Linux,Symbian OS, and Microsoft Windows Phone 7 are examples of a Rich OS.

Secure Element (SE):

A tamper-proof combination of hardware, software and protocols capable ofembedding smart card-grade applications. Typical implementations include UICC,embedded SE, and removable memory cards.

Trusted Execution Environment (TEE):

A separate execution environment that runs alongside the Rich OS. The TEE providessecurity services to that rich environment and isolates access to its hardware andsoftware security resources from the Rich OS and its applications.


24/26


APPENDIX C: Comparing Rich OS, TEE, and SE

The table below summarizes security and computational facilities offered by typicalimplementations of the three environments, in order to identify their fundamentaldifferences.

Rich OS TEE SE

Application downloadcontrolled by

User choice. Authorizationprocess.

Authorizationprocess.

Application code Typically un-validated anduncertified.

Typically validatedand certified beforeauthorization, and inauthorizationchecked on loading.

Typically validatedand certified beforeauthorization, and inauthorizationchecked on loading.

Isolation Limited by Rich OScapabilities someRich OS may providea sandbox model(e.g. Java VM) orsupport virtualization

The TEE is separatefrom the Rich OS the depth isolationrelies on thestrength of the TEEimplementation

Isolated physically runs a separate OS(e.g. JavaCard,STIP, etc.)

Certification Uncertified Certified Strongly certified

OS Kernel, driverand library code

Created for flexibilityand speed

Created for securityand speed

Created for security

Rich API set Limited API set Very limited API set

Typically large RAMsize

Typically mediumRAM size

Typically small RAMsize

Confidential andintegrity of access touser interfacedevices (Keyboard,screen, audio I/O)

Within the limits ofthe Rich OScapability

Confidentiality- andintegrity-bounded bythe TEE (the TEE canhave access to userinterfaces which areisolated from theRich OS)

Only indirectly, andso bounded bydelegation from anexternal enablersuch as Rich OS orTEE.

CPU speed GHz range Hundreds MHz toGHz range

Few to 20 MHz range

Cores 1->4 1 master 1

RAM size 16MB->1GB+ 64KB to many MBsecure A few 10's of KB

RAM speed 64 bits @ 200Mhz ->800Mhz

64 bits @ 200Mhz ->800Mhz

32 bits @ 5Mhz

(limited by power)

FLASH size 1GB-> 32GB + (incSD cards etc)

shared with Rich OS each Trusted

64KB-> 1 MB


25/26


Application mayhave its own securestorage

Data Transfers withRich OS

Very fast Very fast Slow

Protection againstunauthorizedsoftware attack,including softwaremaking "illegal" useof hardware on thedevice

Confidentialityinternally protectedby non-certified OS

ConfidentialityProtected vs. RichOS and devicehardware. Internallyprotected bycertified OS

ConfidentialityProtected vs.external softwareand devicehardware. Internallyprotected bycertified OS

Limited integrityprotection duringboot (TypicallyKernel only)

Integrity Protectedvs. Rich OS anddevice hardware.Internally protectedby certified OS

Integrity Protectedvs. external softwareand devicehardware. Internallyprotected bycertified OS (andother mechanisms?)

Protection againstexternal hardwareattack

no protectionsagainst attacks

limited anti-rollbackprotection

Protection dependingon TEEimplementationmechanisms andhardware features ofhosting platform

Strong protectionfor SE but not forhosting device

Protection guardingthe device, i.e.preventing the

device from beingunlocked or flashedwith unauthorizedsoftware

Optional secure boot TEE mandatessecure boot

Often triviallyremovable from thedevice by user or

attacker. Any linkagewith the device canonly be as strong asthe security guardingthe weakest part ofthat link (typically onthe device andtypically the weakpoint being the RichOS or TEE)

Table 2 Comparison between Rich OS, TEE and SE


26/26

APPENDIX D: Table of Figures

Figure 1 : Architecture of the TEE ..................................................................... 10

Figure 2 : Rich OS, TEE and SE Positioning ........................................................ 13

Figure 3 : Security vs. investment .................................................................... 14

APPENDIX E: Table of Tables

Table 1 TEE Specifications Roadmap .............................................................. 20

Table 2 Comparison between Rich OS, TEE and SE .......................................... 25

Documents

GlobalPlatform TEE White Paper Feb2011