1540-7993/14/$31.00 © 2014 IEEE Copublished by the IEEE Computer and Reliability Societies July/August 2014 29

MOBILE SECURITY

Hardware-based trusted execution environments (TEEs) have been available in mobile devices for more than a decade, but their use has been limited. Th e On-board Credential system safely opens up TEEs to application developers so that they can implement and deploy mobile services with hardware-assisted security.

A trusted execution environment (TEE) is a secure, integrity-protected environment, consisting of

processing, memory, and storage capabilities. It’s iso-lated from the “normal” processing environment, some-times called the rich execution environment (REE), where the device OS and applications run. Using TEEs, devel-opers can design REE applications and services that remain secure even in the face of OS compromise— sensitive operations are isolated from the REE, and sen-sitive data, like cryptographic keys, never leave the TEE.

In our daily lives, we encounter more and more ser-vices that use dedicated hardware tokens to improve security, for example, one-time code tokens for two-factor authentication, wireless tokens for opening doors in buildings or cars, and tickets for public transport. Mobile devices equipped with TEEs can replace these tokens, thereby improving usability and reducing the cost for service providers.

Chances are that your mobile device sports a hard-ware-based TEE. Chances are, too, that you haven’t come across many applications that use TEE function-ality. Despite TEE’s large-scale deployment, there’s been no widely available means for application devel-opers to benefi t from its functionality as mobile device manufacturers have restricted TEE access to their inter-nal use cases. Fortunately, with emerging standardiza-tion, this situation is about to change. In this article, we discuss TEE’s security features and describe On-board

Credentials (ObC), a system that safely opens up access to TEE functionality.

Mobile Platform SecuritySecurity in the mobile world has had a very diff erent trajectory from that of personal computers.1 Various stakeholders have strict security requirements, some of which date back to the beginning of the explosion of personal mobile communications two decades ago. Th ese include

■ standardization requirements that the device identi-fi er, also called the International Mobile Equipment Identifi er (IMEI) resists “manipulation and change, by any means (e.g., physical, electrical and soft ware)”;2

■ regulatory requirements such as ensuring secure storage for radio frequency parameters calibrated during manufacture;

■ business requirements such as subsidy lock—ensuring that subsidized mobile phones given to a subscriber as part of a contract with a mobile operator can’t be used by a diff erent mobile operator subscriber—and secure implementations of digital rights management schemes; and

■ users’ reliability requirements, for instance, no blue screen of death.

To meet these requirements, mobile device man-

Th e Untapped Potential of Trusted Execution Environments on Mobile Devices

Jan-Erik Ekberg | TrustonicKari Kostiainen | ETH ZurichN. Asokan | Aalto University and University of Helsinki

j4kos.indd 29 7/9/2014 11:25:04 AM

30 IEEE Security & Privacy July/August 2014

MOBILE SECURITY

ufacturers, chip vendors, and platform providers designed and deployed hardware and platform secu-rity mechanisms for mobile platforms early on, and hardware-based TEEs were essential building blocks. The first mobile phones with hardware-based TEEs appeared almost a decade ago in Nokia phones using Texas Instruments processors.3

One way to realize a TEE is by implementing a secure processor mode, such as ARM TrustZone, which is deployed in the majority of smartphones and tablets.4 Today, almost every smartphone and tablet contains a TEE like ARM TrustZone as well as software platform security mechanisms.1

What Makes a TEE?A typical TEE provides platform boot integrity, secure storage, device identification, isolated execution, and device authentication capabilities. Figure 1 illustrates these security mechanisms.

Security MechanismsMobile devices have a hardware trusted computing base (TCB) consisting of hardware and firmware compo-nents that need to be trusted unconditionally. Mobile platform boot integrity can be verified using either secure or authenticated boot.

In secure boot, a device’s start-up process is stopped if a boot loader, or another boot process component ver-ified by it, detects any changes to the launched platform components. A common secure boot implementation uses code signing and, during manufacturing, stores the beginning of the boot sequence in the TCB (for exam-ple, on the mobile device processor chip’s ROM) to make it immutable; the processor must unconditionally start executing from this memory location. Boot code certificates that contain hashes of booted code and that are signed with respect to a device’s trust root, such as the device manufacturer’s immutable public key, can be used to verify the booted components’ integrity.

