GlobalPlatform Security Task ForceRoot of Trust Definitions and Requirements
Version 1.0.1

Public Release
March 2017
Document Reference: GP_REQ_025

Copyright  2014-2017, GlobalPlatform, Inc. All Rights Reserved.
Recipients of this document are invited to submit, with their comments, notification of any relevant patents or other intellectual property
rights (collectively, “IPR”) of which they may be aware which might be necessarily infringed by the implementation of the specification or otherwork product set forth in this document, and to provide supporting documentation. The technology provided or described herein is subject toupdates, revisions, and extensions by GlobalPlatform. Use of this information is governed by the GlobalPlatform license agreement and any use
inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

THIS SPECIFICATION OR OTHER WORK PRODUCT IS BEING OFFERED WITHOUT ANY WARRANTYWHATSOEVER, AND IN PARTICULAR, ANY WARRANTY OF NON-INFRINGEMENT IS EXPRESSLYDISCLAIMED. ANY IMPLEMENTATION OF THIS SPECIFICATION OR OTHER WORK PRODUCT SHALL
BE MADE ENTIRELY AT THE IMPLEMENTER’S OWN RISK, AND NEITHER THE COMPANY, NOR ANY
OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY
IMPLEMENTER OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER DIRECTLYOR INDIRECTLY ARISING FROM THE IMPLEMENTATION OF THIS SPECIFICATION OR OTHERWORK PRODUCT.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

3 / 74

Contents
1

Introduction ............................................................................................................................ 8

1.1
1.2
1.3
1.4
1.5
1.6

Audience ............................................................................................................................................... 8
IPR Disclaimer ...................................................................................................................................... 8
References ............................................................................................................................................ 8
Terminology and Definitions ...............................................................................................................10
Abbreviations and Notations ...............................................................................................................13
Revision History ..................................................................................................................................15

2

Overview ............................................................................................................................... 16

3

Requirements for a Root of Trust........................................................................................ 18

3.1
3.2
3.3
3.4

4

Shared Requirements for a Root of Trust ...........................................................................................20
Initial Root of Trust ..............................................................................................................................21
Enhanced Root of Trust ......................................................................................................................22
Primary and Secondary RoT ...............................................................................................................22

Root of Trust Security Services .......................................................................................... 23

4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9

5

Authentication Service ........................................................................................................................25
Confidentiality Service.........................................................................................................................25
Identification (of a Root of Trust) Service............................................................................................26
Integrity Service ..................................................................................................................................26
Measurement Service .........................................................................................................................26
Authorization Service ..........................................................................................................................27
Reporting Service ................................................................................................................................28
Update Service ....................................................................................................................................29
Verification Service .............................................................................................................................30

Chain of Trust ....................................................................................................................... 31

5.1

6

Requirements ......................................................................................................................................35

Root of Trust in GlobalPlatform Context ............................................................................ 37

6.1

Requirements for GlobalPlatform Secure Components ......................................................................39

7

Detailed TEE Use Cases for Roots of Trust ........................................................................ 41

7.1
7.2

Factory Creation, Installation, and Life Cycle of TEE Root of Trust ...................................................43
Roots of Trust and TEE.......................................................................................................................46
7.2.1 #1 Roots of Trust Security Services for TEE RTE Instantiation ..................................................46
7.2.2 Boot of TEE RTE..........................................................................................................................52
7.2.3 #2 RoT Security Services Offered to a Trusted Application on the TEE Platform .......................54
7.2.4 #3 RoT Security Services Offered to Remote Entities by the TEE Platform ...............................56
7.2.5 #4 RoT Capabilities that Applications in the TEE Platform May Offer to Other Platforms ..........598

Detailed Secure Element Use Case for Root of Trust ........................................................ 60

8.1
8.2
8.3

Factory Creation, Installation, and Life Cycle of Secure Element ......................................................60
Root of Trust and Secure Element......................................................................................................62
Authentication Service ........................................................................................................................65
8.3.1 Cardholder Verification Method ...................................................................................................65
8.3.2 Secure Channel Protocol .............................................................................................................65
8.4
Confidentiality Service.........................................................................................................................66
8.4.1 Application Firewall ......................................................................................................................66
8.4.2 Secure Channel Protocol .............................................................................................................66
8.5
Identification Service ...........................................................................................................................66
8.6
Authorization Service ..........................................................................................................................67

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

4 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

8.7
8.8
8.9

Reporting Service ................................................................................................................................68
Update Service ....................................................................................................................................68
Verification Service .............................................................................................................................69
8.9.1 Loading Information .....................................................................................................................69
8.9.2 Runtime Verification .....................................................................................................................69

9

Multi-Platform Use Cases for RoTs ..................................................................................... 70

9.1

Contactless Transaction with TEE and SE .........................................................................................71
9.1.1 Preparation ...................................................................................................................................71
9.1.2 Performing a Contactless Transaction .........................................................................................71
9.2
An REE Interacting with a TPM on TEE or SE ...................................................................................73

Annex A

Detailed HSM Use Cases for Roots of Trust ....................................................... 74

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

5 / 74

FiguresFigure 2-1: Architecture Overview ...................................................................................................................17
Figure 4-1: Possible Relationship of Independent and Composite RoT Security Services ............................24
Figure 5-1: Example of an Implicit Chain of Trust ...........................................................................................31
Figure 5-2: Example of an Explicit Chain of Trust ...........................................................................................32
Figure 5-3: Explicit Chain of Trust between Two Platforms ............................................................................33
Figure 5-4: Example of an Explicit Chain of Trust that Extends the Confidentiality Service ...........................34
Figure 5-5: Example of an Implicit Chain of Trust Containing an Explicit Chain of Trust................................35
Figure 7-1: Life Cycle of TEE-enabled Device ................................................................................................43
Figure 7-2: Life Cycle of Root of Trust ............................................................................................................45
Figure 7-3: Example of Device Boot with TEE Platform ..................................................................................48
Figure 7-4: One Example of Security Domain Structure .................................................................................57
Figure 8-1: Secure Element Life Cycle ............................................................................................................60
Figure 8-2: Secure Element Architecture Diagram..........................................................................................62
Figure 9-1: Example of Multiple RoTs Platform in Device ...............................................................................70
Figure 9-2: Contactless Transaction with TEE and SE ...................................................................................72

TablesTable 1-1: Normative References...................................................................................................................... 8
Table 1-2: Informative References .................................................................................................................... 9
Table 1-3: Terminology and Definitions ...........................................................................................................10
Table 1-4: Abbreviations and Notations ..........................................................................................................13
Table 1-5: Revision History .............................................................................................................................15
Table 7-1: Life Cycle of TEE-enabled Device .................................................................................................44
Table 8-1: Life Cycle of SE ..............................................................................................................................61

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

6 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Requirements
Requirement 3-1: Computing Engine, Code, and Data ...................................................................................20
Requirement 3-2: Security Services ................................................................................................................20
Requirement 3-3: Certification .........................................................................................................................20
Requirement 3-4: Unique Identifiable Ownership............................................................................................21
Requirement 3-5: Mutability.............................................................................................................................21
Requirement 3-6: Ownership Transfer ............................................................................................................21
Requirement 3-7: One iRoT per Platform ........................................................................................................21
Requirement 3-8: Provenance (iRoT) .............................................................................................................21
Requirement 3-9: Temporal (iRoT)..................................................................................................................21
Requirement 3-10: Verification (eRoT) ............................................................................................................22
Requirement 4-1: Security Service Interface(s) ..............................................................................................25
Requirement 4-2: Authentication Service ........................................................................................................25
Requirement 4-3: Confidentiality Service ........................................................................................................25
Requirement 4-4: Identification Service ..........................................................................................................26
Requirement 4-5: Root of Trust Identity Authentication ..................................................................................26
Requirement 4-6: Integrity Service ..................................................................................................................26
Requirement 4-7: Measurement Service .........................................................................................................26
Requirement 4-8: Authorization Service ..........................................................................................................27
Requirement 4-9: Reporting Service ...............................................................................................................28
Requirement 4-10: Update Service .................................................................................................................29
Requirement 4-11: Verification Service ...........................................................................................................30
Requirement 5-1: Origin for Implicit Chain of Trust .........................................................................................35
Requirement 5-2: Origin for Explicit Chain of Trust .........................................................................................35
Requirement 5-3: Location ..............................................................................................................................35
Requirement 5-4: New Root of Trust ...............................................................................................................36
Requirement 5-5: Explicit Chain of Trust .........................................................................................................36
Requirement 5-6: Implicit Chain of Trust .........................................................................................................36
Requirement 6-1: Manufacturing Process .......................................................................................................39
Requirement 6-2: Manufacturing Process Certification ...................................................................................39
Requirement 6-3: Device Certification .............................................................................................................39
Requirement 6-4: GlobalPlatform Multi-tenant (CASD)...................................................................................39
Requirement 6-5: GlobalPlatform Secure Component Services .....................................................................39
Requirement 6-6: GlobalPlatform Secure Components Extend Confidentiality Service .................................39
Requirement 6-7: GlobalPlatform Verification RoT .........................................................................................40

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

7 / 74

Requirement 6-8: GlobalPlatform Security Domain Explicit Chains of Trust ..................................................40
Requirement 6-9: GlobalPlatform-unique RoT Identification ...........................................................................40
Requirement 8-1: SE Tamper Resistant .........................................................................................................64

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

8 / 74

1

Root of Trust Definitions and Requirements – Public Release v1.0.1

Introduction

The aim of this document is to provide definitions and requirements for the trusted computing concept of Rootof Trust in the context of GlobalPlatform. The document then proceeds to relate these definitions to existing
GlobalPlatform technologies, enabling third parties to better understand those technologies in trusted
computing terms.

1.1

Audience

This document is intended for use by the Trusted Computing community and others who need to relate Trusted
Computing concepts to GlobalPlatform products.

1.2

IPR Disclaimer

Attention is drawn to the possibility that some of the elements of this GlobalPlatform specification or other work
product may be the subject of intellectual property rights (IPR) held by GlobalPlatform members or others. For
additional information regarding any such IPR that have been brought to the attention of GlobalPlatform,
please visit https://www.globalplatform.org/specificationsipdisclaimers.asp. GlobalPlatform shall not be held
responsible for identifying any or all such IPR, and takes no position concerning the possible existence or theevidence, validity, or scope of any such IPR.

1.3

References
Table 1-1: Normative References

Standard / Specification

Description

Ref

GlobalPlatform Card
Specification

GlobalPlatform Card Specification[GPCS]

GPD_SPE_010

GlobalPlatform Device Technology
TEE Internal Core API Specification[TEE Core]

GPD_SPE_120

GlobalPlatform Device Technology
TEE Management Framework Specification[TMF]

GPD_SPE_021

GlobalPlatform Device Committee
TEE Protection Profile[TEE PP]IETF RFC 2119

Key words for use in RFCs to Indicate Requirement Levels[RFC 2119]

TCG

Trusted Computing Group Glossary,
http://www.trustedcomputinggroup.org/developers/glossary,
visited 23 February 2016[TCG]

ISO 7498-2:1989

ISO 7498-2: 1989 Information Processing Systems – Open
Systems Interconnection – Basic Reference Model –Part 2: Security Architecture, 2 February 1989

[7498-2]NIST

NIST SP 800-164 Guidelines on Hardware-Rooted Security
in Mobile Devices (Draft), National Institute of Standards
and Technology, October 2012

[NIST]

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

9 / 74

Table 1-2: Informative References
Standard / Specification

Description

Ref

GPCS Amendment B

GlobalPlatform Card, Remote Application Management
over HTTP, Card Specification v 2.2 – Amendment B[Amd B]GPD_SPE_009

GlobalPlatform Device Technology
TEE System Architecture[TEE Sys Arch]GPD_SPE_007

GlobalPlatform Device Technology
TEE Client API Specification[TEE Client]

GPD_SPE_100

GlobalPlatform Device Technology
TEE Sockets API Specification[TEE Sockets]

GlobalPlatform KMS

GlobalPlatform Key Management System Functional
Requirements v1.0

[KMS Rqmts]

Andreas M. Antonopoulos

Andreas M. Antonopoulos, “Cloud security: Root ofTrust”, Network World,
http://www.networkworld.com/columnists/2010/020210-antonopoulos.html, Feb 2, 2010, visited 23 February
2016[Andreas M.
Antonopoulos]

Chris Mitchell

Chris Mitchell, Trusted Computing, IEE Professional
Applications of Computing Series 6, The Institution ofElectrical Engineers, London, United Kingdom, 2005

[Chris Mitchell]

Craig Rawlings

Craig Rawlings, Certicom, “Securing SoC Platform
Oriented Architectures with a hardware Root of Trust”,
http://www.embedded.com/design/mcus-processorsand-socs/4008315/Securing-SoC-Platform-OrientedArchitectures-with-a-hardware-Root-of-Trust, Jul 6,
2009, visited 23 February 2016

[Craig Rawlings]

Graeme Proudler

Graeme Proudler, HP, “What’s in a Trusted Computing
Platform?”,
http://www.informit.com/articles/article.aspx?p=28804&
seqNum=4, Aug 23, 2002, visited 23 February 2016

[Graeme Proudler]

Kill jeep

Andy Greenburg, “Hackers Remotely Kill a Jeep on the
Highway – With Me in It”[Jeep killed]

http://www.wired.com/2015/07/hackers-remotely-killjeep-highway/
MMS attack

Thomas Fox-Brewster, “Stagefright: It Only Takes One
Text To Hack 950 Million Android Phones”[MMS Attack]http://www.forbes.com/sites/thomasbrewster/2015/07/2
7/android-text-attacks
Patrick Schaumont

Patrick Schaumont, Virginia Tech University, “Tree ofTrust”,
http://www.ece.vt.edu/news/ar07/treeoftrust.html,
visited 23 February 2016

[Patrick
Schaumont]

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

10 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Standard / Specification

Description

Ref

CCMB-2012-09001_002_003

Common Criteria for Information Technology Security
Evaluation:[CCMB-2012-09001_002_003]

1. Introduction and general model, September 2012,
version 3.1 Revision 4
2. Security functional components, September 2012,
version 3.1 Revision 4
3. Security assurance components, September 2012,
version 3.1 Revision 4
FIPS 140-2

Security Requirements for Cryptographic Modules[FIPS 140-2]

CPA

Commercial Product Assurance; information available
at: https://www.ncsc.gov.uk/[CPA]

CSPN CER I 02

Critères pour l’évaluation en vue d’une certification desécurité de premier niveau v1.1

[CSPN CER I 02]

OMTP ATE TR1Open Mobile Terminal Platform Advanced Trusted
Environment TR1 v1.1

[OMTP ATE TR1]

Security IC Platform

Security IC Platform Protection Profile with
Augmentation Packages from Eurosmart[Security IC
Platform]

UML

Unified Modeling Language; information available at:
http://www.uml.org/[UML]

TCG Whitepaper

