The Trusted Execution Environment:

Transcription

1 The Trusted Execution Environment: Delivering Enhanced Security at a Lower Cost to the Mobile Market White Paper February 2011 secretariat@globalplatform.org GlobalPlatform Inc.

2 Table of Contents About GlobalPlatform 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: SECTION 3: Introducing the Trusted Execution Environment 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: SECTION 6: SECTION 7: Why Standardize the TEE (proprietary vs. standard)? TEE Roadmap 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 2011 GlobalPlatform Inc. 2

3 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 chip technology. Its proven technical specifications are regarded as the international industry standard for building a trusted end-to-end solution which serves multiple actors and supports several business models. The freely available specifications provide the foundation for market convergence and innovative new cross-sector partnerships. The technology has been adopted globally across finance, mobile/telecom, government, healthcare, retail and transit sectors. GlobalPlatform also supports an open compliance program ecosystem to ensure the long-term interoperability of secure chip technology. As a member-driven association with cross-market representation from all world continents, GlobalPlatform membership is open to any organization operating within this landscape. Its 60+ members contribute to technical committees and market-led task forces. For further information, visit GlobalPlatform Inc. 3

4 Publication Acknowledgements GlobalPlatform wishes to offer special thanks to the members of the Trusted Execution Environment Task Force within the Device Committee and their respective organizations for their involvement in developing this white paper. Contributors include the following: Full Members: Samuel A. Bailey American Express Don Felton ARM ltd Virginie Galindo Gemalto Franz Hauswirth Giesecke & Devrient Janne Hirvimies Nokia Milas Fokle Orange Fredric Morenius ST Ericsson Christophe 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 2011 GlobalPlatform Inc. 4

5 Executive Summary This document explains the context and benefits related to the introduction of the Trusted Execution Environment (TEE). As the mobile market matures and expands, an increasing number of security concerns demand attention. With end-users using their smartphone for a variety of lifestyle applications, there is a proliferation of security needs that result from the use of an open environment. Content protection, corporate environments, connectivity, and the rise of financial transactions in the mobile market exacerbate these security concerns, which are relevant not just to the end-user. Service providers, mobile network operators, OS and application developers, device manufacturers, platform providers, and silicon vendors are all key stakeholders in this market and thus have a vested interest in seeing proper security implemented. The Trusted Execution Environment (TEE) offers the best route to meeting these security 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 execution space that provides a higher level of security than a Rich OS; though not as secure as a Secure Element (SE), the security offered by the TEE is sufficient for most applications. In this way, the TEE delivers a balance allowing for greater security than a Rich OS environment with considerably lower cost than an SE. Having established this high-level understanding, it is possible to recognize how the TEE delivers value for a host of use cases: corporate environments, content management, mobile payments, and service deployment (including service development and service administration). After recognizing the number of actors and use cases that benefit from TEE implementation, it becomes apparent that standardization in this area brings a host of benefits to the industry: better interoperability, greater certainty, and lower costs. Given GlobalPlatform s experience in this area (having delivered the TEE Client API 1.0 specification in July 2010), it makes sense for GlobalPlatform to continue working on the specification for the TEE Internal API as well as higher-level functional APIs for the TEE Client API. An initial version is expected to be completed in 2011; given GlobalPlatform s status as representing the entire mobile ecosystem, the resulting specifications are sure to deliver all necessary market requirements GlobalPlatform Inc. 5