The TCB must be enhanced with cryptographic mechanisms that validate the signature of the sys-tem component launched first (for example, the boot loader), which can in turn verify the next component launched (for example, the OS kernel), and so on. If any of these validation steps fail, the boot process aborts. We can ensure the cryptographic mechanisms’ integrity by storing the needed algorithms on ROM. Secure boot with code signing doesn’t necessarily mean that only a single platform version can start—there might be sev-eral certified alternatives.

In authenticated boot, the launched platform com-ponents are measured but aren’t verified with respect

Figure 1. An overview of common hardware security mechanisms in mobile devices. The trusted execution environment (TEE) consists of secure storage and isolated execution mechanisms. Rich execution environment (REE) applications access these security services through the TEE API.

TEE code certificate

TEE code hash

External trust root

Device key

Identity certificate

Base identity

Base identity

Assigned identity

Data

Executablecode

Boot code certificate

Boot code hash

Trust root

Cryptographic mechanisms

Mobile device hardware trustedcomputing base

Device identification Boot integrity Device authentication

TEE (securestorage and

isolated execution)

Volatile memory

Memoryelement

Boot sequence

Launchboot code

TEE API forREE applications

TEE code Nonvolitilememory

Device certificate

Identity

Public device key

Certificate

j4kos.indd 30 7/9/2014 11:25:04 AM

www.computer.org/security 31

to certified reference values. During the boot, integrity- protected volatile memory stores measurements of launched software components and their configuration data. The boot loader measures the first component launched, which in turn measures the next one, and so on. These measurements represent the platform compo-nents’ state after the boot and can be used to control the booted system software’s access to hardware-protected device resources or for remote attestation.

Implementing secure storage requires at least one confidential, device-specific key that can be accessed only by authorized code in the TCB. Such a device key might be initialized during manufacturing and stored on the processor chip’s memory. In addition, secure storage requires trusted implementations of necessary cryptographic mechanisms, for example, authenticated encryption algorithms. Data rollback protection—the ability to detect old versions of protected objects in local persistent storage—requires writable nonvolatile memory (for example, a monotonic counter) that per-sists its state across device boots.

The secure storage mechanism can expose the func-tionality of a set of predefined cryptographic algorithms to the REE, guaranteeing that the cryptographic keys never leave the hardware TCB. Although predefined common cryptographic operations are sufficient for many services, certain REE applications require execu-tion of application-specific algorithms in isolation from the mobile OS and the rest of the REE. Proprietary one-time password algorithms for online banking are one such example.

To extend the secure storage mechanism for iso-lated execution of arbitrary code, a device’s hardware configuration must provide an interface (the TEE API) through which the executable code (TEE code) can be loaded for execution in protected volatile memory. A TEE code certificate that contains a hash of the TEE code and is signed with respect to the device’s trust root can authorize code execution in the TEE and authorize the TEE code to access the device key. The TCB can control the TEE code’s access to the device key on the basis of the platform state that the authenticated boot process measured and saved on the volatile, integrity-protected memory.

The hardware TCB instance typically has a unique immutable base identity, for instance, a serial number from a managed namespace or a statistically unique iden-tifier initialized randomly at manufacture. Combining a trust root and the base identity allows flexible device identification; an identity certificate signed with respect to the trust root can securely bind an assigned identity to the base identity. IMEI and link-layer identities, such as Bluetooth and Wi-Fi addresses, are examples of device identities. A device certificate signed by the manufac-

turer can bind any assigned identity to the public part of a TEE-protected keypair. Signatures using such a key provide device authentication, while signed statements over volatile memory containing an authenticated boot’s measurements enable device state reporting and verifica-tion, or remote attestation. The hardware TCB might also contain a hardware-based source of randomness.