TPM MOBILE with Trusted Execution Environment for
Comprehensive Mobile Device Security; available here

[TCG Whitepaper]

1.4

Terminology and Definitions

The following meanings apply to SHALL, SHALL NOT, MUST, MUST NOT, SHOULD, SHOULD NOT, and
MAY in this document (refer to [RFC 2119]):• SHALL indicates an absolute requirement, as does MUST.
• SHALL NOT indicates an absolute prohibition, as does MUST NOT.
• SHOULD and SHOULD NOT indicate recommendations.
• MAY indicates an option.

Selected terms used in this document are included in Table 1-3.
Table 1-3: Terminology and Definitions
Term

Definition

Actor

Unique entity participating in a GlobalPlatform compliant environment.
These entities can take the form of issuers, application developers,
production centers, service providers, provisioning systems, etc.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

Term

Definition

Chain of Trust

An Initial Root of Trust plus:

11 / 74• Zero or more Extended Enhanced Root(s) of Trust, each of which isverified by its parent Root of Trust within the chain• Any Validated/Measured Module that is verified by a Root of Trust or
by a Validated/Measured Module that extends theverification/measurement service within the chain• Any non-Root-of-Trust component that is measured and themeasurement preserved in a Root of Trust for Integrity within the chain
A Chain of Trust might also include a security service extension of a Rootof Trust.
Cold Boot

When power is cycled “off” and then “on” on a specific platform.

Computing Engine

In the context of this document, any system of hardware that willconsistently change in a deterministic manner from one state to another.
That deterministic manner is governed by the computing engine’s current
state, instruction code, and/or data. A platform must have one computing
engine.
Note: Hardware entropy sources are acted upon as an aspect of data,and so while they themselves are non-deterministic, the resultant value ata given point in time is acted upon by the computing engine in a
deterministic manner.

Credential

A key and/or password and/or any other data used in an authentication
protocol.

Critical Security Parameters

In the context of this document, security-related information (e.g. secretand private cryptographic keys, and authentication data such as
passwords and PINs) whose disclosure or modification can compromise
the Root of Trust Security Services.

DeviceA product that includes at least one platform.

Extended Enhanced Root ofTrust (eRoT)

A Root of Trust whose integrity is verified by another Root of Trust at any
point during the life cycle of the platform (see section 3.3) and that is notavailable from an ancestor entity.

Executable CodeIn the context of this document, a set of instructions in native orinterpreted language. These instructions are executed directly by the
hardware composing the computing engine itself, or indirectly if they are
instead interpreted by another executable code block.

eXecute in Place

Code that is designed such that it may be run directly from ROM or
FLASH (or other non-volatile storage) without loading into RAM before
execution.

Firmware

Software dedicated to interacting with device specific hardware.

Hardware Security Module(HSM)

A physical computing device that safeguards and manages digital keys forstrong authentication, and that provides cryptoprocessing.
The code, data, and keys of an HSM are collectively considered a Root ofTrust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

12 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Term

Definition

Initial Root of Trust (iRoT)

A Root of Trust that a platform manufacturer provisions and initializes
during the manufacturing process and that is the first executed on theplatform (see section 3.2).

Measured Module

A module measured by the RoT service for measurement or by any
component in a Chain of Trust for Measurement.

Measurement

In the context of this document, an operation that produces a platformcharacteristic.

ModuleA block of code and/or data and/or keys.

Next Executable CodeIn the context of this document, the executable code whose execution is
initiated by the current executable code block. Might or might not beprocessed by the same computing engine as the current executable code
block.

Platform

An execution environment inside a device. SE, TEE, and REE are
examples of platforms.

Platform Characteristic

A value that can be used to confirm the security condition of a platform;
for example, a cryptographic hash, code verification assertion, or
hardware state assertion.

PolicyA set of rules that defines access to services or assets.

Primary Root of Trust (pRoT)

A combination of an Initial RoT and zero or more Extended Enhanced
RoT which are executed on the same platform.

Proof of possession

A means of proving that a party sending a message is in possession of aparticular cryptographic key.

Root of Trust (RoT)

A computing engine, code, and possibly data, all co-located on the same
platform; provides security services (as discussed in Chapter 3).
No ancestor entity is able to provide a trustable attestation (in Digest orother form) for the initial code and data state of the Root of Trust.

Root of Trust Security
Service

In the context of this document, a service provided by a Root of Trust,such as authentication, authorization, confidentiality, identification,
integrity, measurement, reporting, update, or verification.

Secondary Root of Trust(sRoT)A RoT providing security services used by another platform.

Secure Component

GlobalPlatform terminology to represent either a Secure Element or a
Trusted Execution Environment.

Secure Element (SE)A tamper-resistant combination of hardware, software, and protocols
capable of embedding smart card-grade applications. Typical
implementations include UICC, embedded SE, and removable memory
cards.

Shielded Location

A location specifically designed and used for the purpose of securely
storing and protecting sensitive data; for example, a tamper-evident
and/or tamper-resistant memory or register.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

13 / 74

Term

Definition

TEE Run Time Environment(RTE)

In the context of this document, includes all the functionality a TEE may
offer after the boot phase. This includes (but is not limited to):• A selection of the TEE APIs defined by GlobalPlatform (as describedin TEE System Architecture ([TEE Sys Arch]))• Additional APIs defined by the Trusted OS vendor• Additional APIs defined by the Silicon Provider / OEM / Original Design
Manufacturer

Token

Data derived from a credential.

Trusted Execution
Environment (TEE)An execution environment that runs alongside but isolated from an REE.
A TEE has security capabilities and meets certain security-related
requirements: It protects TEE assets from general software attacks,
defines rigid safeguards as to data and functions that a program canaccess, and resists a set of defined threats. There are multiple
technologies that can be used to implement a TEE, and the level of
security achieved varies accordingly.
For more details of the TEE architecture and system requirements, see
GlobalPlatform TEE System Architecture ([TEE Sys Arch]). TEE security
requirements defined by the GlobalPlatform TEE Protection Profile([TEE PP]).

Trusted OS

A specific part of the TEE RTE that provides GlobalPlatform compliant
interfaces.

Trusted Service Manager

An entity trusted by other actors to be in charge of service managementand delivery.

Validated Module

Module verified by the RoT service for verification or by any component in
a Chain of Trust for Verification.

1.5

Abbreviations and Notations

Selected abbreviations and notations used in this document are included in Table 1-4.
Table 1-4: Abbreviations and Notations
Abbreviation / Notation

Meaning

APDU

Application Protocol Data Unit

API

Application Programming Interface

BTEE

Boot time Trusted Execution Environment

CASD

Controlling Authority Security Domain

CPA

Commercial Product Assurance

CRC

Cyclic Redundancy Check

CSPN

Certification de sécurité de premier niveau

CVM

Cardholder Verification Method

DEK

Data Encryption Key

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

14 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Abbreviation / Notation

MeaningeRoTExtended Enhanced Root of TrusteSEembedded Secure Element

FIPS

Federal Information Processing Standard

HSM

Hardware Security Module

HUK

Hardware Unique Key

iRoT

Initial Root of Trust

ISD

Issuer Security Domain

ISOInternational Organization for Standardization

JCRE

Java Card Runtime Environment

MAC

Message Authentication CodeNIST

National Institute of Standards and Technology

ODM

Original Design Manufacturer

OEM

Original Equipment Manufacturer

OMTP

Open Mobile Terminal Platform

OPEN

Open Platform Environment

OTA

Over The Air

OTP

One-Time Programmable

PCB

Printed Circuit Board

PIN

Personal Identification Number

PKI

Public Key InfrastructurepRoT

Primary Root of Trust

REERich Execution Environment

ROM

Read Only Memory

RoT

Root of TrustrSD

root Security Domain

RTE

Run Time Environment

SCP

Secure Channel Protocol

SD

Security Domain

SE

Secure Element

SoC

System-On-ChipsRoT

Secondary Root of Trust

SSD

Supplementary Security Domain

TA

Trusted Application

TAM

Trusted Application Manager

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

Abbreviation / Notation

Meaning

TCG

Trusted Computing GroupTCP/IP

Transmission Control Protocol / Internet Protocol

TEE

Trusted Execution Environment

TLS

Transport Layer Security

TMF

TEE Management Framework

TPM

Trusted Platform Module

TSM

Trusted Service Manager

TUI

Trusted User Interface

UDP/IP

User Datagram Protocol / Internet Protocol

UICC

Universal Integrated Circuit Card

XiPeXecute in Place

1.6

15 / 74

Revision History
Table 1-5: Revision History

Date

VersionDescription

October 2016

1.0

Public Release

March 2017

1.0.1

Maintenance Release, including the following changes:
The term "Extended Root of Trust” has been modified to “Enhanced
Root of Trust”.
Figure 5-1 has been modified.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

16 / 74

2

Root of Trust Definitions and Requirements – Public Release v1.0.1

Overview

Our lives are increasingly dependent on smart connected mobile devices. We use them to conduct business,maintain social relationships, make purchases, and enjoy media content. Despite the benefits, these devices
hold significant security assets and personal data that are susceptible to attacks from hackers. Furthermore,
the sheer number of applications that are easily available for download represents an even larger opportunity
for fraudsters.
Similarly, automotive and home devices are becoming increasingly connected and providing more capabilities
than their original core functionality. 1 Consumers are increasingly using their devices in new ways—organizing
a trip from one’s TV, streaming music while driving, and using a smartphone to pay for petrol. These expanded
practices create new security vulnerabilities, which in turn emphasize the need for mechanisms that allow
trusted parties to have access to applications without granting hackers, rogue applications, etc., the same
opportunity.
Two examples of increased complexity creating security holes:• A hacker was able to kill a jeep on the highway (see [Jeep killed]).
• A hacker used an MMS to install spyware on a mobile device (see [MMS Attack]).
The increased security needs are ultimately driven by new characteristics of consumers’ smart connected
devices. In order to prevent the theft of personal data, hijacking of a connected device, and other security
hazards, security solutions need to authenticate the user, securely store personal data, validate transactions,and so on.
The complexity of final solutions increases with the multiple actors that are used to provide a customer service.
A service provider that would like to deploy a service on mobile devices needs to rely on mobile characteristics
that it cannot manage. The maker of the mobile device, who is responsible for the security architecture, should
prevent security weaknesses. Within the mobile ecosystem, the handset maker might not be able to manage
all items. For example, a part of the OS might be provided by a third company. If the service provider needs
to connect to its service, it must rely on a connectivity service provider (e.g. Mobile Network Operator orInternet Service Provider).
All of these factors present security concerns that must be addressed in the market. One way of resolving
these issues is to provide a small, isolated execution environment for sensitive assets and code that would
allow service providers and OEMs to improve the user experience while increasing the security to prevent
fraud, to guarantee privacy, and so on.
Many security components claim to be Roots of Trust or to contain Roots of Trust. However, each vendor ofthese components has distinct and often independent ideas about what constitutes a root of trust. This
document explores the commonality among these Roots of Trust and defines their requirements andproperties. It also introduces a few use cases that rely on Roots of Trust to provide security services toplatforms and remote service providers (e.g. Mobile Network Operators).

1

Visit http://www.globalplatform.org/documents/whitepapers/IoT_public_whitepaper_v1.0.pdf.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

17 / 74

In the context of this document, Device, Platform, and Shielded Location are used with the following meanings:• A Device is an end-user product that includes at least one platform; for example, a UICC or a mobile
phone without UICC.
• A Platform is composed of one computing engine and executable code that provides a set offunctionalities; for example, a Trusted Execution Environment (TEE) or an embedded Secure Element(eSE). A platform may contain only one Initial Root of Trust (iRoT) and unlimited Extended Enhanced
Roots of Trust (eRoTs).
• A Shielded Location is a location specifically designed and used for the purpose of securely storingand protecting sensitive data; for example, a tamper-evident or tamper-resistant memory or register.
Figure 2-1 shows the [UML] architecture overview and the relation between the different entities.
Figure 2-1: Architecture Overview

Device1..nComputing engine

1

Platform

0..nRoot of Trust

Data/Key

1
Initial Root of Trust

1..n
0..n

Executable code block
LegendExtended Root of Trust

Composed ofInherited from

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

18 / 74

3

Root of Trust Definitions and Requirements – Public Release v1.0.1

Requirements for a Root of Trust

Many designers of security protocols, schemes, products, and services rely on a root of trust to provide
security. However, each designer has its own definition for a root of trust. Upon examining a variety ofdefinitions for Roots of Trust, one begins to see common properties and attributes for them.
The following are descriptive quotes from publications on Roots of Trust.
TCG says: A component that must always behave in the expected manner, because its misbehavior cannot
be detected. The complete set of Roots of Trust has at least the minimum set of functions to enable adescription of the platform characteristics that affect the trustworthiness of the platform. [TCG]
Graeme Proudler says: A root-of-trust is a set of unconditionally trusted functions and must be a computing
engine, because it must perform actions. It must work properly no matter what software is executing on theplatform, in order to be immune to software attacks. Ideally, it should also be immune to physical attack, toavoid the need to trust an owner or user of a platform (who might otherwise physically meddle with it).
Otherwise, a third party cannot unreservedly trust a remote platform. Unfortunately, physical immunity is
impossible, and we have to settle for mere physical protection. (It’s the same for smart cards and cryptocoprocessors.) For most commercial purposes, it’s sufficient to have a root-of-trust that’s built to resist a
modest level of physical attack. [Graeme Proudler]
Andreas M. Antonopoulos says: What that means is that trust flows down a chain until it reaches the rootof trust -- the foundation on which I have built my little tower of trust. I trust a door because I trust the lockbecause I trust the key because it is in my pocket. If I lose the key, the Chain of Trust unravels and I no
longer trust the door. [Andreas M. Antonopoulos]
Patrick Schaumont says: […] your root of trust […] is the element that is implicitly trusted, such as the keyof an encryption algorithm. Implementing the root of trust is always expensive, so the smaller you can makethis, the cheaper your system is. Indeed, the non-trusted elements can use standard components orsoftware. [Patrick Schaumont]
Craig Rawlings says: It has long been understood by security experts that a root of trust (ROT) is essential
to system security. A ROT is a secret that if kept will not compromise the security of the overall system.
A ROT is necessary to provide: (1) a safe place for system-critical secrets, (2) secure processes and (3)extended trust to internal and external entities. [Craig Rawlings]
Chris Mitchell says: […] Roots of Trust are functions that must operate as expected, irrespective of any
other process in a platform, because without them there is no way to believe anything reported by aplatform. [Chris Mitchell]
Note: As should be clear from the quotations above, a key is not a Root of Trust (although a Root of Trust
may include a key).
When a service is built on a device, several operations need to be executed before the application providing
the service is ready to use. During this period, the application must trust that the operations executed before
its execution are authentic and that no malware code is executed. It is better to verify the module and leave arecord of its verification that could be verified during the device execution. The module acting as RoT must be
as small as possible to limit its complexity, and must be certified. Reducing the RoT to the smallest size andcertifying it makes it more difficult to hack and/or load malware inside the Chain of Trust (see Chapter 5).
This paper recognizes that vendors will make various choices in designing and implementing Roots of Trust.
In some cases, an initial block of code starts executing but lacks the resources to record platformcharacteristics. In particular, if the initial block of code must pass execution control on to an independent blockof code, and it verifies the integrity and authenticity of the new code without recording that event before passing
control, then we say we are extending the Root of Trust from the first block to the next. The first block we callthe Initial Root of Trust or iRoT. The subsequent block, or blocks if there is a sequence of more than one such
event, we call an Extended Enhanced Root of Trust or eRoT.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

