GlobalPlatform TEE

The GlobalPlatform (GP) TEE is a series of specifications for trusted execution environments, including TEE networking (GP TEE Sockets API); system archi-tecture (GP System Archiarchi-tecture API); the Internal API for TEE applications, e.g.

for cryptographic operations; debugging APIs; the Client API, for communica-tion with applicacommunica-tions in the untrusted world; and interoperability with secure elements [40], [41], [76]–[78], [105], [106]. The GP TEE divides execution into two distinct ‘worlds’: the untrusted world, comprising a standard OS, such as Windows or Linux, and the trusted world containing a TEE OS and one or more Trusted Applications (TAs).

TAs interact with the TEE OS using the GP Internal API, while untrusted client applications in the REE communicate with the TEE using the GP Client API, which transmits messages to the TEE kernel over a hardware-assisted secure monitor. The kernel, in turn, routes the messages to the target TA. The TEE kernel and TAs are considered trusted; it follows that any errors in the TA code, e.g. the API function definitions it exposes to client applications, or the TEE kernel could potentially compromise the TEE. The high-level architecture of the GP TEE is shown in Figure2.14.

Hardware-wise, a GP TEE should have access to a secure clock, volatile and non-volatile memory, cryptographic accelerators and peripherals if applicable;

the GP TEE should be able to utilise access resources without trusting the REE.

The GlobalPlatform Internal API contains many of the primary abstractions

FIGURE2.14: GlobalPlatform TEE system architecture overview.

described in previous sections, including sealing – similar to TPMs and Intel SGX – in which TAs can seal secrets to a TEE-specific key, and a host of general-purpose cryptographic primitives, such as AES, RSA, and elliptic curve cryptography.

Notably, the GP TEE does not specify protocols for performing remote attestation.

It is important to note that the GP TEE is only a series of interface specifica-tions; it does not contain details, for example, regarding the implementation of the REE and TEE partitioning. Generally speaking, ARM TrustZone (Section2.4.4) is the predominant technology for instantiating a GP TEE on mobile and embedded systems. GlobalPlatform-compliant TEEs include OP-TEE¹⁸, an open-source TEE developed by Linaro, and commercial closed-source solutions like Qualcomm’s QSEE¹⁹and Trustonic’s Kinibi²⁰– all of which utilise TrustZone in practice.

The management of the GlobalPlatform TEE is defined in the TEE Man-agement Framework [107] (TMF) specifications. The GP TEE utilises Security Domains (SDs) as the abstraction with which to manage TAs between multiple provisioning authorities. SDs are abstract isolated regions that manage a set of descendent TAs, which have no administrative capability themselves, using the GP Client API. Initially, a root SD (rSD) is provisioned by a trusted master author-ity, e.g. OEM, which is used to install and manage descendent SDs in a tree-based structure; these SDs may then install subsequent TAs themselves. It is possible for a TEE to contain multiple rSDs – belonging to the OEM, mobile operator and

18OP-TEE:https://www.op-tee.org/

19Qualcomm QSEE:https://www.qualcomm.com/snapdragon/security

20Trustonic Kinibi:https://www.trustonic.com/solutions/

government authority, for example – each comprising independent SD trees. A comprehensive set of management functions, including the installation, deletion and locking of TAs in order to prevent further updates and the configuration and personalisation of SDs, are found in the GP TMF specification [107].

The following section gives special attention is given to the GP TEE’s pro-tection profile and deployment model (as assumed in the CC PP), as it forms the security basis of the systems, protocols and architectures proposed in the forthcoming chapters of this thesis.

Protection Profile

The GlobalPlatform Protection Profile [40] is designed for a target of evaluation (TOE) based on the GP TEE. The TOE must implement the GP System Architec-ture, Internal and Client APIs; it comprises any hardware, firmware and software used to provide the TEE security functionality and secure usage of the TEE after delivery. The GP TEE PP does not consider the REE or any individual client or trusted applications. At present, the minimum assurance level for compliance is CC EAL2.

The profile is split into TEE Base, which covers any GP TEE, and the Time and Rollback modules that are implemented separately. The TEE Time and Rollback modules address the requirement for monotonic TA persistent time, integrity verification of TA code, configuration and trusted persistent storage.