Hardware Security ArchitecturesThe ARM TrustZone and Texas Instruments M-Shield hardware architectures realize these security mecha-nisms. In a common mobile device hardware configu-ration, the device’s main processor, small amounts of ROM and RAM, some peripheral and interrupt control-lers, and debug and trace ports are integrated in a single chip—a system on chip. These on-chip components are connected with an on-chip bus. The rest of the mobile device’s components, such as the system’s main runtime memory, flash memory elements, display, and antennas are typically implemented as off-chip components. The off-chip hardware elements are connected to the system on chip with an off-chip device bus. Figure 2 illustrates such a hardware configuration.

The processor can operate in either normal world or secure world mode. The processor boots into the secure world, which sets up the necessary environment before switching to the normal world. Execution can switch back to the secure world when a special command exe-cutes in the normal world. The secure world is intended for the TEE, whereas the normal world runs the REE.

Hardware configuration designers define the com-ponents accessible in each mode. In a typical configu-ration, access to on-chip elements is restricted to the

Figure 2. Example hardware configuration for a TrustZone-enabled mobile device. The access control between hardware elements is implemented using a status flag that determines the processor mode—secure world or normal world. The system-on-chip (SoC) communication bus carries the status flag, and dedicated hardware enforces access control (teal boxes).

On-chip memory

Access control hardware

Access control hardware

Modem Main CPUBoot ROM

Memory controller

Peripherals

Access control hardware

Memory controllerSoC perimeter

SoC internal bus (carries status flag)

O�-chip memory

j4kos.indd 31 7/9/2014 11:25:05 AM

32 IEEE Security & Privacy July/August 2014

MOBILE SECURITY

secure world, whereas the device’s main memory and user I/O interfaces are accessible in both modes. A sta-tus flag indicates the current world to the on-chip and off-chip buses; access control hardware that uses the status flag in access control enforcement is added to the mobile device configuration (see Figure 2). The switch from the normal world to the secure world is possible only via a controlled transition from the less privileged normal world mode to the more privileged secure world mode. The on-chip ROM is populated during device manufacturing to contain the base identity, device key, trust root, and cryptographic algorithms. The on-chip RAM is used for isolated execution at runtime.

Figure 3 illustrates TrustZone’s software archi-tecture. The REE’s mobile OS accesses TEE services through a TrustZone library and a hardware driver. In the TEE, trusted applications execute on top of a mini-mal runtime environment, called the trusted OS, which provides a TEE internal API that trusted applications can use for communication with REE applications, and to access cryptographic operations and secure storage functionality. The trusted OS can enforce access control on trusted applications that attempt to access the device key. The TrustZone architecture doesn’t define how REE applications access TrustZone services.

The hardware-assisted secure boot can verify boot-time trustworthiness of REE-side system software components, including the TrustZone library. Even if adversaries compromise these software components at runtime, they can’t access TEE-protected secrets;

at most, they could cause denial of service for TEE- provided security services.

Other Types of TEEsMost mobile devices realize the TEE using processor security features such as isolated memories and a secure processing mode, as we discussed earlier. Other ways to realize a TEE include virtualization, dynamic roots of trust, and embedded secure elements.

Virtualization. A securely booted virtual machine moni-tor (VMM) allows many virtualized “guest” OSs to run on the device concurrently. To isolate the guests, the VMM runs at a higher protection domain than the OSs and masters the memory management unit on the OSs’ behalf. Approaches like Overshadow can extend simi-lar protection to individual applications in a potentially harmful guest OS.5 Solutions based on virtualization typically rely on software to guarantee integrity and iso-lation but are otherwise architecturally similar to hard-ware-based TEEs.

Dynamic roots of trust. In x86-based mobile devices such as laptops, TEEs can be realized using the Trusted Computing Group’s (TCG; www.trustedcomputing group.org) Dynamic Roots of Trust Measurement (DRTM), as Flicker demonstrates.6 In concert with a trusted platform module (TPM), a DRTM-enabled processor can launch and run small pieces of trusted software isolated from the OS. Such TEEs are isolated by hardware but active only for short time periods.

Embedded secure elements. Some commercial mobile phone models intended for payment applications with high security requirements include embedded smart cards on their motherboards. These TEEs often use JavaCard as their programming environment. The cards provide full hardware isolation. However, embedded smart cards rarely provide open interfaces and support for more general third-party programming.