19 / 74

The following sections list the requirements that characterize a Root of Trust, clarifying expectations andfunctional behavior that the security industry needs of Roots of Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

20 / 74

3.1

Root of Trust Definitions and Requirements – Public Release v1.0.1

Shared Requirements for a Root of Trust

The following requirements apply to every Root of Trust (RoT) regardless of the security services it provides
or whether it is an Initial Root of Trust or an Extended Enhanced Root of Trust.
Requirement 3-1: Computing Engine, Code, and Data
A Root of Trust SHALL consist of a computing engine and executable code, co-located on the same
platform.
A Root of Trust MAY require data and/or key(s), and if so, the data and/or key(s) SHALL be co-locatedon the same platform as the computing engine and executable code.
Note: Italicized paragraphs in the remainder of this chapter are informative only.
The computing engine could be of any architecture, and the code is not limited to binary
instructions. The data may be an optional component for some Roots of Trust, but necessary forothers. The data may include an integrity measurement (such as a CRC or a cryptographic hash),a public key, a private key, a secret key, or other security assets.
Implementation note: A Root of Trust may have several types of implementations. An alternative
to the computing engine, executable code, and data (if needed) co-located on the same platform,
is a hardware logic that performs the equivalent Root of Trust Security Service. Examples include
Field Programmable Gate Arrays (FPGAs) and special cryptographic accelerators. The samerequirements apply to FPGAs and cryptographic accelerators that apply to other Roots of Trust.
Requirement 3-2: Security Services
A Root of Trust SHALL provide one or more security services.
Any Extended Enhanced Root of Trust module in a Chain of Trust for the security services offered,or any module or application, irrespective of the security service it provides, may rely on the Rootof Trust for the security services it offers.
It is not necessary that the security services provided by the Root of Trust be unique to the Deviceor platform it supports. Indeed, a Device may have multiple Roots of Trust providing the same
service. Nonetheless, a Root of Trust must provide a security service for the benefit of the platform.
Typical security services include, but are not limited to, authentication, authorization,
confidentiality, identification, integrity, measurement, reporting, update, and verification.
Requirement 3-3: Certification
The Root of Trust SHALL be suitable for a certification process for a platform or for a Device. In otherwords, an independent party, such as a testing lab, SHALL be able to assess the computing engine,code, and data, and verify that it performs the advertised service and satisfies the security claims of its
security target.
Following a successful assessment, an authority may issue a certificate proclaiming that the Rootof Trust meets a published set of security requirements.
Notable certification processes include: Common Criteria ([CCMB-2012-09-001_002_003]),
recognized by multiple countries; NIST FIPS 140-2 ([FIPS 140-2]); and national recognition
schemes such as CPA ([CPA]) in UK and CSPN ([CSPN CER I 02]) in France.
GlobalPlatform is launching a TEE Security Evaluation Secretariat to provide certification basedon the GlobalPlatform TEE Protection Profile ([TEE PP]).

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

21 / 74

Requirement 3-4: Unique Identifiable Ownership
A Root of Trust SHALL have a single identifiable owning entity.
Authorized Users, including end users, administrators, service providers, and content providers,must be able to attribute the security services provided by the Root of Trust to the owning entity.
This entity accepts responsibility for the Root of Trust, and if it can be updated, also for its update.
The owner of the Root of Trust is not necessarily the owner of the platform containing the Root ofTrust.
That ownership may be identified through a form of ID retrieval interface and/or the provision ofprovably correct key relationships.
Requirement 3-5: Mutability
Code and/or data of a Root of Trust SHALL be either immutable or its mutability controlled only by theunique identifiable owner.
Requirement 3-6: Ownership Transfer
If a Root of Trust implements an ownership transfer mechanism, then the current owner of the Root ofTrust SHALL provide a mechanism to authorize the transfer to the new owner.

3.2

Initial Root of Trust

An Initial Root of Trust is a root of trust whose code and data integrity cannot be measured and/or verified
immediately prior to its execution and consumption. The following requirements apply to an Initial Root of Trust(iRoT) regardless of the security services it provides.
Requirement 3-7: One iRoT per Platform
A Platform SHALL contain one and only one Initial Root of Trust.
Requirement 3-8: Provenance (iRoT)The platform manufacturer SHALL create and provision the Initial Root of Trust during the manufacturing
process.
Requirement 3-9: Temporal (iRoT)The Initial Root of Trust SHALL include the code which executes first upon the initialization of thecomputing engine during cold boot in that platform.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

22 / 74

3.3

Root of Trust Definitions and Requirements – Public Release v1.0.1

Extended Enhanced Root of TrustWe introduce the concept of Extended Enhanced Root of Trust to address several issues. In particular, theparent Root of Trust may be unable to access some shielded locations to preserve the reportable verificationof subsequent blocks of executable code, and consequently cannot leave a record of the verification of thecode (and associated data) before its execution.
• Some vendors may want to provide additional features or replace existing security services.
• In situations where the next block of code is from a vendor different from that of the original Root ofTrust, there is a desire to differentiate this code from the original Root of Trust.
An Extended Enhanced Root of Trust is a set of code and data whose integrity can be verified prior to its
execution.
When a Root of Trust transfers execution control to the next block of code outside of itself while not preserving
reportable verification, that code and data are an Extended Enhanced Root of Trust. Note that the transfer of
execution control to an Extended Enhanced Root of Trust may remove the availability of the services of its
parent Root of Trust.
To mitigate concerns about a large RoT resulting from the composition of an iRoT and one or more eRoTs,
which seemingly violates an implicit requirement that RoTs should be as small as possible, we rely on
requirement 3-3: Certification. Using a reputable third party to assess the RoTs against a published set of
security requirements provides some assurance that the RoTs will behave as expected.
If the Root of Trust does preserve reportable verification, then the next block of code is a non-Root-of-Trust
component and a link in a Chain of Trust.
The following requirements apply to an Extended Enhanced Root of Trust (eRoT) regardless of the security
services it provides.
Requirement 3-10: Verification (eRoT)
A parent Root of Trust SHALL verify the integrity of the code and data of an Extended Enhanced Rootof Trust before the first execution of the Extended Enhanced Root of Trust. A parent Root of Trust
SHALL NOT preserve the reportable verification of the code and data of an Extended Enhanced Rootof Trust.
An owner of the parent Root of Trust may authorize the instantiation of an Extended Enhanced
Root of Trust at any point during the life cycle of the platform (including manufacturing process).
A parent Root of Trust may be either an Initial Root of Trust or an Extended Enhanced Root ofTrust.
A parent Root of Trust does not keep a record such as a hash of the code and data in a shielded
location before the eRoT’s execution. Following the eRoT’s execution, it will not be possible toaccess a record of the verification of the eRoT.
This is the method many embedded devices use to instantiate higher level functionality. Lower
level security checks are performed, but the space taken by the code and data they validate does
not leave storage for either the results or code to report those results after the higher layer has
started.

3.4

Primary and Secondary RoT

A Primary Root of Trust (pRoT) is a combination of an Initial RoT and zero or more Extended Enhanced RoTs
which are executed on the same platform.
A Secondary Root of Trust (sRoT) is a RoT providing security services used by another platform.
Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

423 / 74

Root of Trust Security Services

This chapter provides definitions and requirements for the Root of Trust Security Services relevant to
GlobalPlatform. A Root of Trust may contain any combination of these services.
Recommendation for designers:
When calling attention to a Root of Trust, designers are encouraged to refer to the service or services
provided by the RoT in order to set the proper context and expectations. For example, say “The Root ofTrust for Verification is provided by this ROM code and data” or “That firmware provides a Root of Trust for
Update”.
With the proper context, software designers and evaluators can more readily assess whether or not a Rootof Trust provides the security services relevant to their security needs.
Several standards organizations define sets of security services. For example:• ISO 7498-2 standardizes and manages the following security services:
authentication, access control, confidentiality, integrity, and non-repudiation (see [7498-2]).
• The Trusted Computing Group standardizes and manages the following security services as Roots ofTrust: measurement, reporting, and storage (see [TCG]).
• NIST standardizes and manages the following security services as Roots of Trust:
integrity, measurement, reporting, storage, update, and verification (see [NIST]).

Based on its experience with the devices and markets that GlobalPlatform addresses through its members,
GlobalPlatform has identified nine services that could be provided by Roots of Trust: authentication,
confidentiality, identification, integrity, measurement, authorization, reporting, update, and verification.
One may construct a Root of Trust with one or more security services. However, the Root of Trust cannot
claim to offer the service unless it exposes the interface to the service in some way. For example, consider aRoot of Trust implementing several Security Services where the Verification Service can maintain the shielded
location for the public key and be able to verify the integrity of the next component in the Chain of Trust (seeChapter 5) without exposing those protected capabilities offered by the Integrity Service and Measurement
Service. In this case, the RoT is only a RoT for Verification and cannot claim to be a RoT for Confidentiality or
Measurement since those services are tailored for and reserved exclusively for use by the RoT for Verification.
A Root of Trust may maintain one or more shielded locations used for the purpose of securely storing andprotecting sensitive data. A shielded location should be accompanied by an interface which provides theappropriate level of protection to limit access to the sensitive information and avoid unauthorized disclosure,use, and access (e.g. in an implementation, the sensitive data stored in a shielded location may only beaccessed by an API where the API checks the access right to this sensitive data). The level of physical andlogical protection of the shielded location may be dictated by certification policies, or by a vendor’s desire tooffer value-added features for their products.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

24 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

If the platform implements a Chain of Trust, the initial boot code executed during the cold boot of a platform
shall contain RoT Security Services. The initial boot code may use these services to perform security-related
tasks, such as verifying the integrity of other components before handing control to them or recording platformcharacteristics for future reference and reporting. As the device bootstraps its way through initialization, eachcomponent in the sequence may instantiate additional RoT Security Services and use them to performsecurity-related tasks, such as authorizing access to protected resources, updating critical device firmware, orreporting platform characteristics. Other security services can use the RoT Security Services to provide
protection of keys, data stored on the device, and data in transit to and from back-end services (e.g. Trusted
Service Manager). Application developers can use the RoT Security Services either directly or indirectly
through the use of those other security services. Service providers or content providers of the device andrecipients of the platform characteristics (e.g. firmware measurements) can have confidence that the platform
provides state-of-the-art security services using certified Roots of Trust.
One could define some independent services and some composite services. We call them independent
because one can implement their assigned service without the help of other services; that is, they are notdependent on the other services. The implementer of composite services decides how dependent they will beon other services: They could be completely self-contained, or they could use the assigned services of otherRoots of Trust, which makes them dependent on the other services.
The following figure illustrates a possible combination of RoT Security Services.
Figure 4-1: Possible Relationship of Independent and Composite RoT Security Services

Independent Security Services
Authentication

Confidentiality

Integrity

Measurement

Authorization

Verification

Identification

ReportingUpdatePossible Composite Security Services

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

25 / 74

Requirement 4-1: Security Service Interface(s)The interface (in this context, also called entry point) SHALL provide the ability to exercise the capability
or function of the Root of Trust as well as provide the appropriate level of protection for the shielded
locations to maintain the integrity of the contents. The interface SHALL enforce internal policy regarding
access to and use of the shielded locations.
The security service interface (or entry point) maintains the integrity of the contents of the shielded
locations, restricts them to authorized access and use, and protects them against unauthorized
use and disclosure.

4.1

Authentication Service

The Root of Trust for Authentication maintains one or more shielded locations for the purpose of securely
storing and preserving the integrity of at least one credential. A service user stores one or more authentication
credentials here for use at a later time to assist in authenticating compliance with a policy, such as performing
access control over the use and/or release of keys, or authorizing access to data. The Root of Trust for
Authentication also includes an interface to maintain authorized access to and use of the contents of theshielded locations as well as protecting it from unauthorized use and disclosure. In this case, authorized use
is for authentication purposes only.
Requirement 4-2: Authentication Service
The Root of Trust for Authentication SHALL maintain one or more shielded locations for storing
credentials to be used in authentication protocols.
The RoT may use this service to authenticate an external entity and vice versa, an external entity
may use this service to authenticate the RoT.

4.2

Confidentiality Service

The Root of Trust for Confidentiality maintains shielded locations for the purpose of storing sensitive data,such as secret keys and passwords.
Requirement 4-3: Confidentiality Service
The Root of Trust for Confidentiality SHALL maintain one or more shielded locations for the purpose ofstoring secret values. Since the values are secret, the interface SHALL protect the contents fromunauthorized disclosure and use.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

26 / 74

4.3

Root of Trust Definitions and Requirements – Public Release v1.0.1

Identification (of a Root of Trust) Service

The Root of Trust for Identification maintains a shielded location for storing a secret value, such as a symmetric
key or an asymmetric private key, for the purpose of establishing the identity of the Root of Trust. This identity
should not be confused with the owner of the Root of Trust, the owner of the platform, or the owner of thedevice. This identity is only for the Root of Trust. Through its signing capability, the Identification Service
provides message origin authentication.
An implementation may store the hash of a public key certificate in a shielded location in which the Root ofTrust protects it from unauthorized modification. In the case of an Initial Root of Trust, this identity may serve
as a proxy for the identity of the platform, since a platform contains one and only one Initial Root of Trust.
Requirement 4-4: Identification Service
The Root of Trust for Identification SHALL maintain a shielded location for storing a secret value. It
SHALL also maintain an interface which provides identification services for proof of possession. Any
Root of Trust SHOULD use standard protocols for authenticating its identity to other entities.
Requirement 4-5: Root of Trust Identity Authentication
The owner of a Root of Trust SHOULD vouch for the identity of the RoT, e.g. in the form of a public key
certificate signed by the manufacturer or vendor of the Root of Trust.

4.4

Integrity Service

The Root of Trust for Integrity maintains shielded locations for the purpose of storing and protecting the integrityof non-secret critical security parameters and platform characteristics. Critical security parameters include, but
are not limited to, authorization values, public keys, and public key certificates.
Requirement 4-6: Integrity Service
The Root of Trust for Integrity SHALL maintain shielded locations for the purpose of storing andprotecting the integrity of non-secret but critical security parameters and platform characteristics. Theinterface SHALL protect the shielded locations from unauthorized modifications.

4.5

Measurement Service