6 SECTION 1: The Need for Security in Mobile Handsets Prior to discussing the specifics of the Trusted Execution Environment, it is important to note that the TEE has evolved as a result of security concerns in the mobile handset market. The TEE as a separate execution environment is critical not only because of the number of factors involved, but also because of the broad range of actors that is impacted by these security factors. Understanding these security concerns will help to lay the foundation for the need of the TEE in mobile handsets Evolution of Security Needs Theft and fraud are ever-present in the mobile market. To support the widespread adoption of new services and to address the convergence between the mobile ecosystem and the Internet, increased levels of device security are essential. Consider that today s phone handsets have evolved from the basic communication devices of the past; they have become lifestyle devices that include multimedia players, cameras, location devices, portable offices, and, in the near future, m-wallet and tele-healthcare functionality. They help us perform our daily working tasks, entertain us, capture the memories we cherish, and facilitate routine transactions. As users accumulate a wealth of valuable personal data and information, we are reminded that it needs to be protected so as to maintain trust. As we delve deeper into the security requirements for mobile devices, there are a number of factors and situations that serve to expand the landscape for our security concerns: Use of Open Environment: New devices are generally built with operating systems that provide an open environment. A key benefit of this is that users can add applications at any time, often with little concern as to the impact on the 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 control of how the software that runs on the device behaves. Privacy: Devices store increasing amounts of personal information (such as contacts, messages, photos, video clips) and even sensitive data (credentials, passwords, medical data, etc.). To prevent exposure of this information in the event of loss, theft, or another negative event (such as malware), sufficient security is needed to store and distribute personal data. Content Protection: Today s devices offer HD video playback and streaming, mobile TV broadcast reception, and console-quality 3-D games. All of 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 and protection models, such as Content Management License Administrator (CMLA) or Content Protection for Recordable Media (CPRM), which favor hardware-strengthened content protection. They are also often associated with penalty clauses so as to further motivate OEMs to adopt strong protection schemes GlobalPlatform Inc. 6

7 Corporate Data: Enterprise-type devices that enable push access and office applications give employees a work anywhere, anytime ability that requires a secure and fast link to their workplace applications through Virtual Private Networking (VPN), secure storage of their data, and remote management of the device by the IT department. Company IT professionals are often wary of enabling connectivity access to their internal networks, fearing that the devices could carry malware and create attacks from within the internal network when used outside of company premises. Therefore, IT departments frequently establish green-lists and red-lists of devices based on their security capabilities. They are also concerned by the always-on nature of these devices and the enforcement of password protection and device locking when not actively in use. Connectivity Protection: Networking through multiple technologies such as 3G, 4G or Wi-Fi/WiMAX, as well as personal communication means, such as Bluetooth and Near Field Communication (NFC) increasingly enables consumers to use their devices for peer-to-peer communication and to access the Internet. Such access, including web services or remote storage implemented thanks to cloud computing, typically uses SSL/TLS or IPSec internet secure protocols. In some use cases, the weak point of such communication 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 is possible to instantly purchase transportation or movie tickets or pay for a small purchase in a retail outlet by waving a mobile device next to a Point of Sale (POS) terminal. These transactions are typically capped at a specific purchase limit in order to manage risk, with higher levels of security required for payments above a certain amount. In some economic models, the device itself becomes the POS terminal. All of these factors present security concerns that must be addressed in the mobile market, and as we shall see, the TEE is capable of addressing each The Perspective from Different Actors As described in the previous, security measures are becoming an inherent requirement of mobile applications and services for many market segments in the mobile market. Furthermore, the TEE s value can be better understood when considering that it offers solutions to all actors of the value-chain: Service Providers: All smartphone users know that deploying services in devices has become commonplace. Service providers face new requirements in this evolving market, such as privacy, strong authentication, guaranteed quality of service with limited (or rupture of) network connectivity, protection of value-added content, deployment of services in an open environment, security regulation, etc. In this context, a controlled and trusted execution environment becomes a key demand from Service Providers to protect their business GlobalPlatform Inc. 7