TEE Access for DevelopersAlthough TrustZone and M-Shield architectures have been deployed to many mobile devices for almost a decade, third-party developers’ use of hardware secu-rity mechanisms has been limited. Traditionally, mobile device manufacturers have leveraged TEE capabilities only for internal use cases, such as subsidy lock protec-tion and secure boot.

Some mobile platforms provide hardware-assisted security APIs. The Java ME application framework, widely used in feature phones, defines JSR 177 API, which offers a low-level communication interface to a smart card–like secure element as well as a higher-level

Figure 3. Software architecture for TrustZone-enabled mobile devices. Trusted applications execute in the TEE, which is isolated from the REE running the mobile OS and applications. REE applications access TEE security services through a device driver.

Mobile device

REE

Application TEE codeApplication

TEE

Mobile OS

Driver

Mobile device hardware with TrustZone support

Trustedapplication

Trustedapplication

TEE internal API + crypto lib

Trusted OSTEE API: TrustZone library

j4kos.indd 32 7/9/2014 11:25:06 AM

www.computer.org/security 33

cryptographic API.7 A mobile phone secure element, such as a SIM card, might provide the implementation of JSR 177. Recent versions of the Android platform expose hardware-assisted cryptographic APIs8 using a standardized PKCS (Public-Key Cryptography Stan-dards) #11 interface9; in iOS, a proprietary key chain API provides similar functionality.10

The high-level hardware security APIs were mod-eled on hardware security module, cryptographic token, and smart card usage paradigms. They allow the creation of hardware-protected keys and common cryptographic operations, such as encryption and sig-natures, on them. To use mobile TEEs’ programma-bility, a different kind of API abstraction is needed. The API should address provisioning of trusted appli-cations and secrets to the device, authorize trusted applications to access provisioned secrets and device keys, and control which REE applications can execute trusted applications. None of the currently standard-ized or de facto proprietary hardware security APIs provide such functionality. This was our motivation to create the On-board Credentials system.

On-board CredentialsWe developed ObC, a TEE architecture, at the Nokia Research Center; Figure 4 illustrates its architecture

(for more details, see “On-board Credentials with Open Provisioning”11). ObC is now available on Nokia Win-dows Phone 8 and Symbian phones.

The ObC architecture achieves the necessary isolation properties for trusted applications using the ObC interpreter, a small virtual machine (VM). Although this interpreter isn’t a complete OS, it provides the necessary runtime environment to execute trusted applications originating from untrusted developers. The VM-based design was driven by mobile device constraints, such as the scarcity of isolated on-chip memory. Future-generation mobile devices will likely be less constrained in terms of TEE resources and might support secure virtual memory. Thus, adopting TEE platforms that resemble full-fledged embedded OSs might become practical.

Developers can create ObC trusted applications using either Basic or a bytecode assembler. An ObC VM is implemented as a set of interacting TrustZone code components. Depending on the underlying TEE hardware and software architecture, these components might permanently reside in the TEE or be loaded on demand. In some environments, they constitute the device’s only available “trusted OS”; in others, the ObC interpreter components are themselves trusted applica-tions. In the latter case, the ObC interpreter is used to

Figure 4. On-board Credentials (ObC) architecture. Teal boxes illustrate ObC components. The ObC interpreter executes trusted applications in the TEE. The ObC scheduler maintains trusted applications’ persistent storage and handles execution scheduling. REE applications access ObC services through the ObC API.

Mobile device

REE

Application

ObC API TEE codeProvisioning, execution, sealing

ObC scheduler

Application

TEE

Mobile device hardware with TrustZone support

Trusted applicationpersistent store

Trusted applicationdynamic state

ObC interpreter

I/O dataInterpreted codeInterpreter state

Loaded trustedapplication

Driver

Mobile OS

j4kos.indd 33 7/9/2014 11:25:07 AM

34 IEEE Security & Privacy July/August 2014

MOBILE SECURITY

augment the native trusted OS provisioning capability or isolation guarantees rather than to provide imple-mentation minimality. In the rest of this article, we use the term trusted application to denote bytecode running on the ObC VM.