The Root of Trust for Measurement provides the ability to reliably create platform characteristics. The Root ofTrust for Measurement may calculate the cryptographic hashes of code and data. The Root of Trust for
Measurement may convey such platform characteristics to other Roots of Trust or may allow the platformcharacteristics to be used by other RoT Security Services, such as the Root of Trust for Integrity, the Root ofTrust for Verification, and the Root of Trust for Update. An implementer using the Root of Trust for
Measurement may perform a measurement once prior to using the measured resource for the first time, or
periodically, as policy dictates.
Requirement 4-7: Measurement Service
The Root of Trust for Measurement SHALL reliably create platform characteristics.
The Root of Trust for Measurement typically does not contain a shielded location for themeasurement.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

4.6

27 / 74

Authorization Service

The Root of Trust for Authorization provides reliable capabilities to assess authorization tokens and determine
whether or not they satisfy policies for access control. It may store authorization tokens in shielded locations
or accept them through an interface. The policy may be resident in the Root of Trust for Authorization.
However, more sophisticated implementations may have the ability to ingest policies and tokens, do thecomputations to determine whether or not the tokens satisfy the policies, and return a simple Boolean to signal
the result (e.g. true = tokens presented satisfy the policy, false = tokens presented do not satisfy the policy).
Optional Composite Root of Trust
A possible composite Root of Trust for Authorization implementation would contain the features required
for a Root of Trust for Authentication and a Root of Trust for Integrity. Such a composite Root of Trust for
Authorization must maintain shielded locations for storing tokens and the same interface as the Roots ofTrust for Authentication and Integrity to control access to the use and modification of the shielded locations.
If the composite Root of Trust for Authorization exposes the interfaces for the Roots of Trust for
Authentication and Integrity, it can claim to be Roots of Trust for those services as well. If the composite
Root of Trust for Authorization does not expose those interfaces for external use, then it cannot claim toprovide those services.
Requirement 4-8: Authorization Service
The Root of Trust for Authorization SHALL reliably assess authorization tokens and determine whether
or not they satisfy policies for access control.
The Root of Trust for Authorization MAY provide the same services as the Root of Trust for
Authentication, Integrity, or both, in which case(s) it SHALL also satisfy the requirements for those Rootsof Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

28 / 74

4.7

Root of Trust Definitions and Requirements – Public Release v1.0.1

Reporting Service

The Root of Trust for Reporting reliably reports platform characteristics. It provides an interface that limits its
services to providing reports on its platform characteristics authenticated by a platform identity.
Optional Composite Root of Trust
A possible composite Root of Trust for Reporting implementation would contain the features required for
Roots of Trust for Authentication, Confidentiality, Identification, Integrity, and Measurement. In this case,the composite Root of Trust for Reporting must maintain shielded locations for storing platformcharacteristics and platform identity; must maintain the capabilities and interfaces that provide and protect
the services of Authentication, Confidentiality, Identification, Integrity, and Measurement; and must control
access to the use and modification of the shielded locations. This implementation need not expose theother services, but may maintain them strictly for the use of the Root of Trust for Reporting.
Alternatively, a composite Root of Trust for Reporting implementation may contain any subset of these
services, and rely on external RoT Security Services to complete the set.
If a composite Root of Trust for Reporting exposes the interface of any one or more of the Roots of Trust
for Authentication, Confidentiality, Identification, Integrity, and Measurement, then it can claim to be a Rootof Trust for each such service as well. If the composite Root of Trust for Authorization does not expose theinterface of one of those Roots of Trust for external use, then it cannot claim to be a Root of Trust for that
service.
Requirement 4-9: Reporting Service
The Root of Trust for Reporting SHALL have the capability to reliably report platform characteristics
authenticated by the platform’s identity in a non-repudiable way. The Root of Trust for Reporting MAY
provide the same services as any one or more of the Roots of Trust for Authentication, Confidentiality,
Identification, Integrity, and Measurement, in which case(s) it SHALL also satisfy the requirements foreach such Root of Trust. It MAY provide these services in addition to the Root of Trust for Reporting, or
MAY leverage these services from Roots of Trust that are physically independent. The Root of Trust for
Reporting SHALL provide freshness for reports of the platform characteristics. The Root of Trust for
Reporting SHALL provide an interface that limits its services to providing reports authenticated in a
non-repudiable way.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

4.8

29 / 74

Update Service

The Root of Trust for Update verifies the integrity and authenticity of signed updates, and upon a successful
verification, authorizes the initiation of the update process. A platform may employ a Root of Trust for Update
to update the code and data for Roots of Trust, including itself. Non-Root-of-Trust platform software may alsoutilize the Root of Trust for Update for updates.
Optional Composite Root of Trust
A possible composite Root of Trust for Update implementation would contain the features required for
Roots of Trust for Authentication (to authenticate the identity of the owner of the update), Authorization (toauthorize initiation of the update after satisfying the policy), Confidentiality (if needed to protect secret keys),
Integrity (to protect public keys and platform characteristics, if needed), and Measurement (to recreate
platform characteristics, e.g. cryptographic hash of the update payload). In this case, the composite Rootof Trust for Update must maintain shielded locations for storing owner identity and authorization tokens, ifany; maintain the capabilities and interfaces that provide and protect the services of Authentication,
Authorization, Confidentiality, Integrity, and Measurement; and control access to the use and modificationof the contents of the shielded locations. Alternatively, a composite Root of Trust for Update may containany subset of these services, and rely on independent services to complete the set.
If a composite Root of Trust for Update exposes the interface of any one or more of the Roots of Trust for
Authentication, Authorization, Confidentiality, Integrity, and Measurement, then it can also claim to be a
Root of Trust for each such service as well. If the composite Root of Trust for Update does not expose theinterface of one of those Roots of Trust for external use, then it cannot claim to be a Root of Trust for that
service.
Requirement 4-10: Update Service
The Root of Trust for Update SHALL verify the integrity and authenticity of signed updates, and uponsuccessful verifications, SHALL authorize the initiation of the update process. It MAY contain the RoT
Security Services, such as Authentication, Authorization, Confidentiality, Integrity, and Measurement,
necessary to perform the update, in which case the Root of Trust for Update must satisfy therequirements which correspond to those services, even if it does not expose the service via an interface.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

30 / 74

4.9

Root of Trust Definitions and Requirements – Public Release v1.0.1

Verification Service

The Root of Trust for Verification verifies the integrity and authenticity of signed objects. Objects may include,
but are not limited to, public keys, code, and data. A platform may employ an Initial Root of Trust for Verification
to verify the code and data for Extended Enhanced Roots of Trust as well as non-Root-of-Trust code and data.
Ideally, a platform uses a Root of Trust for Verification to verify non-Initial-Root-of-Trust code and data prior toits execution. Non-Root-of-Trust platform software may also utilize the Root of Trust for Verification.
Optional Composite Root of Trust
A possible composite Root of Trust for Verification implementation would contain the features required for
Roots of Trust for Authentication (if needed to authenticate the identity of the owner of the object being
verified), Confidentiality (if needed to protect secret keys), Integrity (if needed to protect public keys andplatform characteristics), and Measurement (to recreate platform characteristics, e.g. cryptographic hashof the update payload). In this case the composite Root of Trust for Verification may maintain shielded
locations for storing owner identity, keys, and platform characteristics, if any; maintain the capabilities andinterfaces that provide and protect the services of Authentication, Confidentiality, Integrity, andMeasurement; and control access to the use and modification of the contents of the shielded locations.
Alternatively, a composite Root of Trust for Verification may contain any subset of these services, and rely
on independent services to complete the set.
If a composite Root of Trust for Verification exposes the interface of any one or more of the Roots of Trust
for Authentication, Confidentiality, Integrity, and Measurement, then it can also claim to be a Root of Trustfor each such service as well. If the composite Root of Trust for Verification does not expose the interface
of one of those Roots of Trust for external use, then it cannot claim to be a Root of Trust for that service.
Requirement 4-11: Verification Service
The Root of Trust for Verification SHALL verify the authenticity of digital signatures and verify the
integrity of the objects protected by the signatures. It MAY contain any subset of the RoT Security
Services for Authentication, Confidentiality, Integrity, and Measurement necessary to perform signature
verification, in which case(s) it SHALL satisfy all the requirements which correspond to each suchservice, even if it does not expose the service via an interface. It MAY provide all these capabilities in
addition to the Root of Trust for Verification, or it MAY leverage these services from physicallyindependent Roots of Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

531 / 74

Chain of TrustThis document contains two forms of trust relationships: Implicit Chain of Trust and Explicit Chain of Trust. A
platform instantiates an Implicit Chain of Trust when it executes a sequence of code modules in an environment
in which it is infeasible to record the outcome of any code or data integrity verification that may take place. On
the other hand, a platform instantiates an Explicit Chain of Trust when it purposely extends a security service
in such a way that you can inspect the links in the chain created by the extensions at any time and verify theirvalidity, thus verifying the validity of the security service it extends from end to end.
The Implicit Chain of Trust occurs through a sequence of code modules in which a RoT performs verification
and authorization checks on the next code module. If it passes those checks (without the parent RoT leaving
a record behind), it may be executed and becomes an eRoT in an implicit Chain of Trust. The RoT performing
the verification is called the parent RoT and the eRoT is called the child RoT. The child RoT SHALL be addedin the same Chain of Trust that includes its parent RoT. In this case each new module gains an implicit trustfrom the previous module.
The following figure illustrates an example of an Implicit Chain of Trust based on a RoT for measurement
verification between an iRoT and an eRoT.
Figure 5-1: Example of an Implicit Chain of Trust

1. Execution

iRoT

Platform

2. RoT for Verification

3. Execute

4. Execution

eRoT

5. RoT for Verification

7. Execute

eRoT

8. Execution
Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

32 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

An Explicit Chain of Trust actually extends a service from a RoT (either a Primary or a Secondary RoT) or
module to other modules. A good example of this is a Chain of Trust for Verification, in which the RoT contains
a verification service, and uses that service to verify a module that contains a verification service similar to theverification service in the parent. An explicit Chain of Trust shall always start in a RoT. Like Roots of Trust,
Explicit Chains of Trust shall contain at least one security service. The method of extending the service froma Root of Trust to subsequent modules is highly implementation dependent.
The following figure illustrates an example of an Explicit Chain of Trust when the RoT for Verification isextended.
Figure 5-2: Example of an Explicit Chain of Trust

1. Execution

iRoT

2. RoT for Verification

Platform

3. Verification
record
4. Execute
5. Execution

Validated Module

6. RoT for Verification

7. Verification
record
8. Execute
9. Execution

RoT for Verification

Validated Module

An Explicit Chain of Trust might be extended or provided by a Root of Trust that is not hosted on the same
platform as the module extending the use of its security service; this is called a Secondary Root of Trust. The
security service extended or provided by a Chain of Trust hosted on the same platform is called a Primary
Root of Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

33 / 74

The following figure provides an example of the Chain of Trust between two platforms.
Figure 5-3: Explicit Chain of Trust between Two Platforms

1. Execution

iRoT

Platform A

2. RoT for Measurement

5. Execute
6. Execution

Measured
Module7. RoT for Measurement

10. Execute
11. Execution

Measured
ModulePlatform B
1. Execution

iRoT
4. Measurement
record
9. Measurement
recordCopyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

34 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

In the GlobalPlatform SE context, the Secure Channel Protocol service is reused by all owners of Security
Domains in a platform, but with each applying its own keys. The keys of these Security Domains are loaded
securely, through authorization of the current key already present in the SD. The limitation of access to the
key forms a Chain of Trust by extending the Confidentiality Service.
The following figure illustrates an example of an Explicit Chain of Trust that extends the Confidentiality Service.
The figure shows the evolution of one RoT that installs a new key through a RoT service for confidentiality;
this new key is then reused with the same code of the RoT service for confidentiality to perform operations(i.e. cipher some information).
Figure 5-4: Example of an Explicit Chain of Trust that Extends the Confidentiality Service
RoT

RoT

RoT

Code for RoT
confidentiality

Code for RoT
confidentiality

Code for RoT
confidentiality

Shieldedlocation
1. KeyShieldedlocation
1. Key2. KeyRoT forConfidentiality

Shieldedlocation

RoT for Confidentiality

To provide
information
ciphering

1. Key2. KeyThis document does not list all the possibilities. Nonetheless, Chapter 7 explains Explicit Chains of Trust for a
few selected services.

The Trusted Computing community is more familiar with the Explicit Chain of Trust due to the PC and TPM
nature of the devices they have worked with. The embedded and mobile device communities are more familiar
with the Implicit Chain of Trust model found deployed in secure boot chains. Mapping both models in thisdocument is intended to clarify the concepts for those two key communities and improve communication
between the parties.

A Validated Module is one type of module that may make use of a Chain of Trust. It must have been correctly
authorized and verified by a security service, and it must have an accessible record of this action.
A Measured Module is another type of module that may make use of a Chain of Trust. It must have beencorrectly authorized and measured by a security service, and it must have an accessible record of this action.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

5.1

35 / 74

Requirements

Requirement 5-1: Origin for Implicit Chain of Trust
An Implicit Chain of Trust SHALL always start with an Initial Root of Trust (iRoT).
Note: Italicized paragraphs throughout this chapter are informative only.
If a platform implements an Implicit Chain of Trust, it is initialized by the iRoT. An Implicit Chain ofTrust may contain sRoTs as code modules.
A platform that does not contain an iRoT cannot implement a Chain of Trust.
An Implicit Chain of Trust may have modules that are part of the Explicit Chain of Trust.
Figure 5-5: Example of an Implicit Chain of Trust Containing an Explicit Chain of Trust

1. Execution

iRoT

Platform

2. RoT for
Measurement

4. Execution

3. Execute

5. RoT for
Verification
eRoT
6. Verification
record
8. Execution

RoT forVerification

Validated
Module9. RoT for
Measurement

11. ExecutioneRoT

Requirement 5-2: Origin for Explicit Chain of Trust
An Explicit Chain of Trust SHALL always start with a Root of Trust (RoT).
If a platform implements an Explicit Chain of Trust, it is initialized by a RoT. However, it is notnecessary that the RoT be a pRoT. An sRoT may also serve as the Root for an Explicit Chain ofTrust.
Requirement 5-3: Location
The RoT(s) composing a pRoT SHALL be on the same platform.
The components in an Explicit Chain of Trust rooted in a pRoT must be co-located on the same platform
as the pRoT.
If a platform composed of several components includes a Chain of Trust, the component that hosts
the iRoT for the Chain of Trust shall start first in this platform.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