8 Mobile Network Operators: MNOs are considered reliable partners for service deployments on smartphones. The use of a UICC (usually owned and managed by the MNO) is relevant to deploy some services, but for some applications that exceed the resource capabilities of the UICC, there is a need to have a higher level of security than what the Rich OS offers. The Advanced Trusted Environment: OMTP TR1 specification 1 provides a mechanism to satisfy this requirement by delivering a comprehensive security roadmap aligned with current threats, business opportunities, and the overall industry objectives of achieving hardware-backed security. OS and Application Developers: A well-defined and standardized TEE allows defragmentation and creates broader alignment in the industry around commonly deployed security frameworks and associated software and APIs. This allows for a large ecosystem of application vendors in numerous segments and industries, which ultimately leads to greater economies of scale. Device Manufacturers: With mobile devices handling more and more sensitive data (banking, payment, , etc.), there is an increased need for a robust security model built into the device itself. The trustworthiness of the device is key to enabling these services to consumers. Furthermore, the device must deliver a robust and flexible security system that covers the needs of multiple stakeholders: operators, service providers, legislation authorities, enterprise, and the end user. The large amount of code in mobile device software, however, is proving to be a limitation: It will never be robust enough, and there will always be holes and bugs that hackers can exploit. Furthermore, in open software platforms, the user has the capability to change the software in the device. This raises the need to have a small, OS-independent, isolated, and extendable execution environment that operates deterministically even in un-trusted open source surroundings. Platform Providers and Silicon Vendors: The TEE enables hardwarebacked security for fundamental and sensitive hardware and software assets. TEE standardization enables interoperability and defragmentation without compromising overall platform differentiation and opportunities to add value. As applications and services are deployed, liability and underwriting models appear to reinforce the need for stronger security. Though different actors contribute different pieces of the value chain, it is a fundamental best practice that security protection is provided end-to-end since security is only as strong as the weakest link of the end-to-end solution. Confidence and trust are paramount to the adoption and growth in the handset market and mobile services. 1 For more information on this specification, visit GlobalPlatform Inc. 8

9 Regardless of the actor being discussed, one thing is certain: security is critical. As is alluded to above, the TEE provides a path to resolving these security needs while still enabling the key performance that is required GlobalPlatform Inc. 9

10 SECTION 2: Introducing the Trusted Execution Environment Addressing the security concerns discussed in the previous section is most easily done via the Trusted Execution Environment (TEE). The TEE is a separate execution environment that runs alongside the Rich OS and provides security services to that rich environment. The TEE isolates access to its hardware and software security resources from the Rich OS and its applications. The Figure below shows the architecture of the TEE. Rich OS Application Environment Client Applications Trusted Execution Environment Trusted Application DRM Trusted Application Payment Trusted Application Corporate GlobalPlatform TEE Functional API GlobalPlatformTEE Client API Rich OS GlobalPlatformTEEInternal API Trusted Core Trusted Environment Functions TEE Kernel Hardware Platform HW Secure Resources HW Keys, Secure Storage, Trusted UI (Keypad, Screen), Crypto accelerators, NFC controller, Secure Element, etc. Figure 1 : Architecture of the TEE As this Figure illustrates, the TEE offers safe execution of authorized security software, known as Trusted Applications; it also enforces protection, confidentiality, integrity, and access rights of the resources and data belonging to those Trusted Applications. In order to guarantee the root of trust of the TEE, the TEE is authenticated and then isolated from the rest of the Rich OS during the secure boot process. Inside the TEE, each Trusted Application is independent from the others, and a Trusted Application cannot perform unauthorized access to security resources from another Trusted Application. Trusted Applications can originate from different application providers, and it is expected that the TEE standardization will enable a large ecosystem of Trusted Application providers. Trusted Applications are given controlled access to security resources and services via the TEE Internal API, which is currently being standardized by GlobalPlatform (the TEE Client API was standardized by GlobalPlatform in 2010). Such resources and services may include key injection and management, cryptography, secure storage, secure clock, Trusted UI, Trusted keyboard stroke, etc GlobalPlatform Inc. 10

11 As defined by GlobalPlatfom, a TEE will undergo a qualification process, which will include functional testing (compliance) and security evaluation testing (certification). This qualification process is being defined and will be based on the security requirements 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 and exchange data with a Trusted Application running inside a Trusted Execution Environment. The specification for the TEE Client API can be downloaded from the GlobalPlatform website. Finally, in order to complete the ecosystem, a TEE Functional API will offer Client applications a set of Rich OS-friendly APIs. These will allow access to some TEE services, such as cryptography or secure storage, with a programming model familiar to Rich OS application developers. The definition of the TEE Functional API is part of the GlobalPlatform TEE deliverables roadmap GlobalPlatform Inc. 11