The ObC scheduler that runs in the REE handles the scheduling of the ObC TrustZone components and manages the currently interpreted trusted application’s encrypted state. REE applications access the ObC sys-tem through the ObC API (see Figure 4).

SchedulingTo execute a trusted application, the scheduler loads its locally encrypted representation, possible inputs, and stored data sealed by previous invocations of the same application instance. The ObC interpreter then executes the trusted application bytecode. Some exe-cution events, such as a bytecode requesting an input parameter or invoking a library function, cause the interpreter to collect its runtime state, including the VM program counter, local variables, and stack; encrypt it; and return the encrypted state to the REE for sched-uling. The interpreter also performs on-demand code page loading of the bytecode program, which is another cause for the interpreter to save its state and yield execu-tion control to the REE.

Back at the REE, the ObC scheduler reinvokes the same or a different trusted application, using the same or a different TrustZone component, and attaches pos-sible temporarily stored data or the interpreter state. Bytecode execution continues in this manner until the trusted application completes.

This scheduling mechanism causes significant execu-tion overhead owing to the numerous context switches between the TEE and REE and corresponding encryp-tion and decryption. However, because the ObC sys-tem runs on the mobile device’s main processor, overall performance is comparable to solutions without such scheduling on slower security chips, such as smart cards.

ProvisioningThe ObC platform supports an open provisioning model in which any developer can, with the device user’s permission, deploy trusted applications without ask-ing permission from a centralized authority, such as the device manufacturer or OS provider. A device-specific and manufacturer-certified public key provides the basis for remote provisioning of trusted applications, and the secrets on which they operate, to devices already in the field. In addition, service providers need to handle user authentication for provisioning. The certified device’s public key is used to transport a provisioner- specific secret key that defines a security domain for trusted applications and secrets that are later provisioned to that

domain. Isolation between security domains inside the TEE is achieved by interleaving execution of different security domains in time and implementing local stor-age with distinct encryption keys for each domain.

Application DevelopmentTo develop a complete service, a service provider needs to deploy two components to a mobile device: a trusted application that handles the service-specific security logic in the TEE, and an REE application that triggers trusted application execution and potentially provides a user interface.

For trusted application developers, the ObC inter-preter provides an API including cryptographic func-tions, standard string and array manipulation, sealing, and I/O. Figure 5 shows an excerpt from a trusted application written in ObC Basic for MirrorLink (www. mirrorlink.com) attestation.

For REE application developers, the ObC API includes functions for provisioning new trusted appli-cations and secrets on which they operate; execut-ing previously provisioned trusted applications with the needed input parameters; and local encryption, or sealing, of REE application data without a custom trusted application.

Example ApplicationsHere, we describe two applications developed and deployed using the ObC system.

Public transport ticketing. We designed a public trans-port ticketing application with near-field communica-tion (NFC)-enabled mobile phones, creating trusted applications, and matching REE applications, for gated and nongated ticketing scenarios. Our gated environ-ment uses a straightforward challenge–response proto-col for identity verification during ticket verification. In nongated transport, the tickets aren’t verified at the sta-tion gates; instead, travelers are required to report travel start and endpoints (by touching designated NFC-enabled signposts in stations) on their own accord but are subject to random ticket inspections. In such a model, some opportunities for fraud emerge. For exam-ple, travelers could stop their phone from reporting evi-dence of trips during which they were never inspected.

To address this threat, we developed an ObC trusted application that implements an authenticated counter value that’s bound to identity verification signatures. In ticket inspection and evidence reporting, signatures must be accounted for in back-end logs, and we bind the use of the counter (device-local enforcement) to an operational window that the service back end controls remotely to match the target public transport system’s risk model and usability considerations.12

j4kos.indd 34 7/9/2014 11:25:07 AM

www.computer.org/security 35

A traditional cryptographic API, such as PKCS #11 or TPM interface, wouldn’t give the necessary flexibility for the nongated scenario. With a programmable TEE environment, we implemented such an augmented cryptographic primitive with little effort and deployed it on devices already in the field. The nongated ticket-ing application has been used in a trial of more than 100 users in New York’s transit system.

MirrorLink attestation. Our second application is MirrorLink, a system that enables use of smart-