36 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Requirement 5-4: New Root of TrustThe child RoT SHALL be added in the same Chain of Trust as its parent RoT.
When a RoT verifies the code and data of an eRoT before its first execution:• The RoT performing the verification is called the parent RoT.
• The eRoT is called the child RoT.
When a Root of Trust (either an iRoT or an eRoT) adds a new RoT, the Root of Trust that verified
the new RoT is called the parent and the new RoT is called the child.
Requirement 5-5: Explicit Chain of Trust
If a parent Root of Trust extends a security service, the parent SHALL measure or verify the integrity of
the child, and record that measurement or verification.
A second party can verify that the integrity measurement or check (in the case of a verification)
took place after its execution.
Requirement 5-6: Implicit Chain of Trust
If a parent Root of Trust enables a new security service by creating a RoT child, the parent SHALL
measure and verify the integrity of the child but it MUST NOT record that data.
A second party cannot verify that the integrity measurement or check (in the case of a verification)
took place after execution of the RoT child.
Otherwise it is an Explicit Chain of Trust as Validated/Measured Module in a Chain of Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

637 / 74

Root of Trust in GlobalPlatform Context

The GlobalPlatform technology discussed in this document is specified in the Card Specification [GPCS] for
the Secure Element and the TEE Internal Core API Specification [TEE Core] for the Trusted Execution
Environment.
The security architecture of GlobalPlatform Secure Components (SE or TEE) is based on:• Component management through a hierarchy of Security Domains, where each Security Domain on
the platform represents an actor involved in the management of applications• Strongly isolated execution of applications inside those components
The Security Domain has multiple responsibilities:• For actors: Store management rules and access rights required to the platform data of the Security
Domain owner.
• For service providers: Install applications in a secure and controlled manner, allowing the set-up ofservices (such as banking applications for a bank).
• For service provider aggregators: Provide a management entity that enables service providers to form
relationships over multiple classes of devices. An aggregator (aka TAM or TSM) may exist on many
devices and offers this channel to service providers.
The GlobalPlatform secure chip specifications require that a Security Domain exists before any service isprovided. The presence of this Security Domain implies the presence of an Initial Root of Trust (iRoT) as
defined in this document.
When loading the key(s) during the platform manufacturing process, the manufacturer shall:• Ensure the correctness and authenticity of computing engine and code
• Ensure the secrecy of the keys
The security level of the manufacturing process determines the trust level that you can have in the platform.
For the Secure Element, this is done in a secure and controlled facility, where the facility has strong physicalrestricted access and the manufacturing process is audited.
Multiple certification schemes (such as Common Criteria or EMVCo) describe the way to evaluate and certify
the computing engine, code, and manufacturing process and determine the assurance level of the iRoT and
the first Security Domain.
A part of the code of the Issuer or root Security Domain code and its data and keys is a Root of Trust as
defined in Chapter 3.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

38 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

The Issuer or root Security Domain and the Supplementary Security Domain provide security services(extension) as defined in Chapter 4 for the actors (Card Issuer, Application Provider, or an independent entity
responsible for enforcing specific off-card and on-card security policies).
As an example, a Security Domain provides secure channel services that offer protection of messages
between the platform and an off-platform entity:• Entity authentication – In which the platform or the off-platform entity proves its authenticity to theother entity by means of a challenge-response protocol• Message integrity and authentication – In which the receiving entity (the platform or off-platform
entity) ensures that the data being received from the sending entity (respectively the off-platform entity
or platform) actually came from an authenticated entity in the correct sequence and has not beenaltered• Confidentiality – In which data being transmitted from the sending entity (the off-platform entity or
platform) to the receiving entity (respectively the platform or off-platform entity) is not viewable by an
unauthenticated entity

Suppose vendors build SEs and TEEs to satisfy RoT requirements. Since SE and TEE specifications requirethem to validate all SE and TEE applications, respectively, these applications become Validated Modules. Aslong as the GlobalPlatform Secure Components provide reportable assertions of the validations, Validated
Modules can become part of an Explicit Chain of Trust for the security services they provide, if any.
The owner of a Security Domain may authorize the installation of a new Security Domain on the Secure
Element or the Trusted Execution Environment for another actor. GlobalPlatform offers the possibility to createa child Security Domain and include it in the Security Domain Chain of Trust by service extension from the
RoT of the GlobalPlatform Secure Component.
The RoT of the GlobalPlatform Secure Component is composed of the first SD, plus additional specific partsof code, data, and keys.
The secure component administration is based on a Chain of Trust that indicates at each node of the hierarchy
which actors are allowed to perform what actions in the environment.
The Chain of Trust is controlled during the creation of the child Security Domain and specific rules may be
stored that will be enforced during all content updates of the secure component.
To support dynamic ecosystems, it’s possible to create different independent hierarchies inside the securecomponent. This allows different ecosystems to manage in parallel a part of the secure component. In such amulti-tenant environment and to avoid a monopolistic approach, a specific SD or RoT has been created toallow the confidential loading of keys of any actors in the platform. In [GPCS] we refer to this by the term
Controlling Authority SD. Such an SD performs only confidential key loading services to other SDs.
GlobalPlatform technologies need to fulfill the following requirements to achieve the more general RoT
requirements defined in Chapters 3 and 4.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

6.1

39 / 74

Requirements for GlobalPlatform Secure Components

Requirement 6-1: Manufacturing Process
The manufacturing process SHALL be protected with procedures to protect the chip design, code, andkeys during the fabrication.
Note: Italicized paragraphs throughout this chapter are informative only.
Example: An SE is assembled in a secure environment where the symmetric keys are injectedduring the manufacturing process. A Hardware Security Module (HSM) stores master keys andthe keys are diversified per chip. Procedures and access controls are in place to prevent key
access and software manipulation during the manufacturing process.
Example: For a TEE, the TEE boot chain signing private keys are stored in an HSM. Factory
installed SD and TA related master keys are generated on the platform or in an HSM in adiversified manner. Procedures and access controls are in place to prevent unauthorized key andsoftware modification or addition during the manufacturing process.
Requirement 6-2: Manufacturing Process Certification
The platform manufacturer SHALL be certified to prove that the manufacturing process to assemble in
the platform the code, data, and keys required by the Roots of Trust fits the customer security
requirements.
Requirement 6-3: Device Certification
The manufacturer SHALL certify the GlobalPlatform TEE (in the end-user device) or the GlobalPlatform
SE according to customer requirements for tamper-resistance to protect the Root of Trust’s code, data,
and keys.
For example, a TEE will typically be targeted to be certified against [TEE PP], though for somemarkets additional certifications may be required such as [FIPS 140-2].
Requirement 6-4: GlobalPlatform Multi-tenant (CASD)
If a Controlling Authority Security Domain (CASD), which is a Root of Trust for Confidentiality,
Authentication, and Integrity for GlobalPlatform Secure Elements, is present, it SHALL be loaded during
the manufacturing process.
Requirement 6-5: GlobalPlatform Secure Component Services
All GlobalPlatform Secure Components SHALL implement services for Confidentiality, Authentication,
Identification, Authorization, and Verification rooted in a Root of Trust.
GlobalPlatform Components MAY implement services for Reporting and/or Update.
Requirement 6-6: GlobalPlatform Secure Components Extend Confidentiality Service
GlobalPlatform Secure Components SHALL extend the Confidentiality service to the Security Domain.
All Security Domains on a GlobalPlatform Secure Component use the same code to perform
remote management actions on a particular platform. Authorization of the management actions is
performed by validation of key relationships between the authorizing Security Domain and entities
outside of the platform. Depending on the platform, this validation may be manifested by the key
relationship allowing establishment of an SE Secure Channel or a TEE Security Layer, or throughTEE validation of a command an authorization token. A Security Domain extends the RoT for
Confidentiality and (optionally) the RoT for Authorization by reusing the same code but adding
keys loaded under the protection of the authorizing Security Domain.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

40 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Requirement 6-7: GlobalPlatform Verification RoTThe Initial Root of Trust SHALL verify the integrity and presence of key and data sets. If the verification
fails, the RoT SHALL forbid any interaction with any interface in the platform enabled by that key or data
set.
Requirement 6-8: GlobalPlatform Security Domain Explicit Chains of Trust
Each component in a Security Domain Explicit Chain of Trust SHALL have a unique identifiable owner.
Requirement 6-9: GlobalPlatform-unique RoT Identification
Each GlobalPlatform Secure Component SHALL have a RoT Identification number, which SHALL be
unique among all GlobalPlatform RoTs.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

741 / 74

Detailed TEE Use Cases for Roots of Trust

The Trusted Execution Environment is an embedded platform found on computing devices, offering an isolated
execution space for validated, authorized software (Trusted Applications – TAs) away from the genericexecution environment (the REE). It may be integrated into the device SoC, or provided as a separate physicalcomponent mounted to the main device PCB.
GlobalPlatform specifications for TEEs enable:• Trusted storage of TA assets including keys and general data, in a manner such that only the storing
TA may use, retrieve, or modify this data
• General Trusted OS functionality such as key manipulation and creation• TA access to a simple user interface, enabling TAs to verify user identity in certified isolation, anddisplay confidential information without risk of any other device resident code intercepting orinterfering with that information• TA communication with suitably connected SEs on the device, using SCP if required• TA communication with remote servers over internet protocols, using TLS if required• TA communication with applications in the REE
TEEs can provide SD and TA OTA management structures in much the same way as can be found in the
Secure Element. In the TEE these allow:• Management isolation through the creation of root SDs
o A root SD is a Security Domain with no managing parent SD.
• Management delegation through the creation of child SDs
o A child SD is a Security Domain with a designated parent SD, which can provide some or all
management operations if required.
Implementations can choose to base the OTA management security on either secret key or PKI technology,
and have the choice of using Security Layers (similar to SE SCP) or protected Command authorization token
based interaction. Implementations can also choose to allow the installation of root SDs, child SDs, and TAs
either in the factory or in the field.
TEE OTA management capability includes potential rights to:• Install further SDs, update existing SDs, remove SDs, provision SD data
• Install further TAs, update existing TAs, remove TAs, provision a subset of TA data
• Perform general TEE management operations such as Factory Reset
Whether a specific TEE SD may perform any or all of these operations depends on its assigned rights.
The GlobalPlatform specification for OTA management of the TEE is called the TEE Management Framework([TMF]). This specification is in late draft, and while the protocol has yet to stabilize, the functionality
requirements have been agreed upon, so it is worth referencing.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

42 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

A TEE can support a number of customized security services in a host device such as a mobile phone ortablet. In particular, it can provide:• Security service for entity authentication• Security service for user authentication• Security service for data integrity• Security service for data confidentiality• Security service key provisioning
These security services can also be implemented without using a TEE. Using a TEE opens up the possibilityof a level of security assurance for the aforementioned services that might be out of reach of solutions that do
not involve a TEE. The reasons for this are as follows:• Protocol simplicity: Given that an application has to communicate with a range of protocols in relation
to security and non-security issues, separating the security-critical protocol usage into a TA should
simplify the security design and hence enable easier design time validation of those security-related
protocols.
• Software simplicity: Given that an application has to perform a range of functionality, both security
and non-security related, separating the security-critical functionality into a TA should simplify the
security design and hence enable easier design time validation of that security-related functionality.
• Physical and logical protection of keys: In order to offer the security services mentioned above, a TEE
has to perform authorization and validation through keys, in an isolated manner. TEE technology has
been engineered with exactly that goal in mind.
• Multi-stakeholder key management: In a multi-application environment, there may be multiple
stakeholders, each with their own cryptographic keys. A TEE that complies with the GlobalPlatform
specifications allows different stakeholders to manage their keys independently of each other.
The provision of RoT security services is one of the reasons that TEEs bring value to devices. A GlobalPlatform
TEE offers security services to its TAs. Depending on how the GlobalPlatform TEE boots, those security
services may be from an iRoT (e.g. TEE Run Time OS in ROM) or from an eRoT (e.g. TEE Run Time OS
validated as authorized by ROM (pRoT) or based on a RoT with components outside the TEE (sRoT)). Since
these security services are rooted in RoTs, users can have confidence in the security services offered by the
GlobalPlatform TEE and its TAs.
Implementing functionality in a TA inside the TEE environment brings the above advantages. In addition tothis, similarly to the way that a TCG TPM is a component of the Root of Trust offered by an x86 PC, when theTEE (or a TA) is present, it may be treated as a component of a Root of Trust by other platforms in the device.
The following sections discuss the TEE as defined in [TEE PP] and TEE System Architecture [TEE Sys Arch]and how the architecture relates to the concept of Root of Trust.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.1

43 / 74

Factory Creation, Installation, and Life Cycle of TEE Root of TrustThis section describes events in the device life cycle of a Root of Trust as used in the GlobalPlatform TEE
Protection Profile [TEE PP].
[TEE PP] defines the device life cycle of the TEE as follows:
Figure 7-1: Life Cycle of TEE-enabled Device

Non-TEE

Design environment

Phase 1

Additional SW design(REE)(optional) TA design

Additional HW
supporting the TEE

Additional ROM/
HW design

TEE
Secure boot/firmware
designTEE HW
design(optional) TEE
initialization code

TEE FW/SW
designTEE chipset design

Phase 2

Manufacturing environment

Additional
hardwaremanufacturing

Phase 3

TEE chipset manufacturing

TEE / REE /Additional software
LinkingPhase 4

Device assembly

Phase 5
End-Userenvironment

Phase 6

Device end-usage

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

44 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1
Table 7-1: Life Cycle of TEE-enabled Device

PhasesActors

1 & 2: Firmware / Software /Hardware design

The TEE software developer:• Is in charge of TEE software development and testing compliant with
GlobalPlatform specifications• May also develop the TEE initialization code that
instantiates/initializes the TEE (e.g. part of the secure boot code)• Specifies the TEE software linking requirements
The device manufacturer may design additional REE software that will belinked with the TEE in phase 4 to provide REE-controlled resources. He
may also design Trusted Applications that he will integrate in phase 4.
The TEE hardware designer is in charge of designing (part of) theprocessor(s) where the TEE software runs and designing (part of) the
hardware security resources used by the TEE.
The silicon vendor designs the ROM code and the secure portion of theTEE chipset. If the silicon vendor is not designing the full TEE hardware,
the silicon vendor integrates (and potentially augments) the TEE
hardware designed by the TEE hardware designer(s).

3: Silicon/chip manufacturing

The silicon vendor produces the chipset for a device which may containmany platforms. If the platform is a TEE, it enables, sets, or seeds the
Root of Trust of the TEE. It may perform similar operations for the otherplatforms.

4: Software manufacturing

The device manufacturer is responsible for the integration, validation, andpreparation of the software to load in the product that will include theTEE, any pre-installed Trusted Applications, and additional software
required to use the product (e.g. REE, Client Applications).

5: Device manufacturing

The device manufacturer is responsible for the device assembly andinitialization and any other operation on the device (including loading or
installing Trusted Applications) before delivery to the end user.

6: End-usage phase

The end user gets a device ready for use.
The Trusted Applications Manager is responsible for the loading,installation, and removal of Trusted Applications post-issuance.

7: End-usage termination

The end user terminates their relationship to allow device resale byperforming a factory reset of the TEE.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

45 / 74

Based on the life cycle of the TEE-enabled device, the life cycle of a RoT may be defined as follows:
Figure 7-2: Life Cycle of Root of Trust
Source of Trust