The TOE may require additional, non-TOE hardware to operate, such as other flash memory storage units, but the TOE must not rely on the correct behaviour of such units. The profile lists a series of assets aboard the TEE and the security properties that should be upheld; Table2.2lists these assets and their security requirements, aggregated from the TEE Base, Time, Rollback and Debug modules.

The current version “targets threats to the TEE assets that arise during the end-usage phase and can be achieved by software means...focuses on non destructive software attacks that can be easily widespread...and constitute a privileged vector for getting undue access to TEE assets without damaging the device itself” [40]. This may, for example, include threats that attempt to recover keys for accessing corporate data or enforcing DRM video playback, which is implemented by a TA in the TEE. It does not protect against poorly-designed TAs containing improper use of cryptographic

algorithms and TA programming errors in general.

TABLE2.2: Security requirements of GP TEE assets.

Asset Property

C I AU U UP AT DB M CO IM

TEE Identifier 3 3

RNG 3

TA Code 3 3

TA Data and Keys 3 3 3 3 3 3

TA Instance Time 3

TA Run-time Data 3 3 3

TA Persistent Data 3 3 3 3 3

TEE Firmware 3 3

TEE Init. Code and Data 3

TEE Storage RoT 3 3

TA Persistent Time 3

Rollback Detection Data 3 TEE Debug Auth. Key 3 3

C: Confidentiality, I: Integrity, AU: Authenticity, U: Uniqueness, UP: Unpredictability, AT: Atomicity, DB: Device Binding, M: Monotonicity, CO: Consistency, IM: Immutability.

The reader is referred to [40] for a full list of all the security and organisational controls, delivery and deployment assumptions and requirements. Importantly, the PP defines two untrusted world adversaries that any GP TEE must protect against:

• Basic remote attacker: “Performs the attack on a remotely-controlled device or alternatively makes a downloadable tool that is very convenient to end-users. The attacker retrieves details of the vulnerability identified in the identification phase and [...] makes a remote tool or malware and uses techniques such as phishing to have it downloaded and executed by a victim” [40].

• Basic (on-)device attacker: “Has physical access to the target device; it is the end-user or someone on his behalf. The attacker is able to retrieve exploit code, guidelines written on the internet on how to perform the attack, and downloads and uses tools to jailbreak/root/reflash the device in order to get privileged access to the REE allowing the execution of the exploit. The attacker may be a layman or have some level of expertise but the attacks do not require any specific equipment” [40].

Additionally, the the GP TEE Exploitation Profile (Appendix A.2 of [40]) covers four capability levels of these adversaries (in increasing order):

1. Remote – an adversary without physical access who uses malware or phishing through which to conduct an attack on the TEE.

2. Local layman – a low capability adversary with physical access, who may jailbreak/root/reflash the device, and use standard equipment available through the Internet with information from an Internet resource, e.g. tuto-rial.

3. Local proficient attacker – same as (2) but with greater expertise and more time; assumes the use of standard equipment, such as oscilloscope, voltage supply and low-end visible light microscope.

4. Local proficient attacker with equipment – same as (3), but possesses spe-cialist equipment, including chemical etching tools, UV-light microscopes, laser apparatus and micro-probe workstations.

Specifically, the GP TEE addresses 14 threats, which are described in Table2.3.

The current GP TEE CC requires resistance to attackers with TEE-Low attack potential. This is deduced from the Attack Quotation Grid using the sum of the adversary capability, elapsed time, and any organisational controls, including those that inhibit access to the TOE TEE’s designs (VHDL/Verilog SoC designs) and source code, like requiring non-disclosure agreements (detailed further in Annex A.1 in [40]). While the security threats in Table2.3imply protection against hardware/physical attack vector, the TOE must only satisfy the TEE-Low criteria, which, in practice, does not address threat actors with significant expertise and bespoke equipment. Comparatively, the Eurosmart Security IC PP stipulates conformance to EAL4+ with protections against expert adversaries possessing specialist tools found in ‘solid -state physics research and IC failure analysis’. As such, while a TEE may protect against expert adversaries with bespoke equipment (reaching the security rating of TEE-High or beyond), the PP states that this “is often beyond reach” of most TEEs, nor is it it necessary for CC certification.