phone-provided content and services in automotive environments. To comply with driver distraction regulations, the car’s head unit—the entertainment and navigation system’s main console—must verify the trustworthiness of the data it receives from the mobile device. We designed an attestation protocol that builds on standardized functionality and data structures defined in TCG’s Mobile Trusted Module (MTM) specification. A set of platform configuration registers aggregate measurements that represent the mobile device’s software configuration. A signature

Figure 5. A fragment of a MirrorLink attestation trusted application illustrating the trusted platform module (TPM) platform configuration register extending and signing (quote operation).

rem ––– Subroutines written in assembler or BASIC can be linked in#include “sha1_standard.evoh”#include “io_codes .evoh”#include “program_io.evoh”...

rem ––– Extend operation rem –––––––––––––––––––––––––––––– if mode == MODE EXTEND read_array(IO_SEALED_RW, 2, pcr_10) rem ––– Read earlier produced sealed input data read_array(IO_PLAIN_RW, 3, value) rem ––– Read plaintext input data append_array(pcr_10, value) rem ––– Concatenate arrays sha1(digest, pcr_10) rem ––– PCRval’ = H(PCRval |New)

write_array(IO_PLAIN RW, 1, digest) rem ––– Write plaintext output write_array(IO_SEALED RW, 2, digest) rem ––– Write encrypted data for storage and future use end

rem ––– Quote operation rem –––––––––––––––––––––––––––––– if mode == MODE_QUOTE read_array(IO_SEALED_RW, 2, pcr_10) read_array(IO_PLAIN_RW, 3, ext_nonce)

rem ––– Create TPM_PCR_COMPOSITE(the default type is uint16) pcr_composite[0] = 0x0002 rem ––– sizeOfSelect=2 pcr_composite[1] = 0x0004 rem ––– PCR 10 selected(00 04) pcr_composite[2] = 0x0000 rem ––– PCR selection size 20(uint32) pcr_composite[3] = 0x0014 append_array(pcr_composite, pcr_10) sha1(composite_hash, pcr_composite)

rem ––– Create TPM_QUOTE_INFO quote_info[0] = 0x0101 rem ––– version(major and minor) quote_info[1] = 0x0000 rem ––– version(revMajor and revMinor) quote_info[2] = 0x5155 rem ––– Fixed(‘Q’ and ‘U’) quote_info[3] = 0x4F54 rem ––– Fixed(‘O’ and ‘T’) append_array(quote_info, composite_hash) append_array(quote_info, ext_nonce) write_array(IO_PLAIN_RW, 1, pcr_composite)

rem ––– Hash_QUOTE_INFO for MirrorLink PA signing sha1(quote_hash, quote_info) write_array(IO_PLAIN_RW, 2, quote_hash) ...

j4kos.indd 35 7/9/2014 11:25:07 AM

36 IEEE Security & Privacy July/August 2014

MOBILE SECURITY

using a manufacturer-certified key over the content of such registers provides the head unit assurance of the mobile device software’s trustworthiness. Content attestation is built on top of device and software attes-tation.13 We implemented the relevant subset of the MTM specification as a trusted application; Figure 5 shows a fragment of this implementation.

This example illustrates a different use of program-mable TEEs. Many legacy security standards, ranging from one-time token algorithms to APIs like MTM, might originally have been intended for implemen-tation with dedicated hardware tokens or resources. In devices with programmable TEEs, it’s possible to easily deploy these interfaces to already shipping cus-tomer devices if the TEE security properties satisfy the compliance requirements of the standard being implemented. For example, the Nokia ObC imple-mentation of the MirrorLink attestation has been security audited for approval by the Car Connectivity Consortium. Evaluation with respect to more generic auditing systems, such as Common Criteria, is left for future research.

Emerging StandardizationTo date, no completed standard interface defines how REE applications access a TEE’s security services for trusted application provisioning and use. The ARM TrustZone architecture can be considered a de facto starting point for mobile devices’ hardware architec-ture. The National Institute of Standards and Technol-ogy (NIST) recently made public a draft guideline for hardware-rooted security in mobile devices.14 NIST identifies secure storage, code integrity, reporting and provisioning, policy enforcement, and OS component measurement as security services that should be rooted in device hardware. Using these services, we can con-struct TEE isolation properties, application-protected storage, and overall integrity guarantees.