Design environment

RoT HW
designSecure boot/firmware design(optional) RoT initialization code

RoT FW/SW
designPhase 1

RoT chipset design

Phase 2

Manufacturing environment

RoT chipset manufacturing,seeding of RoT

RoT Additional
software Linking

Phase 4

Device assembling, initialization of
the RoT (e.g. key provisioning)

Phase 5
End-User environment

Phase 6

Phase 7

Device end-usage, usage of the RoT,
RoT is immutable in this phase, may SW
updateTermination of RoT,
destruction of all end-user credentials

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

46 / 74

7.2

Root of Trust Definitions and Requirements – Public Release v1.0.1

Roots of Trust and TEE

There are four levels of concern about RoTs in relation to a TEE in a device.
1

RoT used during initialization of a TEE

How did the TEE RTE instantiate itself into a run timestate?
This is of concern to those who wish to trust the TEE
itself.

2

3

4

RoT Security Services offered toapplication software on the TEE
platform

What does the TEE OS software offer to application
software?

RoT Security Services offered toremote entities (off device) by the TEE
platform

What does the TEE OS software offer to remote software
management?

RoT Security Services thatapplications in the platform may offer
to other TEE platforms

How can a Trusted Application (TA) act as a componentof a Root of Trust for another platform?

This is of concern to those who wish to make use of thetrusted environment to instigate further services.

This is of concern to those who wish to make use of thetrusted environment to remotely manage TEE services.

The following sections address those four areas.

7.2.1#1 Roots of Trust Security Services for TEE RTE Instantiation

The term “boot time” refers to the time frame from the reset/power-up of the underlying hardware to the time
an operating system has completed its initialization and loading and is offering services to generic applications.
Based on this definition, boot time software also includes any firmware/ROM code that takes over the control
of execution after the device is reset.
Only some TEEs need a boot time. TEEs resident in FLASH-based execution environments (like in an SE) do
not need to go through a distinct boot time involving a multi-step load/validate/execute boot as (like in an SE)
their code has been validated on installation, is executed in the validated location, and is guarded by hardware
against integrity failures.
As indicated in [OMTP ATE TR1], it is assumed that the integrity of the initial trusted boot code of a TEE isintrinsically guaranteed. Furthermore, OMTP Flexible Trusted Boot requirements and OEM-dependent bootoperations require that, during boot time, some services or operations need to be performed in a TEE.
Therefore, a minimal set of the TEE capabilities must exist during the general device boot time and, to enable
some of these services, a Trusted OS (or some simplified version thereof) may also exist. Such a minimal setof TEE capabilities is referred to here as a Boot time TEE (BTEE).
It is not the current intention of GlobalPlatform to define the capabilities of a BTEE, but it should be clear that
all elements involved in that boot action form parts of the TEE from the point of view of its instantiation andprotection.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.2.1.1

47 / 74

Typical Boot Sequence Involving a TEE

Figure 7-3 illustrates two simplified implementation examples of a device starting a TEE platform alongside an
REE platform. These are both examples and many variants are possible.
In both examples, the TEE platform boots from the embedded mask boot ROM code inside the SoC. ThisROM code will be simple and generally enough to enable moving to the next stage, and in good designs
perform a minimal POST.
This ROM code, combined with the computing engine and associated data, form the Initial Root of Trust
required of a platform.

Single Stage Boot
Single stage boot will then continue execution of the TEE RTE from the on-SoC FLASH; this is the sameprocess found in an SE.

Multi Stage Boot
Alternatively, the TEE code in the boot ROM may then load more complex boot stage software components
from non-volatile storage, verify them using the enabling TEE assets (for example, hashes stored in the bootROM or one-time programmable (OTP) fuses), before finally executing them in faster RAM memory.

When to Boot Relative to the Rest of the Device
During boot, some TEEs will configure the general host device’s isolation settings (e.g. internal data firewalls)
and so some TEEs need to boot before other platforms on the SoC, to protect their assets. This “first to boot”
is not necessary in TEE platforms that have their own dedicated resources, but even then, it is often desirable
to boot the TEE before the REE, as this allows the TEE to provide security services to an REE RoT enabling
REE Secure Boot. While implementations may choose to do otherwise, a GlobalPlatform TEE is only required
to offer its services once the REE has completed its own boot sequence.

Failure in TEE Secure Boot
Typically, if any loaded software component verification fails during boot, the boot process halts and the device
reboots with a possible error report/indication. In many devices it will then seek out externally-sourced flash
images to fix the problem, while other devices will default to a simplified TEE in ROM, enabling emergency
service functionality.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

48 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.10
Figure 7-3: Example of Device Boot with TEE Platform(a) ROM or internal FLASH based TEE
REE(b) ROM and external FLASH based TEE
REE

TEE

TEE
Device Reset
Event

Device Reset
Event
1

1

Loads & Verifies

4

Key
n

Order of first
execution
TEE primaryboot stage
TEE secondaryboot stage(s)REE Platform Code /Rich OS
(optionally Certified/Verified)Fetches signed codefrom file system(Not Optional) 5

Verifies(Not Optional)

TEE RTE

6

TEE Secondary Roots Of Trust or Security Service Extensions

REE Boot Stages(optionally Certified/
Verified)

REE
Roots Of Trust

REE
Roots Of Trust

3

3

REE Platform Code / Rich OS(optionally Certified/Verified)2

TEE Boot Stages“Firmware”(Optional)

2

REE Boot Stages(optionally Certified/
Verified)

Factory Only
Programmable
Storage

Immutable
ROM Code

TEE Primary
Root Of Trust

Immutable ROM and FLASH
Software.
TEE RTE (XiP)TEE Primary
Root Of Trust

Factory Only
Programmable
Storage

Copyright  2014-2016 GlobalPlatform, Inc. All Rights Reserved. The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this informationis governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

49 / 74

As shown in Figure 7-3 and discussed in the following sections, a TEE MAY go through various phases while
it prepares to offer GlobalPlatform compliant functionality. This section covers RoT functionality in relation tothis boot sequence and does not cover the RoT functionality exposed by the RTE.
While there are many possible variants, we will cover only the two based on systems shown in Figure 7-3.

7.2.1.2

TEE 1 of Figure 7-3: TEE RTE XiP in ROM or FLASH

This is a system where the TEE RTE and other software are executed from a non-volatile store without blocks
being preloaded into some other execution space such as RAM. This is a sensible design when the processor
bus speed matches the access speed of non-volatile store memory. This is common in technology used in SE
systems.
If TEE software is running XiP in either of the following:• ROM code and data used for XiP is intrinsically trusted, or• FLASH code and data used for XiP is intrinsically trusted once it has passed verification during theprocess of being written to the FLASH...then there is no cold boot verification before the execution of any code, as there is no access available forunauthorized modification of the code base. Mechanisms may be provided to perform runtime verification (e.g.
automatic memory checksums and more advanced techniques).
As the XiP code is the only code in such a platform on cold boot, it is the first code executed on cold boot. No
entity exists before the XiP code’s first execution that can provide measurement or verification (with or without
record).
In SoC design and code execution methodology terms, this TEE variant may be considered identical to that of
an SE, with the only difference being in the runtime environment offered to the applications and thecommunication connection port, so all the SE application RoT material from Chapter 8 equally applies here.
From the point of view of remote management, the RoT service principles are those of the TEE management
system and are described in section 7.2.4.

7.2.1.3

TEE 2 of Figure 7-3: TEE RTE Software Loaded through TEE Secure Boot

From the point of view of “trust”, the exact time the GlobalPlatform compliant part of the TEE RTE is loaded
makes little difference.
What is critical is that:• The first code executed on the TEE platform is the first stage of a Chain of Trust that can be shown tovalidate that the TEE RTE is the intended and correct code to provide the RTE.
• The first stage of the boot chain is intrinsically trusted.
o As the intrinsically trusted first stage in a boot chain, the use of On-SoC ROM prevents interferencewith the code reaching the computing engine of the TEE.
• Any additional stages in a boot chain sequence must be validated before execution.
o These form Extended Enhanced RoT if no record of validation is available and if additional service
or a modification of the service is provided by these stages.
o These may form security service extensions to a RoT, if a record of validation is available from that
RoT.
Because they may be either service extensions or RoTs, they will be referred to below as “Boot Phases”.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

50 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

Boot Phase Services
Each phase of a TEE secure boot chain must provide the following services to the next phase. These primitives
are not necessarily exposed as services to other code, but are useful to consider in terms of explaining thefunctionality of each phase. Only for the iRoT must these be RoT Security Services rather than service
extensions.
The following sections describe how the Root of Trust in the TEE implements the services associated with
TEE secure boot. The services are not exposed as explicit services, but are integrated into the functionality
offered by the boot phases.
• Confidentiality serviceo Each boot phase will use a confidentiality service rooted in a RoT for Confidentiality in which it
stores the secret materials used by the following phase, but prevents access to secrets which later
phases are not authorized to access.
For example, TEEs typically use a hardware unique key (HUK) to device bind and protect
non-volatile data. This may have been derived from a common “root” HUK from which other device
secrets are derived. It is essential that the root HUK is not exposed to unauthorized entities as thismay enable them to derive the HUKs of other entities.
• Identification serviceo Each boot phase must contribute to a RoT for identification that will be exposed through theTrusted OS when the system is in its run time state.
How a boot phase contributes is implementation dependent. This material is used to generate the

gpd.tee.firmware.* TEE property set to uniquely identify the boot code used to establish the
TEE RTE.
For example:• A boot phase may provide a temporary service to the next layer to pass on the identity ofthe parent RoT.
or:
• A boot phase may provide some information through the platform software build system,
which is only available to the TEE RTE. Such information will therefore not be available
unless the authentication process has validated boot phases to a point to instigate theTEE RTE.
• Verification Serviceo Each boot phase must use a service to validate the code and data that is rooted in a RoT for
Verification to instigate the following phase.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

51 / 74• Reporting and Identification Serviceo Only the final RoT will expose a reporting service through the TEE RTE.
o This service will allow discovery of identification of the platform capabilities including security
services, along with the unique version relating to the separate elements of the boot chain that leadto the availability of this service.
o Typically the reporting will take the form of validated information rather than the digest material ofthe validation itself.
For example:• It will report the version of the boot phases rather than hashes of those boot phases.
• See the gpd.tee.firmware.* TEE property set.
• It will report the version of the TEE RTE rather than hashes of that code.
• See the gpd.tee.trustedos.* TEE property set.
• It will report the availability of applications by responding to access requests for those
applications (rather than by returning the hashes of those applications).
• See TEE Client API Specification ([TEE Client]).
Each phase of a TEE secure boot chain MAY provide the following service:• Update Serviceo This may enable the boot phase to update itself.
 Updates are authorized against key materials held by the boot phase.
o This may enable the boot phase to install later boot phases when it finds those phases are
currently invalid or unavailable.
o This may allow a boot phase to update its authorizations such that a change of ownership has
occurred and it may then allow different owners to present later boot phases.
 This would be done be updating signature validation material held by the boot phase being
updated.
Note: Code in the TEE RTE or the TEE boot phases may not be updated without reapplying forcompliance and certification. Such updates are normally only done to add additional compliant
functionality. For example, as no hardware changes may be required, a TEE RTE may be updated to
add support for GlobalPlatform TEE Sockets API ([TEE Sockets]) even though it was originally released
without this functionality.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

52 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.2.2

Boot of TEE RTE

A TEE using XiP in ROM and FLASH is identical to an SE and so inherits the same RoT principles as an SE(see Chapter 8).
The following principles only apply to a TEE that boots by loading code from non-volatile storage to be
executed in RAM.
iRoT Initialization
The Initial Root of Trust is a computing engine, code, (optionally) keys to validate later boot phases,(optionally) keys to validate remote entities, and (optionally) chip-unique root secrets, that shall be
installed with all its static data configured, during the manufacturing process.
Manufacturing Process
The manufacturing process shall be protected with the necessary material to protect the chip design,code, and keys during the fabrication.
Example: The TEE RTE code signing private key is stored in an HSM and it is not possible tocopy or replace the private key during or after the manufacturing process.
TEE RTETEE RTE shall boot through a chain of RoT verifications originating in a TEE based pRoT. These RoTs
will provide the services listed in the following principles.
Code Used During the Boot Phases
Each boot phase shall provide a verification service 2 and an authorization service through which it shallperform verification and authorization checking of the next phase code. If verification and authorization
is successful, the current boot phase shall allow the execution of the next phase code.
That is, to start a following boot phase, that boot phase will require various code to execute. The
instigating phase must verify the integrity and authenticity of that code and also check that it has
been authorized (typically by comparing that code’s cryptographic signature against keys held in
the current module).
Data Used During Boot Phase Initialization
Each boot phase shall provide a verification service2 and an authorization service through which it shallperform verification and authorization checking of the next phase initialization data before moving to thatnext phase.
That is, to start a following boot phase, that boot phase will require various material. The instigatingphase must verify the integrity and authenticity of that material.
Data in this case includes keys, digests, hashes, checksums, etc. – that is, all material that is not
code.

2

If the previous phase doesn’t provide measurement, this phase will be a RoT for Verification.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

53 / 74

Failure of Verification or Authorization of Next Boot Phase Material
If that verification or authorization of material for the next boot phase fails, the platform SHALL go intoa mode that does not offer TEE services from that following phase.
If the verification or authorization checks fail, the current boot phase may still offer services from itself
and previous phases, and may seek alternate fallback boot phases (that must themselves be correctly
verified) if the initial boot sequence has failed.
Data Used During Boot Phase but Not During Initialization
Each boot phase may instigate a verification service 3 and authorization service through which it may
perform verification or authorization checking of data before use.
Once a boot phase has started it fetches further materials to enable services it offers. That material
may be verified and/or checked for authorization before use.
Boot Phase and Confidentiality Service
Each boot phase shall provide a confidentiality service3 for secret data provided by itself or its parents
and used in the following phases.
Boot Phase and Identification
Each boot phase shall provide (directly or implicitly) an information service3 for identification of theoverall boot material.
RoT and Update
Any RoT in the boot chain may offer RoT Security Service for Update.

3

If the previous phase doesn’t provide measurement, this phase will be a RoT for Verification.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

54 / 74

7.2.3

Root of Trust Definitions and Requirements – Public Release v1.0.1#2 RoT Security Services Offered to a Trusted Application on the TEE
Platform

A TEE that has booted its RTE will offer Roots of Trust services to other software on the device. These services
may be offered from Initial or Extended Enhanced Roots of Trust depending on how the TEE was implemented(see section 7.2.1).
That “other software” may be resident in the REE, or may be Trusted Applications, drivers, etc., executing in
the TEE itself.
The TEE RTE is only required to offer fully GlobalPlatform-compliant services once the whole system hasreached its run time state (see [TEE Sys Arch]); however, subsets of these services and proprietary services
may be offered before that point in the device boot cycle.
The following services are not exposed as explicit services, but are integrated into the functionality offered by
the Trusted OS.