12 SECTION 3: Positioning of the TEE The TEE provides a framework for security within the device, offering a layer of security between a typical Rich OS and a typical SE. At present, serious mobile security solutions rely primarily on an SE. This is required mainly to provide a secure control mechanism that is supported by most financial institutions, including banks and credit card companies. However, several use cases have less stringent security requirements and, further, cannot be executed because of the performance, interaction, and user experience limitations of an SE. In general, the level of security required should be proportional to the importance of the asset. A higher level of security should be balanced against a faster, easier, and more attractive device use experience. The following are a few examples of how to position the TEE vis-à-vis an SE: Although the SE brings a higher level of security to execute mobile financial transactions, 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 user s profile and history. For example, one study on this topic 2 has shown that most of the financial transactions people do with their mobile devices are below $10. Enterprise networking can be appropriately protected with authentication and encryption that can be provided by the TEE while offering a level of performance comparable to the Rich OS. The TEE is an ideal environment to host DRM agents that protect content or applications downloaded from an app store. By contrast, this environment would be easy to forge in a Rich OS. So, if we understand a Rich OS to be a rich environment that is vulnerable to attacks, and an SE as resilient to attacks but somewhat limited, the TEE serves as a needed compromise between Rich OS performance and SE security. 2 Mobile Financial Services: Banking & Payment Markets Juniper Research September GlobalPlatform Inc. 12

13 User Interface Ease of Development Processing Speed Rich OS Trusted Execution Environment (TEE) Secure Element (SE) Attack Resistance Access Control Physically Removable Figure 2 : Rich OS, TEE and SE Positioning Figure 2 represents the security and usability characteristics in particular environments a Rich OS, TEE, and SE. However, the capabilities indicated are not of the same strength on the whole range of a particular implementation of an environment. The diagram reflects this through the given width and height of the arrows. In very general terms, the TEE offers an execution space that provides a higher level of security than a Rich OS; though not as secure as an SE, the security offered by the TEE is sufficient for most applications. Moreover, the TEE provides a more powerful processing speed capability and greater accessible memory space than an SE (these are, in fact, quite similar to that of a Rich OS). Because the TEE supports more user interface capabilities and peripheral connections than an SE, it allows development of security applications that enable a rich user experience. In addition, since the TEE is isolated from the Rich OS environments (as a result of software partitioning), it leverages the Rich OS functionality while maintaining adequate security. In particular, the TEE is able to resist software attacks occurring in the Rich OS (e.g. OS rooting, jailbreaking, malware, etc.). By contrast, the SE supports physical robustness and high tamper resistance against side channel attacks; therefore, it is certifiable at the highest security levels (EAL4+ and above with SmartCard Protection Profile). Removable SEs can support security and data mobility (such as UICC or MicroSD) and are therefore transferable from one device to another. NFC-enabled SEs can be used in low-power or no-power modes when device electrical power is low or drained GlobalPlatform Inc. 13

14 Ultimately, this discussion makes obvious the conclusion that security is a compromise: it requires balancing the cost of the protection with the cost of the attack. 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 Rich OS 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 can serve as a complementary security countermeasure and integrating nucleus (i.e. glue technology ) for services that depend on partial identities distributed across SEs, such as Active Stickers, Secure Micro SD Cards, UICCs, and Embedded SEs. The TEE combines these into integrated solutions, which assures seamless interaction and 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 while delivering convenient, integrated solutions to the end consumer. For example, the TEE can enable Secure User Interfaces (UIs) and OTA credential provisioning to securely isolated Security Domains, as well as the different Applications stored in each one of these GlobalPlatform Inc. 14

15 SECTION 4: Detailed Use Case Implementation To better understand the TEE, it will be valuable to explore a number of use cases each with distinct needs that can be met by the TEE Corporate Use Case A primary driver of the security development in the mobile Internet is the confidentiality required for corporate use situations. When the end-user uses a mobile device to access , intranet, and corporate documents, there is a need for reliable, 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 of protection that enables secure usage of smartphones in enterprises. The TEE can be used in different ways to increase security for corporate applications: Corporate applications such as an manager or CRM application can rely on Trusted Applications, which require implementation of the sensitive functionalities, such as encrypted storage and controlled access to or customer information. VPN authentication can rely on Trusted Applications, which allow for secure VPN credential provisioning and reliable authentication cryptographic calculation. A corporate access policy rule can be implemented thanks to a TEE-based Trusted User Interface. One such implementation would require the user to enter a password prior to accessing the encrypted corporate data and connecting to the corporate network. A One-Time-Password (OTP) application can be securely implemented in the form of a Trusted Application, and thereby use the smartphone as a secure authentication token; this could happen, for example, when logging -on to the corporate network from a PC (two-factor authentication method). Furthermore, the TEE provides an execution environment with a speed of execution comparable to the Rich OS. Therefore, the security features required to support the corporate use case will not significantly impact the overall user experience Content Management Use Case Smartphones, tablets, and portable multimedia players enable users to enjoy high quality content, such as music, video, books, and games. While the user benefits from this increased smartphone capability, businesses that provide such content require content protection mechanisms to shield their businesses from illegal copying or 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) 2011 GlobalPlatform Inc. 15