The Global Platform Consortium (www.global platform.org) is in the process of producing a full set of TEE interface standards (www.globalplatform.org/specificationsdevice.asp), including trusted application provisioning and use, API interfaces in the TEE, and I/O specification for trusted application communica-tion with external interfaces, such as trustworthy user interfaces. An OS driver interface (the TEE client API) allows REE applications and OSs to activate and run trusted applications, and a trusted application system interface (the TEE internal API) provides commonly available programming interfaces such as memory allocation primitives and cryptographic primitives for trusted applications. Thus far, Global Platform hasn’t published information on how applications and data are provisioned to the TEE.

TCG TPMs define security interfaces for nonvola-tile storage, key generation and use, and sealing. The recently published TPM 2.0 specification adds a fine-grained policy authorization model for object access.15 The TPM is typically implemented as a discrete chip, but in a mobile context, a trusted application imple-mentation deployment is more likely. TPM interfaces don’t specify installation of trusted applications into the TEE. A recently published use case document indicates that TPM Mobile—TCG’s mobile working group—will provide standardization support for OS application interfaces as well as trusted application use and possibly provisioning.16 These specifications complement the Global Platform standards.

OutlookRecent standardization efforts by Global Platform and TCG are accompanied by the industry’s increased inter-est in making standardized TEE functionality widely available. However, no standardized API provides the ObC system’s TEE functionality, including open, trusted application provisioning and REE application execution. A recent Global Platform white paper sug-gested moving away from the issuer-centric provision-ing model to a more open consumer-centric model.17 The concrete provisioning specification is not yet pub-lic; therefore, it’s too early to say how open it will be.

In addition, several important considerations will likely be missing from the picture. In many emerging mobile platforms, third-party application develop-ment is based on Web programming techniques. How can Web applications access TEE services? Mobile devices are equipped with several security-critical interfaces, including SIM cards, NFC payment, and user interfaces. Can future trusted applications control and use such interfaces? If trusted applications are dis-tributed from traditional REE application stores, what is the security model for authorizing trusted appli-cations for execution on the TEE of the destination device, and how is associated confidential data distrib-uted to the device?

Provisioning confidential data implies encryption with a device-specific key, which transforms a tradi-tional application publishing and downloading pro-cess into an interactive provisioning protocol. How are secrets collected and amassed in a trusted applica-tion migrated to a new device? How are backups, fac-tory resets, and device service issues handled? Can centralized trusted authorities, such as trusted service managers, assist users in such credential life-cycle man-agement operations?18 If a device has many parallel per-sonalities, such as in bring-your-own-device concepts, what is the authorization model for trusted applications in the respective usage modes?

j4kos.indd 36 7/9/2014 11:25:07 AM

www.computer.org/security 37

A s with any new domain, only when the first sig-nificant stakes are set do we see the full range of

issues ahead. Mobile device TEEs are now at this criti-cal juncture. Although some form of developer access to TEEs can be expected in the short term, we must address many open issues before TEE use becomes widespread. When that happens, developers’ ingenu-ity and creativity will lead to novel ways to use TEEs to improve applications. In the same way, we can expect attackers to find creative ways of exploiting TEE func-tionality to strengthen their attacks. These efforts are already under way!19

References1. K. Kostiainen et al., “Old, New, Borrowed, Blue—

A Perspective on the Evolution of Mobile Platform Security Architectures,” Proc. 1st ACM Conf. Data and Application Security and Privacy (CODASPY), 2011, pp. 13–24.

2. “3GPP TS 42.009 Security Aspects,” 3GPP, Mar. 2001; www.3gpp.org/ftp/Specs/html-info/42009.htm.

3. J. Srage and J. Azema, M-Shield Mobile Security Technol-ogy, white paper, Texas Instruments, 2005; http://focus.ti.com/pdfs/wtbu/ti_mshield_whitepaper.pdf.

4. “Building a Secure System Using TrustZone Technology,” ARM Security Technology, Apr. 2009; http://infocenter. arm.com/help/index.jsp?topic=/com.arm.doc.prd29 -genc-009492c/index.html.