7.2.3.1

Authentication Service

The TEE RTE offers limited levels of authentication guarantee of the software entity communicating to the TAfrom the REE.
The TEE RTE offers authentication guarantee of the software entity communicating to the TA from the same
TEE.
In addition, where the appropriate GlobalPlatform API specifications have been implemented, a TA may use
the TEE to hold key material in shielded locations for the purpose of authentication. This material, in
combination with security protocols provided by the TEE RTE, may be used to authenticate software entities
on other platforms.
• TLS protocols are available to authenticate entities available over TCP/IP and UDP/IP.
• GlobalPlatform SCP protocols are available to authenticate entities in Secure Elements connected tothe device and linked to the TEE.

7.2.3.2

Confidentiality Service

The Confidentiality Service maintains shielded locations in volatile and non-volatile memory. The protection of
the shielded locations is vendor-implementation-specific. Confidentiality and access control are provided
through isolation of the applications in the runtime environment. For example:• The firewall of the TEE RTE prevents one TA from accessing objects of another TA.
• The firewall of the TEE RTE prevents anything outside the TEE from accessing assets inside the TEE,
and the firewalls managed by the Trusted OS prevent one TA from accessing objects that are assetsof another TA.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.2.3.3

55 / 74

Identification Service

The Identification Service maintains a shielded location that prevents modification.
This service provides a set of device specific certificates that may be verified by an off-card entitycommunicating with the TA.
It is exposed through the GlobalPlatform TEE properties:

gpd.tee.trustedos.implementation.binaryversion
gpd.tee.firmware.implementation.binaryversion
In addition, the Root of Trust for Identification maintains the integrity of a platform-unique ID number(gpd.tee.deviceID). This ID number provides an index that may be used by a remote entity to retrievematerial to enable a per platform secure channel or other similar relationships to be established.

7.2.3.4

Authorization Service

In the TEE, there may be multiple Trusted Applications, each one with its own keys and data. As a generalrule, the Trusted OS imposes that a Trusted Application can only access its own stored keys and data and not
those of another application. Access to stored Trusted Application keys and data is hence subject toauthorization in that only the owning application can access the data.
In addition, there are authorization rules regarding the interaction of different instances of the same application
to stored application keys and data.
The Authorization Service maintains a shielded location to store the rules regarding access to the restrictedfeature as described above. It guarantees that the rules cannot be changed without authorization and verifies
that the rule is applied when an application tries to access a restricted resource.

7.2.3.5

Verification Service

All items extracted from Trusted Storage are verified upon extraction.
All TA code and data (including keys) are stored in Trusted Storage while not in use.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

56 / 74

7.2.4

Root of Trust Definitions and Requirements – Public Release v1.0.1#3 RoT Security Services Offered to Remote Entities by the TEE Platform

A TEE provides a remotely managed environment to control the resident TAs. While [TMF] is still in draft, thefunctionality requirements of such a system have been agreed upon and are reflected here.
The remote management entity (TAM or TSM) acts through local endpoints in the TEE platform called Security
Domains.
Each Security Domain has an assigned owner.
• Commands from that owner are authenticated, validated (and optionally decrypted) against keys
installed in the SD.
• Replies to those commands are signed (and optionally encrypted) by keys held in the SD.
There are three general sets of operations that may be available to an SD if it has the appropriate rights.
• The SD may store secrets (data or keys) in itself or a child SD or TA.
• The SD may install, remove, or update a child TA code or SD presence.
• The SD may perform certain TEE management operations.
Only correctly authorized and authenticated remote entities may perform particular management operations.
Those operations are further restricted by a permission hierarchy structure; e.g. an SD that cannot perform
TEE management operations cannot create another SD that can perform TEE management operations.
From the external view of a managing remote entity (such as a management server), a TEE platform appears
as one of two classes of management nodes.
• The first class is known as a root SD (rSD).
o A root SD has no entity that can perform SD or TA management operations on it or its children is adomain that restricts the operations necessary for the management of TEE services (creation,
update, blocking, removal, etc.) mainly to its owner remote entity and to any remote entity
responsible for one of the root SD’s ordinary sub-domains.
o A TEE may have many rSDs and they do not all have to be installed in the factory.
• The second class is an ordinary SD.
o This has a hierarchy of parent SDs that may potentially perform management operations on it or its
children.
o An ordinary SD can have another SD as its parent and they may be installed in the factory.
Note: This structure is NOT identical to that found in an SE but is very similar in many aspects.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

57 / 74

The following diagram shows an example of management hierarchy in a TEE.
Figure 7-4: One Example of Security Domain Structure
TA-211

TA-212

TA-x

SD-21

TMF
InstalledandManaged

SD-22

rSD-2

SD-x

TA-112
rSD-x

Trusted Application – a GP
compliant TEE Application
Security Domain – a GP
compliant domain which may
have a set of management
abilities
Root Security Domain – a GP
compliant domain over which
other domains have strictly
limited management abilities

TA-111

TA-11

SD-11

rSD-1

Factory
Installed
and TMF
ManagedGeneral management control
Strictly limited management
Factory installed
In-Field installed

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

58 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.2.4.1

RoT Principles of TEE Management Framework (TMF) Services of a TEE RTE

Because the [TMF] requirements are currently a toolbox of operations, with no particular operations required
to be supported by a particular TEE, only the authentication and identification services are mandatory for a
TMF-supporting TEE to implement. All the other services are optional depending on the TMF operations the
TEE supports.
The following services are not exposed as explicit services, but are integrated into the functionality offered by
the TEE TMF software or equivalent TEE OTA management software.
Identification Service
A TEE RTE providing TMF facilities shall offer a RoT for Information to external parties. Using the TMF
mechanism, this shall may also be available through unsecured enquiry to an SD.
A remote entity may enquire of, or otherwise apply (for example, as a constraint), the TEE platform
identity (gpd.tee.deviceID) such that it can then use platform-specific management keys tocommunicate to the platform.
Reporting Service
A TEE RTE providing TMF facilities may offer a RoT for Reporting to external parties. If available throughthe TMF mechanism, this shall be available through an SD.
A remote entity can use the TEE Audit operations to discover the available capabilities of a TEE.
If this is done through a TMF security layer then the capability statement will be signed by the
security layer key material.
Authentication Service
A TEE RTE providing TMF facilities shall offer services based on a RoT for Authentication to TMF
commands from third parties. Using the TMF mechanism this shall be available through an SD.
All SD commands to the TMF shall be validated as to their authorization. This requires authenticating
their relationship with the Security Domain, and also examining may extend to allowing the rights of the
Security Domain to be examined through TMF interfaces.
Update Service
A TEE RTE providing TMF facilities may offer update services. If available through the TMF mechanism,
this may be available through a correctly privileged SD.
The update service allows an authenticated and authorized SD command to update key material,
code, and data stored in shielded locations.
Confidentiality Service
A TEE RTE providing TMF facilities shall provide service based on a RoT for Confidentiality to SDs, toprovide the SD guaranteed confidentiality in data it stores and transmits.
The confidentiality service maintains shielded locations for the purpose of storing secret criticalsecurity parameters, such as symmetric keys and private asymmetric keys.
Integrity Service
A TEE RTE providing TMF facilities shall provide service based on a RoT for Integrity to SDs, to enable
the SD to guarantee integrity in code and data it stores.
The Integrity Service maintains shielded locations for the purpose of storing and protecting the
integrity of non-secret code and data.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

7.2.5

59 / 74#4 RoT Capabilities that Applications in the TEE Platform May Offer to Other
Platforms

A Trusted Application or RTE service in a TEE may offer facilities to other platforms to enable their RoTs orother functionality.
For example: A TA may provide the functionality of a TCG TPM. That functionality might be usedby the REE in concert with a computing engine and boot code to create a RoT for the REE
platform.
There are no specific RoT principles for this section as these will depend on the component being offered by
the TEE.
• GlobalPlatform TEEs offer no specific RoT Security Services to other platforms.
• GlobalPlatform TEEs enable writers to create TAs and those may offer a range of RoT Security
Services as seen fit by the TA creator.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

60 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

8

Detailed Secure Element Use Case for Root of Trust

8.1

Factory Creation, Installation, and Life Cycle of Secure Element

This section describes events in the Secure Element creation.
This section was extracted from the [Security IC Platform] document.
Figure 8-1: Secure Element Life Cycle

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

61 / 74

Table 8-1: Life Cycle of SE
PhasesActorsPhase 1The Security IC (or SE) Embedded Software Developer is in charge of• The Security IC (or SE) embedded software development and• The specification of IC (or SE) pre-personalization requirements, though the actual
data for IC (or SE) pre-personalization come from Phase 6 (or Phase 4 or 5).

Phase 2The IC (or SE) Designer• Designs the IC (or SE),• Develops IC (or SE) Dedicated Software,• Provides information, software and tools to the Security IC (or SE) Embedded
Software Developer, and• Receives the Security IC (or SE) embedded software from the developer, throughtrusted delivery and verification procedures.
From the IC (or SE) design, IC (or SE) Dedicated Software and Security IC (or SE)
Embedded Software, the IC Designer• Constructs the Security IC (or SE) database, necessary for the IC (or SE) photomask
fabrication.

Phase 3The IC Manufacturer is responsible for• Producing the IC (or SE) through three main steps: IC (or SE) manufacturing, IC (orSE) testing, and IC (or SE) pre-personalization.
The IC (or SE) Mask Manufacturer• Generates the photomasks for the IC (or SE) manufacturing based upon an output
from the Security IC (or SE) database.

Phase 4The IC (or SE) Packaging Manufacturer is responsible for• The IC (or SE) packaging and testing.

Phase 5The Composite Product Manufacturer is responsible for• The Security IC (or SE) product finishing process and testing.

Phase 6

The Personalizer is responsible for• The Security IC (or SE) personalization and final tests.

Phase 7The Security IC (or SE) Issuer is responsible for• The Security IC (or SE) product delivery to the Security IC (or SE) consumer, and theend of life process.

If the TOE comprises programmable non-volatile memory, the Security IC (or SE) Embedded Software may
be loaded onto the chip in phase 3, 4, 5 or 6.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

62 / 74

8.2

Root of Trust Definitions and Requirements – Public Release v1.0.1

Root of Trust and Secure Element

The Secure Element as a removable form factor like the UICC technically enforces the business relationshipbetween the end user of the mobile device and the telecom network provider. This is done independently ofthe mobile device. In this context, it serves as a true root of trust both for the telecom network provider and forthe end user of the mobile device and does not require RoT Security Services provided by the mobile device.
This modus operandi can be extended to additional secure elements with the same form factor or in the formof a microSD.
On the one hand, third parties such as banks, public transport operators, and government agencies canprovide these secure elements and use the root of trust that they own on them for applications such as homebanking, ticketing, or subscription for public transport or in a legal/administration ecosystem. On the other
hand, the telecom network provider that owns the root of trust of the UICC can offer to serve as root of trust
on behalf of third parties that wish to deploy applications on this UICC. The SE owner does this by the
installation of an SSD, the writing of its secure channel keys set, and the extradition of the SSD [GPCS]. The
stakeholders (SE owner and third party) rely on the SE Initial Root of Trust for authorization and confidentiality
in these operations. Moreover, the confidentiality of the key set of the SE owner (in the ISD) is a condition for
ensuring the confidentiality of the key set of the third party. The SSD is part of a Chain of Trust by extending
the security services.
An SE can also be used in a stand-alone fashion as a banking card, ID card, public transport card, or accesstoken. In that case, it does not serve as a root of trust for a mobile device but rather in the context of applications
that involve a terminal or external “reader” such as a payment terminal, ATM, or access gate.
Figure 8-2: Secure Element Architecture Diagram

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

63 / 74

We start with a short summary of the main components of the GlobalPlatform SE chip architecture:• System code (or Smart Card Base Firmware) and secure hardware: The system code is the part ofthe code that corresponds to the lower layer services such as memory management, access to(communication) peripherals, etc. It contributes to the security of the product by providing amechanism to verify continuously that the code is executing correctly and to confirm the integrity of theparameters, data, and keys being used or processed. If an anomaly is detected, this layer takes
appropriate action (e.g. aborting execution and becoming mute or incrementing some ratification
counter). In providing these security services, the system code makes use of hardware dedicated tosecurity (e.g. Active Shield, monitoring of environmental parameters, protection against faults,
memory scrambling, or runtime execution environment monitoring).
• GlobalPlatform Environment (OPEN):o Performs application loading and related Card Content management.
o Manages the installation of applications loaded to the card.
o Dispatches APDU commands to the currently selected application, and sets the applicationreferenced in the SELECT command to be the selected application.
o Manages the internal registry as an information resource. This registry contains information for
managing the Card Executable Load Files, applications, and Security Domain associations andprivileges.
• Run Time Environment (RTE): Java Card Runtime Environment (JCRE) or MULTOS. The Run Time
Environment is responsible for providing firewalls between all applications installed on the SE,
implying that an application can by default access only its own data and keys. There are mechanisms
to enable an application to make use of services offered by another application of the platform, but thisis governed by the OPEN and subject to authorization.
• Secure channel protocol combining dedicated code and the associated key set. It provides
cryptographic services such as command authorization and authentication, response authentication,and both command and response encryption, with a dedicated mechanism (and key) for key
encryption.
• Issuer Security Domain (ISD) has its Secure Channel Protocol available. The ISD is present on the SE
since the beginning of its “life”. It also has a command set allowing it to manage its data and to load
and install other SDs or applications.
• Supplementary Security Domain (SSD) has its Secure Channel Protocol. The SSD and its initial
Secure Channel key set are installed secured by the Secure Channel Protocol and with the ISD
Secure Channel key set. After personalization, it relies on its own Secure Channel key set for
installing the remainder of its data. This may include rolling its Secure Channel key set to another one.
Its functionality is similar to that of the ISD but it has a different owner and somewhat lesser privileges.
• Cardholder Verification Method (CVM) application (called Global PIN if there is exactly one)

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

64 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