Deployment Model

GlobalPlatform provides a reference deployment model comprising six stages, which are listed as follows:

1. The TEE hardware designer is responsible for designing the IP cores for processors and other components used for hosting TEE software, main-taining inter-world hardware-enforced separation, and other hardware security resources used by the TEE, e.g. secure clocks and cryptographic co-processors.

TABLE2.3:GlobalPlatformTEECCPPthreats.

CCThreatCodeDescription

T.ABUSE_DEBUG AnattackerisgrantedaccesstoTEEDebugfeatures,allowingthemtoobtainsensitivedataorbypass,deactivateorchangesecurityservices.

T.TA_PERSISTENT_TIME_ROLLBACKAnattackermodifiesTApersistenttime;forinstance,toextendexpiredrights.

T.ROLLBACK AnattackerbacksuppartorallstoragespacesandrestoresthemlaterinordertouseobsoleteTAservicesorhavetheTAuseobsoletedata.

T.RNG AttackerexploitsanRNGwithinsufficiententropy,thuscomprisingTEE-generatedsecretsderivedfromrandomnumbers.

T.SPY AttackerwhoaccessesTEEstoragebymeansofrun-timeattacks,thusviolatingdataconfidentiality(thismayalsoincludebusprobing,timingandpowerconsumptionside-channels).

T.RAM PartialortotalrecoveryofconfidentialRAMcontent,potentiallyallowingtheattackertointerferewithTEEcodeanddata.

T.IMPERSONATIONImpersonatinganotherTAtocauseanotherTAtorevealconfidentialdata.

T.STORAGE_CORRUPTION AnattackercorruptstheTEE’snon-volatilestorageinordertotriggerunexpectedbehaviourfromsecurestoragemechanisms.

T.TEE_FIRMWARE_DOWNGRADEAnattackerbacksuptheTEEfirmwareandrestoresitlaterinordertouseobsoleteTEEfunctionalities.

T.PERTURBATION AnattackermodifiesthebehaviouroftheTEEoraTAinordertodiscloseormodifysensitivedataandservices.

T.ROGUE_CODE_EXECUTIONAnattackerimportsmaliciouscodeintotheTEEtodiscloseormodifysensitivedata.

T.CLONE AnattackercopiesTEE-relateddataofafirstdeviceonaseconddeviceinordertomakeitacceptthedataasgenuine.

T.ABUSE_FUNCT AnattackeraccessesTEEfunctionalitiesoutsideoftheirexpectedavailabilityrange,thusviolatingirreversiblephasesoftheTEElife-cycle/statemachine.

T.FLASH_DUMPThedumpingofnon-volatileflashmemory.

2. The TEE software developer develops the TEE’s software resources, including the TEE kernel and procurement of TAs. It also develops code used in initialising and instantiating the TEE, such as secure boot code, and any req-uisite drivers for interfacing with I/O peripherals in the trusted world. The TEE software developer is responsible for testing TEE software correctness and its compliance with the GlobalPlatform specifications.

3. The silicon vendor is responsible for producing the TEE chipset that inte-grates the hardware and software components from the previous steps. The silicon vendor may assume the role of hardware and software designer, or procure them externally. It produces the secure ROM code used as the root of trust, and incorporates any additional hardware, such as wireless (e.g.

Ethernet and 802.11 WiFi), I/O (e.g. GPIO and SPI) and GPU support, into the final chipset.

4. Device manufacturing is the production of the final product into its housing, including installing the previously developed chipset from the silicon ven-dor. Here, the REE software, root security domain(s), and any additional TAs are provisioned.

5. End-usage involves any final quality assurance steps before delivering the product to the client, and the process of aftercare is prepared. This includes the use of a Trusted Service Manager (TSM), which may be incorporated into the device manufacturer or outsourced, for managing the TEE through-out its lifecycle. This includes remotely performing updates, factory resets, and uninstalling and installing TAs.