5. X. Chen et al., “Overshadow: A Virtualization-Based Approach to Retrofitting Protection in Commodity Operating Systems,” ACM SIGPLAN Notices, vol. 43, no. 3, 2008, pp. 2–13.

6. J.M. McCune et al., “Flicker: An Execution Infrastructure for TCB Minimization,” ACM SIGOPS Operating Systems Rev., vol. 42, 2008, pp. 315–328.

7. “JSR 177: Security and Trust Services API for J2ME,” Oracle, 2007; http://jcp.org/en/jsr/detail?id=177.

8. N. Elenkov, “Jelly Bean Hardware-Backed Credential Storage,” 2012; http://nelenkov.blogspot.ch/2012/07/jelly-bean-hardware-backed-credential.html.

9. “PKCS # 11 v2.20: Cryptographic Token Interface Stan-dard,” RSA, 2004; ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf.

10. “iOS Security,” Apple, Oct. 2012; http://images.apple.com/iphone/business/docs/iOS_ Security_Oct12.pdf.

11. K. Kostiainen et al., “On-board Credentials with Open Provisioning,” Proc. ACM Symp. Information, Computer and Communications Security (ASIACCS), 2009, pp. 104–115.

12. J.-E. Ekberg and S. Tamrakar, “Mass Transit Ticketing with NFC Mobile Phones,” Proc. Int’l Conf. Trusted Sys-tems (TRUST), 2012, pp. 48–65.

13. K. Kostiainen, N. Asokan, and J.-E. Ekberg, “Practical Property-Based Attestation on Mobile Devices,” Proc. Int’l

Conf. Trust and Trustworthy Computing (TRUST), 2011, pp. 78–92.

14. L. Chen, J. Franklin, and A. Regenscheid, Guidelines on Hardware-Rooted Security in Mobile Devices (Draft), tech. report NIST SP 800-164, Nat’l Inst. Standards Tech-nology, Oct. 2012; http://csrc.nist.gov/publications/drafts/800-164/sp800_164_draft.pdf.

15. “TPM 2.0 Library Specification,” parts 1–4, level 00, rev. 00.96, Trusted Computing Group, Mar. 2013; www.trustedcomputinggroup.org/resources/tpm_library _specification.

16. “Mobile Trusted Module 2.0 Use Cases,” Trusted Comput-ing Group, Mar. 2011; https://www.trustedcomputing group.org/developers/mobile.

17. “A New Model: The Consumer-Centric Model and How It Applies to the Mobile Ecosystem,” Global Plat-form, Mar. 2012; www.globalplatform.org/documents/ Consumer_Centric_Model_White_PaperMar2012.pdf.

18. C. Cox, Trusted Service Manager: The Key to Accelerat-ing Mobile Commerce, white paper, First Data, 2009; www.firstdata.com/downloads/thought-leadership/fd _mobiletsm_whitepaper.pdf.

19. T. Roth, “Next Generation Mobile Rootkits,” BlackHat Europe, 2013; http://leveldown.de/bh_eu_2013.pdf.

Jan-Erik Ekberg is the director of Advanced Develop-ment at Trustonic. His research interests include plat-form security and TEEs; securing network protocols and telecom systems; and short-range communica-tion technologies such as NFC, BT-LE, and WLAN. Ekberg received a doctorate in computer science from Aalto University. Contact him at jan-erik.ekberg@trustonic.com.

Kari Kostiainen is a postdoctoral researcher at ETH Zurich’s System Security Group. His research inter-ests include mobile device security and privacy issues, especially mobile platform security and trusted com-puting. Kostiainen received a doctorate in computer science from Aalto University. Contact him at kari.kostiainen@inf.ethz.ch.

N. Asokan is a computer science and engineering pro-fessor at Aalto University and a computer science professor at the University of Helsinki. His research interests include applying cryptographic techniques to design secure protocols for distributed systems and security for mobile devices and users. Asokan received a doctorate in computer science from the University of Waterloo. Contact him at asokan@acm.org.

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

j4kos.indd 37 7/9/2014 11:25:08 AM