The components listed above contain the code and hardware mechanisms which the SE utilizes to provide
RoT Security Services; the following sections describe and provide examples of these services. [TEE PP] (butnot GlobalPlatform specifications) requires that the code in this set of components meets immutability
requirements, which in turn meet the immutability requirement for Roots of Trust. The data and key set
associated with the ISD and the CASD are mutable under authorization (except their identifications) and they
are set during the manufacturing process.
• The SSD is in the immutable memory and is set during the manufacturing process. The key sets anddata of the SSDs are in the mutable memory and they are provisioned after the manufacturing
process. For this reason, SSDs are not included as Roots of Trust for SE. However, through theproper verification of this code, including runtime verification, one can consider them to be in a Chainof Trust.
• Additionally, applet owners can load applets after the manufacturing process by using the security
service delivered by the Security Domain.
The Initial Root of Trust in an SE is composed of a subset of the following components:• System code and Secure Element hardware protection• OPEN• Runtime Environment• ISD + Secure Channel Protocol + related data (data + keys set)
The Initial Root of Trust implements the following security services:• Authentication Service• Confidentiality Service• Identification Service• Authorization Service• Reporting Service• Update Service• Verification Service
The following sections describe how the Initial Root of Trust in the Secure Element implements the services.
The security services described in this section are provided only by the GlobalPlatform Card Specification.
This section does not cover additional security services or service adaptations provided by anapplication/applet (Validated Module) running on the platform.
All the code in the Secure Element that composes the iRoT is in an immutable memory. The data (includingkeys) associated with the iRoT may be updated under authorization. Each Security Domain (after extradition)
has its own key set but the code that implements the Secure Channel is shared between all Security Domains.
The Secure Channel makes use of several keys for several purposes (S-ENC, S-MAC, DEK).
Requirement 8-1: SE Tamper Resistant
The SE SHALL provide a shielded location. This shielded location SHALL be tamper resistant. The
implementation is a combination of hardware and software and its implementation is vendor specific.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

8.3
8.3.1

65 / 74

Authentication Service
Cardholder Verification Method

The Authentication Service maintains at least one shielded location to be used to protect the reference PIN(CVM or global PIN) to be used for end-user authentication. The Authentication Service maintains an interface
to the CVM application that:• Maintains the integrity of the CVM management data, including the PIN value.
• Protects the PIN value against dictionary attacks.
• Protects the PIN value against disclosure.
• Restricts its use for user authentication only.

8.3.2

Secure Channel Protocol

The Authentication Service maintains a shielded location to be used to protect the key set used for the Secure
Channel Protocol for on-card and off-card authentication. The Root of Trust for Authentication maintains aninterface to the Secure Channel Protocol that:• Maintains the integrity of the key set (S-MAC key used to generate the Secure Channel C-MAC
sessions key).
• Protects the key values against several types of attack (fault injection, simple and differential power
analysis, etc.).
• Protects the key values against disclosure.
• Restricts the use of each key only to applications that have the right to access it.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

66 / 74

8.4
8.4.1

Root of Trust Definitions and Requirements – Public Release v1.0.1

Confidentiality Service
Application Firewall

The Confidentiality Service maintains shielded locations in non-volatile memory. The protection of the shielded
locations is vendor-implementation-specific. Confidentiality and access control are provided through isolationof the applications in the runtime environment. For example, the firewall of the JCRE prevents each applicationfrom accessing objects of another application.

8.4.2

Secure Channel Protocol

The Confidentiality Service maintains a shielded location for protecting the key set used for the Secure Channel
Protocol for on-card and off-card encryption/decryption. The Root of Trust for Confidentiality maintains aninterface to the Secure Channel Protocol that:• Maintains the integrity of the key set (S-ENC key used to generate the Secure Channel encryption
session key and the DEK key used to generate the Secure Channel data encryption session key).
• Protects the key values against several types of attacks (fault injection, simple and differential power
analysis, etc.).
• Protects the key values against disclosure.
• Restricts the use of each key to only the applications that have the right to access it.
When a cryptographic key must be transferred from an off-card entity to an SE, the key owner (SE owner or
third party with an SSD on the SE) can rely on the Root of Trust for Confidentiality to protect and use the
Secure Channel Protocol in an authorized fashion, ensuring authorization and integrity by means of encryption
and MAC, to securely transfer and store the value in a shielded location maintained by the Root of Trust ofConfidentiality. The Root of Trust for Confidentiality maintains an interface for secure channel protocols tostore the secure channel keys of an SD that it uses to perform command and response authentication andencryption.

8.5

Identification Service

The Identification Service maintains a shielded location as non-volatile memory. This service provides asignature (a MAC called R-MAC) that may be verified by an off-card entity. The signature is computed over
specific data requested by the off-card entity with the key set value of the owner of the Root of Trust or a third
party with an SSD on the SE.
The Root of Trust for Identification maintains the integrity of an ID number, storing it in a shielded location andpreventing any modification. This ID number is used as common practice to have a unique secret key per chip.
This value is used by the off-card entity to find the key set corresponding to a dedicated Secure Element in its
HSM. The applications running in the Run Time Environment cannot access this ID number.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

8.6

67 / 74

Authorization Service

In the SE there are multiple applications (applet instances), each one with its own keys and data. As a generalrule, the OPEN and RTE impose that an application can only access its own keys and data and not those ofanother application. Access to application keys and data is hence subject to authorization in that only theowning application can access the data. There are some exceptions to this.
The first exception is the GlobalPlatform API. It allows applications to make use of services such as:• Cardholder verification using the SE unique PIN• Secure Channel services, offered by the SD associated with the application• Card locking and termination• Contactless parameters (OPEN authorizes only the application with the self-contactless privilege tomodify the RF parameter as it may affect the other application)
The OPEN and RTE impose that access to these services (and their underlying resources such as the PIN
and the secure channel keys) pass via this API, so this authorization is checking. Moreover, for certain
services, the application must have certain privileges (e.g. the right to lock the card) that are maintained by
the OPEN and RTE and are attributed when the application is installed by means of a Security Domain. Whenmaking use of the API, the OPEN and RTE will verify that the application has the corresponding privilege,
which is also part of authorization. Moreover, the application will not be able to decipher the enciphered key
value in a PUT KEY command if there is no secure channel session going on AND the PUT KEY command
had no valid MAC.
The second exception is the mechanism of shareable interface. This is a mechanism defined at the Java Cardlevel and strictly speaking not a GlobalPlatform concept. However, the GlobalPlatform specifications use it, forinstance for the interface to the PIN object (CVM). The shareable interface is a method for an application toaccess services offered by another application. An applet provider can make use of the shareable interface
concept to support offering services to other applications. The OPEN + RTE will impose that access to suchservices (and their underlying resources) pass via the shareable interface, so this is authorization. A typicalexample of such a service is a stored value balance (electronic value) that may be debited or credited via
different protocols, supported by different applications, but that must be common.
The Authorization Service maintains a shielded location to store the rules regarding access to the restrictedfeature as described above. It guarantees that rules for the access control of specified resources cannot bechanged without authorization and verifies that the appropriate rule is followed before granting an application
access to a restricted resource.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

68 / 74

8.7

Root of Trust Definitions and Requirements – Public Release v1.0.1

Reporting Service

The Reporting Service maintains a shielded location to protect the key set used for the Secure Channel
Protocol between card and issuer (or third party) that provided a signature. The Root of Trust for Reporting
maintains an interface to the Secure Channel Protocol that:• Maintains the integrity of the key set (S-MAC key used to generate the Secure Channel R-MAC
session key).
• Protects the key values against several types of attacks (fault injection, simple or differential power
analysis, etc.).
• Protects the key value against disclosure.
• Restricts use of each key to only the applications that have the right to access it.
• Limits use of keys to only those suitable for reporting which are available to the using application.
In addition to maintaining the shielded location, the Reporting Service provides a mechanism to sign data. The
Issuer Security Domain provides access to its non-secret data and to some information from the internalregistry. With the Secure Channel Protocol (with the R-MAC key), it can sign the response that it provides.

8.8

Update Service

The Update Service provides a mechanism to update the contents of the shielded location where a key set isstored. This mechanism may be performed only under an authorization. The authorization is provided by acorrect signature (MAC).
This mechanism is used when rolling the Secure Channel Keys in an SD when the ownership of the SD istransferred to another party.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

8.9

Verification Service

8.9.1

Loading Information

69 / 74

The Verification Service maintains a shielded location to protect a key set that is used to verify the integrity
and the authenticity of applet code, data, and keys loaded in the Secure Element. This mechanism is provided
by the verification of a MAC with the Secure Channel Protocol of an SD with the key set value that is stored in
the shielded location.
Whenever the Issuer wants to perform an action that changes the configuration, data, or keys of the SE, it
sends a sequence of commands. Such actions include, but are not limited to:• Loading of applet code
• Installation of an application (applet instance)• Writing of a key (put key). This can be a secure channel key, but also an application-level key in an
application.
• Card life cycle state transitions (locking, unlocking, or terminating the SE)• Update of SD data elements such as its ID
For all such actions, the SE imposes authorization by means of a secure channel. The commands will have a
MAC and the RoT for Verification will verify the MAC before performing the action.

8.9.2

Runtime Verification

The Verification Service provides a mechanism to verify continuously that code is executing correctly and to
confirm the integrity of the parameters, data, and keys being used or processed. This is done by a combinationof hardware mechanisms (e.g. redundancy in storage, fault detectors, or duplication of execution) and systemcode including software mechanisms such as repeated execution, etc. As soon as the SE detects an anomaly,
it takes appropriate action, such as aborting execution and becoming mute or incrementing some ratification
counter. This is not specified in the GlobalPlatform specifications, but may be imposed in Common Criteria
documents such as Protection Profiles and specified in Security Targets.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

70 / 74

9

Root of Trust Definitions and Requirements – Public Release v1.0.1

Multi-Platform Use Cases for RoTs

A device such as a mobile phone might host several platforms that can provide security services from one toanother and vice versa. The implementation of the RoTs and the Security Services provided to anotherplatform are implementation dependent.
The following diagram shows an example of a Mobile environment that measured its boot phase and stored
the measurements into a TPM component. When the OS started, the boot phase was measured by its
platform’s pRoT (1). The OS can use the RoT for Verification from the TPM platform that acts as an sRoT for
the OS (2). In this environment, a TEE is also present and some TA applications may provide security services
to the OS or to an application running on the OS (3). The TEE platform will be an sRoT for the OS (or theapplication). An SE might be equivalent by providing security services to the OS (4). The SE can also provide
some security services to the TEE and vice versa (5).
Figure 9-1: Example of Multiple RoTs Platform in Device

TEE
Secure Boot(iRoT +
[eRoT])TEE RTE(eRoT)TA(Validated
Module)3

MobileBoot(iRoT)

1

2

Loader(Measured
Module)1

OS + REE(Measured
Module)Application

4

2

TPM
TPM
(iRoT)

5

SD + RTE(iRoT)SE

Applet(Validated
Module)Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

9.1

71 / 74

Contactless Transaction with TEE and SE

This use case describes the RoTs behind the interaction between TEE and SE when a TEE TA is providing
Trusted User Interface (TUI) services to an SE application for acting on a payment transaction.

9.1.1

Preparation

First both run time environments must be made operational after power-up of the device.
See the various chapters for how the SE and TEE environments built their Chains of Trust.
Both the Applet and the TA are validated for Authorization and Integrity during the OTA installation phase by
the pRoT of the relevant platform.
They are also validated for integrity before or during execution. Again, this is performed by the pRoT of theplatform.
They can then be thought of as eRoTs for the services they then may offer.
Both the application and the TA are personalized with material such that they can perform mutual identification(for example, they may be personalized with keys to enable them to bring up an SCP link). Suchpersonalization will be done through the GlobalPlatform Security Domain Management mechanisms in both
environments, and is therefore bound to the RoT services for that mechanism as described in previous
chapters.

9.1.2

Performing a Contactless Transaction

1. An external NFC source causes the NFC controller event, which triggers an REE application.
This start transaction event is received by SE application.
SE establishes secure communication with the NFC external source.
This requires a pRoT in the SE and the External Source.
Those pRoTs must offer authentication services to establish the secure communication link.
2. SE receives transaction details.
3. SE application establishes (via a request through the REE Application) a secure link to the Trusted
Application.
RTEs are providing a number of RoT services to the TA and application at this stage.
The TA and the application are themselves not RoTs, as their presence is vouched for by the SE or
TEE RoT services.
The secure channel is ultimately based on each platform’s RoT, and provides applet and TA endpoint
authentication and confidentiality.
4. SE requests TA to authenticate the end user and confirm the transaction from that end user.
The TA is passing on material based on a number of RoT services to the application at this stage.
End-user authentication and any other services are offered by the TEE to the TA whose installation
is not reportable through a RoT service.
5. SE then passes back a reply to the external NFC source.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

72 / 74

Root of Trust Definitions and Requirements – Public Release v1.0.1

The following figure illustrates the transaction described above.
Figure 9-2: Contactless Transaction with TEE and SE

TEE
Secure Boot(iRoT +
[eRoT])TEE RTE(eRoT)TA(Validated
Module)4

Material

MobileBoot

OS + REE

Application

34SE
SD + RTE(iRoT)

Applet(Validated
Module)25Material

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

Root of Trust Definitions and Requirements – Public Release v1.0.1

9.2

73 / 74

An REE Interacting with a TPM on TEE or SE

This section does not go into depth, as it is assumed that the reader understands the methods by which an
REE may make use of a TPM, and the white paper mentioned below explains how a TEE can host a TPM.
In the case of an SE, the same paper can be considered, but with TEE replaced by SE, and Trusted Application
replaced by SE application.
For a description of this use case, see the [TCG Whitepaper].
If a TPM is instantiated as a TA or Applet, then that TPM will be a Validated Module.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

74 / 74

Annex A

Root of Trust Definitions and Requirements – Public Release v1.0.1

Detailed HSM Use Cases for Roots of Trust

As explained in Requirement 6-1, GlobalPlatform Secure Components are required to protect the keys andtheir injection during the manufacturing process. A common practice is to use a Hardware Security Module(HSM) to protect the keys. HSMs are dedicated systems that physically and logically secure cryptographic
keys and cryptographic processing.
Functions supported by HSMs include:• Life cycle management of cryptographic keys used to lock and unlock access to digitized information.
Remember that the privacy strength of encrypted information is determined by the sophistication of
the encryption algorithm and the security of the cryptographic keys. The most sophisticated encryption
algorithm is compromised by weak cryptographic key security. Life cycle management ofcryptographic keys includes generation, distribution, rotation, storage, termination, and archival.
• Cryptographic processing, which produces the dual benefits of isolating and offloading cryptographic
processing from application servers.
In use since the early 1990s, HSMs are available in two forms:• Standalone network-attached appliances• Hardware cards that plug into existing network-attached systems
HSMs are fully contained solutions for generation of high quality random data, cryptographic processing, key
generation, and key storage. As purpose-built appliances, they automatically include the hardware andfirmware necessary for these functions in an integrated package. Physical and logical protection of theappliance is supported by a tamper resistant/evident shell; and protection from logical threats, depending on
the vendor’s products, is supported by integrated firewall and intrusion prevention defenses. Some HSM
vendors also include integrated support for two-factor authentication. Security certification is typically pursued
by HSM vendors and positioned as a product feature.
Cryptography is a resource intensive process that will introduce latency to any application that depends on it.
Depending on the application involved and the organization, an objective could be to minimize the latency
introduced by cryptography. HSMs have an advantage over software, as they are designed to optimize theefficiency of cryptographic processing. Compared to software running on general purpose servers, HSMs will
typically accelerate security-critical cryptographic processing; an outcome of being purpose-built.

Copyright  2014-2017 GlobalPlatform, Inc. All Rights Reserved.
The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information isgoverned by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.