16 Conditional access systems that control broadcast content reception and usage (e.g. Nagra, NDS, Irdeto, Viaccess, and OMA BCAST) These content protection systems would benefit from the TEE by relying on Trusted Applications 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. Mobile Payment Use Case A majority of market analysts are predicting large growth in the area of mobilebased financial services. Smartphones are personal and convenient platforms to perform such financial transactions. There are specific types of mobile financial services that tend to be targeted at smartphones. They include mobile banking, mobile payment, mobile money transfer, and mobile authentication (e.g. use with One-Time Password OTP technology). For the purpose of discussing the value that the TEE brings to the table, let us focus here on mobile payment. It is important to note that mobile payment covers many types of transactions that fit 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 user s money is transferred to another entity to pay for a good or a service. In a remote payment scheme on the smartphone, the most sensitive operations are user authentication and transaction validation. The second scenario, proximity payments with mobile phones, is expected to become widespread with the deployment of Near-Field Communication (NFC) technology. NFC enables transactions to be processed quickly by just bringing the phone in proximity of a reader resulting in a streamlined user experience. Because these transactions are generally offline, they require a security component in the handset that 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-based transactions, some sensitive operations are directly performed on the smartphone, such as the transaction validation when the payment amount value is above a certain threshold amount. As more financial transactions take place within a smartphone s open platform, the door is opened to an increased risk of malware that could induce the following: Retrieval of user passwords and PIN codes for user authentication and transaction validation Modification of transaction essential data, such as transaction amount Generation of transactions without user validation 2011 GlobalPlatform Inc. 16

17 The TEE is a unique environment that is capable of increasing the security and assurance level of these transactions if the transaction is conducted online or coupled with a Secure Element. Areas that the TEE is protecting include the following: User Authentication: through its Trusted User Interface feature, the TEE makes it possible to securely collect a user password or PIN code that will then be verified locally, on a remote server, or within a Secure Element. Transaction Validation: through its Trusted User Interface, the TEE makes it possible to ensure that the information displayed accurately portrays the application s request as opposed to displaying misinformation offered by a rogue application. Furthermore, it prevents transaction validation without the explicit authorization of the user (e.g. through a user PIN code). Transaction Processing: any processing that needs to reside on the handset can be isolated from any untrusted software attack by being executed in the TEE and leveraging any of the device s 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 to make sure that richer applications that may interact with the application residing in the SE can assure confidentiality and integrity with a friendly user experience, such as a user entering a PIN Service Deployment in a TEE Service Development A Trusted Application is the means for a Service Provider to deploy secure services in a smartphone that supports a TEE. The Trusted Application is executed in a secure manner in the TEE and relies on the TEE s Internal API. Examples of services available in the TEE include key management, key storage, secure storage of data, and cryptographic operations. Nevertheless, all of the operations of a given service do 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 the functionalities. A traditional smartphone application is split into two parts when using the TEE: one part will be executed in the Rich OS while the other part will use the security-centric TEE Internal APIs. The limitation of such an architecture is that the service will be developed for a given smartphone while all Trusted Applications that rely on standardized TEE Internal API will be portable on any TEE that is compliant with GlobalPlatform specifications. Standardization of the TEE Internal API is underway, and as of this writing, the status is as follows: The communication between the distributed parts of a service is based on a standardized TEE Client API, issued by GlobalPlatform in Summer A higher-level TEE Functional API is expected by end GlobalPlatform Inc. 17

18 The complete set of features available to Trusted Applications will be described in the TEE Internal API, which is under construction within GlobalPlatform and is expected to be issued in TEE compliance tests are expected to be developed by GlobalPlatform in Service Administration Today, the standard way for deploying secure services that rely on TEE technology is while the TEE is being integrated into the device. However, this model needs to be changed so that several parties can load new Trusted Applications. As part of its 2011 deliverables, GlobalPlatform plans on defining an interoperable way to administrate Trusted Applications in the TEE An Example of Service Development: Corporate Use Case A Trusted Application can support the deployment of Corporate Services. In cases where the Corporate Services rely on a VPN, credentials need to be securely stored in the memory managed by the TEE. Additionally, sensitive documents managed in the 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 Trusted Application, stored and executed in the TEE, which would be in charge of VPN channel establishment and access control to sensitive documents. Those Trusted functions, implemented in the Trusted Application, would be accessed thanks to a TEE Client API running on the Rich OS GlobalPlatform Inc. 18

19 SECTION 5: Why Standardize the TEE (proprietary vs. standard)? Standardization of the TEE is key to both avoid fragmentation of APIs and protect differentiation. 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 or adapting 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, standardization allows for multiple business partners and, because it ensures long-term stability and survivability, protects investment in a way that proprietary solutions cannot. It also defines 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 card specifications are now embedded in more than 5 billion Secure Elements. As a recognized standards body, GlobalPlatform represents the full ecosystem, including chip manufacturers, IP providers, software developers, OEMs, network operators, service providers, certification laboratories, and more. Following its OMTP and TCG standardization efforts, GlobalPlatform s Device Committee delivered the TEE Client API 1.0 specification in July The Committee is now actively working on the specification for the TEE Internal API, as well as higher-level functional APIs for the TEE Client API GlobalPlatform Inc. 19

20 SECTION 6: TEE Roadmap Due to the slow penetration rate of new technologies in the mobile market, it is critical that the various actors have a clear roadmap of the potential benefits of the TEE from features available in the short-term to capabilities envisioned for the longterm. This is especially important when speaking of hardware features and when making decisions regarding investments in this area. The TEE technology will publish its specifications in phases as identified below. Phase TEE API Deployment Dynamicity TEE Internal API Basic core APIs Secure storage Cryptography Date/counter management TEE Internal API Trusted UI Access to NFC controller Access to SE TEE Functional API mapping to various Rich OS application environments. Advanced set of TEE Internal API to support higher level services (e.g. certificate management, web protocols, ) Single issuer TEE where a TEE has a unique identity and contains one secret owned by one identified actor. The secret injection is left to implementation. Single-issuer TEE with standardized provisioning and management of issuer credentials. Multiple-issuer TEE by several actors, having some wellidentified roles and capabilities. The provisioning and management of issuers credentials are standardized. The means to add Trusted Applications in the TEE once issued is left to implementation. The means to add Trusted Applications in the TEE once issued are available to several actors. The means that adding Trusted Applications in the TEE once issued is available to several actors. Planned Release mid end 2011 mid 2012 Table 1 TEE Specifications Roadmap For each of those specifications phases, it is expected that the compliance (covering functional tests) and the certification (security compliance) will be delivered. The compliance deliverables will be published four months after the public specification availability. The certification program will conform as much as possible to this roadmap GlobalPlatform Inc. 20

21 SECTION 7: Conclusion There are today increasing security concerns resulting from increased mobile handset usage, and the TEE offers the market a solution that addresses many of these concerns without imposing an undue burden on applications. The TEE is a separate execution environment that runs alongside the Rich OS and provides security services to that rich environment. This is accomplished while protecting and isolating access to hardware and software security resources from the Rich OS and its applications. The TEE protects the assets that fall between a secure element and Rich OS. It provides robust, hardware-backed, scalable-consistent, OS-independent security. Furthermore, it offers device features and performance that cannot be delivered by a secure element. The definition of the TEE is an effort in progress and follows a roadmap for the development of standardized security features in mobile devices. Following the TEE Client API 1.0 specification delivered by GlobalPlatform s Device Committee in July 2010, the Committee is now actively working on the specification for the TEE Internal API, as well as higher-level functional APIs for the TEE Client API. It is expected that these will be completed in The result of this activity will be a standardized TEE that will not be subject to the whims of proprietary solutions. Multiple business partners across all relevant market segments will benefit from the standardization: greater long-term continuity, greater stability, and lower costs GlobalPlatform Inc. 21

22 APPENDIX A: Abbreviations Abbreviation Meaning CA CC CMLA CPRM DRM EAL HD HLOS IPsec MNO MFS NFC OEM OMTP OS OTA OTP POS SE SSL TEE TLS UI UICC VPN Conditional Access Common Criteria Content Management License Administrator Content Protection for Recordable Media Digital Rights Management Evaluation Assurance Level High-Definition High-Level Operating System Internet Protocol Security Mobile Network Operator Mobile Financial Services Near Field Communication Original Equipment Manufacturer Open Mobile Terminal Platform Operating System Over-the-Air One-Time-Password Point Of Sale Secure Element Secure Socket Layer Trusted Execution Environment Transport Layer Security User Interface Universal Integrated Circuit Card Virtual Private Network 2011 GlobalPlatform Inc. 22

23 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 of embedding 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 provides security services to that rich environment and isolates access to its hardware and software security resources from the Rich OS and its applications GlobalPlatform Inc. 23

24 APPENDIX C: Comparing Rich OS, TEE, and SE The table below summarizes security and computational facilities offered by typical implementations of the three environments, in order to identify their fundamental differences. Application download controlled by Application code Isolation User choice. Rich OS TEE SE Typically unvalidated and uncertified. Limited by Rich OS capabilities some Rich OS may provide a sandbox model (e.g. Java VM) or support virtualization Authorization process. Typically validated and certified before authorization, and in authorization checked on loading. The TEE is separate from the Rich OS the depth isolation relies on the strength of the TEE implementation Authorization process. Typically validated and certified before authorization, and in authorization checked on loading. Isolated physically runs a separate OS (e.g. JavaCard, STIP, etc.) Certification Uncertified Certified Strongly certified OS Kernel, driver and library code Confidential and integrity of access to user interface devices (Keyboard, screen, audio I/O) Created for flexibility and speed Created for security and speed Created for security Rich API set Limited API set Very limited API set Typically large RAM size Within the limits of the Rich OS capability Typically medium RAM size Confidentiality- and integrity-bounded by the TEE (the TEE can have access to user interfaces which are isolated from the Rich OS) CPU speed GHz range Hundreds MHz to GHz range Cores 1->4 1 master 1 RAM size 16MB->1GB+ 64KB to many MB secure RAM speed Mhz -> 800Mhz FLASH size 1GB-> 32GB + (inc SD cards etc) Mhz -> 800Mhz shared with Rich OS each Trusted Typically small RAM size Only indirectly, and so bounded by delegation from an external enabler such as Rich OS or TEE. Few to 20 MHz range A few 10's of KB 32 5Mhz (limited by power) 64KB-> 1 MB 2011 GlobalPlatform Inc. 24

25 Application may have its own secure storage Data Transfers with Rich OS Very fast Very fast Slow Protection against unauthorized software attack, including software making "illegal" use of hardware on the device Confidentiality internally protected by non-certified OS Confidentiality Protected vs. Rich OS and device hardware. Internally protected by certified OS Confidentiality Protected vs. external software and device hardware. Internally protected by certified OS Limited integrity protection during boot (Typically Kernel only) Integrity Protected vs. Rich OS and device hardware. Internally protected by certified OS Integrity Protected vs. external software and device hardware. Internally protected by certified OS (and other mechanisms?) Protection against external hardware attack no protections against attacks limited anti-rollback protection Protection depending on TEE implementation mechanisms and hardware features of hosting platform Strong protection for SE but not for hosting device Protection guarding the device, i.e. preventing the device from being unlocked or flashed with unauthorized software Optional secure boot TEE mandates secure boot Often trivially removable from the device by user or attacker. Any linkage with the device can only be as strong as the security guarding the weakest part of that link (typically on the device and typically the weak point being the Rich OS or TEE) Table 2 Comparison between Rich OS, TEE and SE 2011 GlobalPlatform Inc. 25

26 APPENDIX D: Table of Figures Figure 1 : Architecture of the TEE Figure 2 : Rich OS, TEE and SE Positioning Figure 3 : Security vs. investment APPENDIX E: Table of Tables Table 1 TEE Specifications Roadmap Table 2 Comparison between Rich OS, TEE and SE GlobalPlatform Inc. 26