CC Huawei iTrustee Software V5.0
Security Target
Issue 1.6
Date 2021-07-26
HUAWEI TECHNOLOGIES CO., LTD.
Copyright © Huawei Technologies Co., Ltd.
i
Copyright © Huawei Technologies Co., Ltd. 2021. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer.
All or part of the products, services and features described in this document may not be within the purchase scope or
the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this
document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or
implied.
The information in this document is subject to change without notice. Every effort has been made in the preparation
of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this
document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.
Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
CC Huawei iTrustee Software V5.0 Security Target About This Document
Copyright © Huawei Technologies Co., Ltd.
ii
About This Document
Purpose
This document is the Security Target of the iTrustee software V5.0.
Change History
Changes between document issues are cumulative. The latest document issue contains all the changes made in
earlier issues.
Date Revision Version Section Number Change Description Author
2019.12.05 1.0 ALL Initial Draft
iTrustee Team
Certification Team
French office
2020.02.13 1.1 ALL Review and comments
Certification Team
French office
2020.02.18 1.2 ALL Review and update
iTrustee Team
Certification Team
French office
2020.07.08 1.3 ALL Review and update.
iTrustee Team
Certification Team
French office
2020.11.18 1.4 ALL Review and update.
iTrustee Team
Certification Team
French office
2020.11.25 1.5 ALL Review and update.
iTrustee Team
Certification Team
French office
2021.07.26 1.6 ALL Review and update.
iTrustee Team
Certification Team
French office
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
1
Contents
About This Document....................................................................................................................... ii
1 Introduction.....................................................................................................................................3
1.1 Security Target Identification........................................................................................................................................3
1.2 TOE Identification ........................................................................................................................................................3
1.3 TOE Overview..............................................................................................................................................................4
1.4 TOE Description...........................................................................................................................................................6
1.5 TOE Device Life Cycle ................................................................................................................................................8
2 Conformance Claim......................................................................................................................11
2.1 Conformance Claim.................................................................................................................................................... 11
2.2 PP Claim ..................................................................................................................................................................... 11
3 TOE Security Problem Definition ...............................................................................................14
3.1 Assets..........................................................................................................................................................................14
3.2 Users / Subjects...........................................................................................................................................................15
3.3 Threats ........................................................................................................................................................................15
3.4 OSP.............................................................................................................................................................................18
3.5 Assumptions................................................................................................................................................................18
4 Security Objectives .......................................................................................................................20
4.1 Objectives for the TOE ...............................................................................................................................................20
4.2 Objectives for the Operational Environment ..............................................................................................................22
4.3 Security Objectives Rationale.....................................................................................................................................24
5 Extended Components Definition................................................................................................32
5.1 Extended Family FPT_INI - TSF initialization ..........................................................................................................32
6 Security Requirements .................................................................................................................33
6.1 Conventions................................................................................................................................................................33
6.2 Definitions of security policies ...................................................................................................................................33
6.3 Security Functional Requirements..............................................................................................................................35
6.4 Security Functional Requirements Rationale..............................................................................................................44
6.5 Security Assurance Requirements Rationale ..............................................................................................................50
7 TOE Summary Specification .......................................................................................................52
7.1 Protection of TSF........................................................................................................................................................52
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
2
7.2 Trusted Storage ...........................................................................................................................................................52
7.3 Cryptographic Support................................................................................................................................................53
7.4 User Identification and Authentication .......................................................................................................................53
7.5 Security Audit.............................................................................................................................................................53
7.6 Protection of TA..........................................................................................................................................................54
7.7 Security Instantiation..................................................................................................................................................54
7.8 Reliable time stamps...................................................................................................................................................54
8 Abbreviations, Terminology and References ..............................................................................55
8.1 Abbreviations..............................................................................................................................................................55
8.2 Terminology................................................................................................................................................................56
8.3 References ..................................................................................................................................................................58
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
3
1 Introduction
This Security Target is for the evaluation of the Huawei iTrustee Operating system, which is a simplified
Real-time Operating System (OS) aiming to provide the Trusted Execution Environment (TEE) on the
Android platform for managing digital copyright and protecting mobile payment and sensitive data. The
TOE version is provided in chapter. 1.2.
1.1 Security Target Identification
Security Target Identification
Document title CC Huawei iTrustee Software V5.0 Security Target
Document reference iTrustee_ST_V5
Document version 1.6
Document publication date 2021.07.26
Document author Huawei Technologies Co., Ltd
1.2 TOE Identification
TOE Identification
TOE name Huawei iTrustee
Version 5.0
Software binary image 6.1.2
Developer name Huawei Technologies Co., Ltd.
Note that the TOE consists of software only. The SoC is out of the scope of the evaluation.
The following guidance documents must be provided in order to ensure the secure usage of the Huawei
iTrustee V5.0 after delivery.
Reference Document
[AGD_PRE] Huawei iTrustee Software V5.0 Preparative Procedures for User. Version 1.1.
[AGD_OPE] Huawei iTrustee Software V5.0 Operational User Guidance. Version 1.2.
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
4
1.3 TOE Overview
1.3.1 TOE Type
The TOE type is the Trusted OS, which is only the software part of the Trusted Execution Environment
(TEE) defined by [TEE PP]. It is for embedded devices implementing GlobalPlatform TEE
specifications (see TEE System Architecture [SA], TEE Internal API [IAPI] and TEE Client API
[CAPI]). However, this ST does not claim full functional compliance with GlobalPlatform TEE APIs
specifications.
The TOE is an execution environment isolated from any other execution environment, including the
usual Rich Execution Environment (REE), and their applications. The TOE hosts a set of Trusted
Applications (TA) and provides them with a comprehensive set of security services including: integrity
of execution, secure communication with the Client Applications (CA) running in the REE, trusted
storage, key management and cryptographic algorithms, time management and arithmetical API.
1.3.2 TOE Usage
The TOE enables the use of mobile devices for a wide range of services that require security protection,
for instance:
• Corporate services: Enterprise devices that enable push e-mail access and office
applications give employees a flexibility that requires a secure and fast link to their workplace
applications through Virtual Private Networking (VPN), secure storage of their data, and
remote management of the device by the IT department.
• Content management: Today’s devices offer HD video playback and streaming, mobile TV
broadcast reception, and console-quality 3-D games. This functionality often requires content
protection, through Digital Rights Management (DRM) or Conditional Access.
• Personal data protection: Devices store increasing amounts of personal information (such as
contacts, messages, photos and video clips) and even sensitive data (credentials, passwords,
health data, etc.). Secure storage means are required to prevent exposure of this information in
the event of loss, theft, or any other adverse event, such as a malware.
• Connectivity protection: Networking through multiple technologies—such as 3G, 4G or
Wi-Fi/WiMAX, as well as personal communication means, such as Bluetooth® and Near
Field Communication (NFC) — enables the use of mobile devices for peer-to-peer
communication and for accessing the Internet. Such access, including web services or remote
storage relying on cloud computing, typically uses SSL/TLS or IPsec internet secure protocols.
Often the handling of the key material or the client end of the session needs to be secured.
• Mobile financial services: Some types of financial services tend to be targeted at smart
phones, such as mobile banking, mobile money transfer, mobile authentication (e.g. use with
One-Time Password–OTP technology), mobile proximity payments, etc. These services
require secure user authentication and secure transaction, which can be performed by the
device potentially in cooperation with a Secure Element.
We refer to the TEE White Paper [WP] for an overview of the main TEE use cases.
1.3.3 TOE and Non-TOE parts
The TOE comprises:
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
5
• Software used to provide the TEE security functionality
• The guidance for the secure usage of the TOE after delivery.
The TOE does not comprise:
• Hardware and firmware used to provide the TEE security functionality, the secure boot and
AT firmware.
• The Trusted Applications
• The Rich Execution Environment
• The Client Applications.
The TOE can be running on Huawei Mate/P series Mobile Phones, and the necessary Non-TOE
hardware in the mobile phone consists at least the following parts:
• Huawei Kirin series SoC, such as Kirin 990
• RAM, which can be configured as secure memory and non-secure memory
• ROM, which contain sensitive information for secure boot
• Flash memory, where Android OS and iTrustee stored
• Crypto Module, which provides cryptographic mechanisms functions related mainly to key
generation
• Necessary peripherals such as display screen, Power button etc.
The following Non-TOE software is also required:
• Bootloader which its version is 2.0
• Bl31 monitor which its version is 2.1
• EMUI, Huawei customized Android OS, which its version is 10.1
• Device driver for iTrustee in Android
• SDK for Android app to communicate with iTrustee
The TOE enables a wild range of enhanced security services for mobile device, the instances of those
use cases are as below:
• Mobile Payment and banking such as Huawei Pay, IFFA, FIDO etc.,
• Device Protection such as Phone Finding Back, Secboot, File Cabinet and File Encryption,
• System Protection such as kernel integrity checking for Android system,
• Digital Right Management.
In the following, TOE and iTrustee are used interchangeably.
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
6
1.4 TOE Description
1.4.1 Architechure Overview
The TEE is embedded in the device and runs alongside a standard OS or Rich Execution Environment.
Figure 1 provides a high level view of the software components of a TEE-enabled device, independently
of any hardware architecture.
Normal REE
Application(s)
Client
Application(s)
GPD TEE Client API
Rich OS Components
Public Device
Drivers
REE
Communication
Agent
Platform Hardware
Public
Peripherals
Trusted
Application(s)
GPD TEE Internal Core API and other GPD TEE
Internal API specs
iTrustee OS Components
Trusted
Device
Drivers
REE TEE
Trusted Kernel
Shared Trusted Peripherals
Trusted Peripherals
Trusted
Core
Framework
TEE
Communication
Agent
Isolation
defined
by
GPD
TEE
PP
Interface :Runtime
environment for TA
Interface:SMC
Message
ARM Trusted Firmware
tlogcat
Trustzone Internal
Hardware Interface
Figure 1: The architecture of a TOE-enabled device
The TEE software architecture identifies two distinct classes of components:
• The Trusted Applications that run on the TEE and use the TEE Internal API
• The Trusted OS Components whose role is to provide communication facilities with the
REE software and the system level functionality required by the Trusted Applications,
accessible from the TEE Internal API
The REE software architecture identifies also two distinct classes of components:
• The Client Applications which make use of the TEE Client API to access the secure
services offered by TAs running on the TEE
• The Rich OS, which provides the TEE Client API and sends requests to the TEE
The TEE software external interface comprises the TEE Internal API (used by the Trusted Applications)
and the TEE Communication Agent protocol (used by the REE).
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
7
The trusted peripherals including timer modules which are provided by the SoC. The TOE acquires
reliable time and RNG from trusted peripherals via the Trustzone internal Hardware interface.
The TOE is composed of four components as below:
iTrustee Component Description
iTrustee Kernel iTrustee Kernel provides task creation, memory management,
IPC etc.
TEE Communication Agent TEE communication Agent will send/receive SMC calls to/from
REE, resolve SMC messages and forward messages to other
components of the TOE.
Trusted Core Framework Trusted Core Framework will manage the tasks already created.
Trusted Device Drivers Trusted Device Drivers will talk to Trusted Peripherals, and
provide trusted functions to the TOE.
Table 1: TOE components
1.4.2 TOE Physical Scope
The TOE consists of the following components:
Title Version Format
iTrustee binary image “sec_trustedcore.img” 6.1.2 img
Huawei iTrustee Software V5.0 Preparative Procedures for User. 1.1 pdf
Huawei iTrustee Software V5.0 Operational User Guidance. 1.2 pdf
Table 2: TOE physical scope
1.4.3 TOE Security Functionality
The TOE security functionality in the end-user phase which is in the scope of the evaluation consists of:
• Protection of TSF Including TSF secure initialization, TSF failure with preservation of
secure state, isolation between REE and TEE, integrity protection of TEE data, and security
management.
• Trusted Storage Providing confidentiality, consistency and integrity protection of TA
data; Binding TA data to the TEE.
• Reliable time stamps Providing reliable, monotonic secure clock whenever TOE falling
into deep sleep or not, and it will be reset if the TOE is restarted.
• User Identification and Authentication Both CAs and TAs should be identified and
authenticated by the TOE before any more actions.
• Security Audit The TOE detect potential security violation such as violation of TA data,
TA code or TEE data, and generate audit log. The log will be sent to REE.
• Protection of TA The TOE provide TA protection during the life cycle from its loading to
exiting. For each TA, the TSF will create an isolated user space, and it can’t be accessed by
other TAs. TAs can access kernel functions only by internal core API, and every time it access
the kernel, the TSF will perform security policy to ensure correct execution.
• Security Instantiation TEE instantiation through a secure initialization process that
ensures the integrity of the TOE internal tasks.
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
8
• Cryptographic Support The TOE provides: (i) cryptographic operations to support
TOE’s security functions as listed in Table 3; (ii) cryptographic key destruction; (iii)
cryptographic operations to TAs via TEE Internal API as listed in [AGD_OPE].
Algorithm
name
Supported Modes
Key sizes
(default bits)
Supported standard
Symmetric
ciphers (AES)
CBC 256
FIPS 197 (AES)
NIST SP800-38A (CBC)
XTS 256
FIPS 197 (AES)
NIST SP800-38E &
IEEE Std 1619-2007 (XTS)
Hash SHA256 -
FIPS 180-4
MAC
HMAC: SHA256
block size
not exceed
64 bytes
FIPS 198-1 & FIPS 180-4
AES-CMAC 256 NIST SP800-38B
ECC ECDH 256 NIST SP 800-56A
RSA
OAEP for encryption
PKCS1_V1.5 for
signature
2048
PKCS #1
Table 3: TOE Cryptographic algorithms supporting TOE’s security functions
The TOE security functionality defines the logical boundary of the TOE. The interfaces of this boundary
are the Software External Interface, introduced in section 1.4.1.
The security functionality provided by the Trusted Applications is out of the scope of the TOE.
1.5 TOE Device Life Cycle
The device life cycle outlined here is an overall life cycle from which implementations can deviate
according to development, manufacturing and assembly processes. It is split in six phases:
• Phase 1 corresponds to the design of firmware, software and hardware; it covers both TEE and
additional components.
• Phase 2 corresponds to the overall design of the hardware platform supporting the TEE.
• Phase 3 corresponds to chipset and other hardware components manufacturing. The root key and
material use to generate TEE identifier are set in this phase.
• Phase 4 covers software integration (linking the TEE software and other software)
• Phase 5 consists of device assembling; it includes any initialization and configuration step necessary to
bring the device to a secure state prior delivery to the end-user. Trusted ROM will be formatted in this
phase.
• Phase 6 stands for the end-usage of the device.
Figure 2 together with Table 4, show the whole life cycle of TEE-enabled device.
As the TOE is only the software part of the TEE defined in [TEE PP], the related life cycle actor is
colored with green in the figure 2.
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
9
Additional ROM/HW
design
Additional SW design (REE)
TEE HW
design
Secure boot/
firmware design
(optional) TEE
initialisation code
TEE FW design
TEE
Non-TEE
phase1
Design
environment
Manufacturing
environment
TEE chipset design
TEE chipset manufacturing
Additional hardware
manufacturing
phase2
phase3
phase4
phase5
phase6
End-User
environment
TEE / REE / Additional software
Linking
Device assembling
Device end-usage
Additional
HW
supporting
the
TEE
TEE SW design
CA design
TA design
Figure 2: Life Cycle of TEE-enabled Device
Phases Actors
1 & 2: Firmware /
Software / Hardware
design
TOE development:
The software developer (iTrustee team) is in charge of:
 Developing TEE software (the TOE) and testing compliant with
GlobalPlatform specifications.
 Specifying TEE software linking requirements.
Non-TOE development:
- The Hardware/firmware designer is in charge of:
 Designing (part of) the processor(s) where the TEE software runs and designing
(part of) the hardware security resources used by the TEE.
 Developing TEE initialization code that instantiates/initializes the TEE (e.g.
part of the secure boot code).
- The software integrator (Terminal Product Line team) may design: (i) additional
REE software that will be linked with the TEE in phase 4 to provide REE controlled
resources; (ii) Trusted Applications that they will be integrated in phase 4 also.
- The software developer (iTrustee team) may design also Trusted Applications that
they will be integrated in phase 4.
- The silicon vendor designs the ROM code and the secure portion of the TEE 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
Hardware/firmware team.
CC Huawei iTrustee Software V5.0 Security Target 1 Introduction
Copyright © Huawei Technologies Co., Ltd.
10
3: TEE
manufacturing
The silicon vendor produces the TEE chipset and enables, sets or seeds the root of trust of the
TEE. The root key and material use to generate TEE identifier are set in this phase.
4: Software
integration
The software integrator (Terminal Product Line team) is responsible for the integration,
validation and preparation of the software to load in the product that will include the iTrustee,
any pre-installed Trusted Application, and additional software required to use the product (e.g.
REE, Client Applications).
5: Device
manufacturing
The device manufacturer is responsible for the device assembling and initialization and any
other operation on the device (including loading or installation of 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.
Table 4: Actors in the Device Life Cycle
The phase related to the iTrustee during the whole device life cycle (mentioned in green in the figure) is
the following:
Phase 1: TEE software design. Developing iTrustee image and delivering it to software integrator.
The point of delivery is at the end of Phase 1. Hence, the TOE operational phase starts effectively in
Phase 4 since Phases 2 and 3 are not part of the TOE delivery process.
The TOE doesn’t provides TA management.
The involved actors and sites are described in the following table.
Actors Identification Covered by
Software developer iTrustee team:
Huawei Beijing Research Institute
Dongguan and Langfang data centers
ALC & site audit
TEE Hardware/Firmware
designer
Huawei Hisilicon Not part of the TOE delivery
process
Silicon vendor TSMC Limited
ASE Technology Co., Ltd
SPIL Co., Ltd
Not part of the TOE delivery
process
Software integrator Terminal Product Line team:
Huawei Mobile Dept- Shanghai, China
AGD
Device manufacturer Huawei Machine Co., Ltd
Shenzhen FuTaiHong Precision Industry Co.,
Ltd
AGD
End user - AGD
CC Huawei iTrustee Software V5.0 Security Target 2 Conformance Claim
Copyright © Huawei Technologies Co., Ltd.
11
2 Conformance Claim
2.1 Conformance Claim
This Security Target claims conformance to Common Criteria version 3.1 revision 5 as follows:
- Part 1 [CC1].
- Part 2 [CC2], extended with FPT_INI.1 as defined in chap.5.
- Part 3 [CC3], more precisely EAL4, augmented with ALC_FLR.1.
2.2 PP Claim
This Security Target is built using items from the BASE-PP of GlobalPlatform Device Committee TEE
Protection Profile Version1.2 [TEE PP], and claims no conformance to this PP.
The TOE defined by this Security Target is the trusted OS, which is one of the components defined by
[TEE PP]. The hardware components defined in [TEE PP] are considered as the environment of the
TOE, thus the corresponding security objectives and SFRs are moved to the TOE environment, and new
assumptions or objectives are added to the operational environment.
The following table shows the SPDs of the [TEE PP] that are applicable to the current ST:
TOE SPDs TEE PP iTrustee Included
Assumptions
A.PROTECTION_AFTER_DELIVERY × ×
A.ROLLBACK × ×
A.TA_DEVELOPMENT × ×
A.INTEGRATION ×
A.SECUREBOOT ×
A.SECURE_HARDWARE/FIRMWARE ×
A.RNG x
Threats
T.ABUSE_FUNCT × ×
T.CLONE × ×
T.FLASH_DUMP × ×
T.IMPERSONATION × ×
T.ROGUE_CODE_EXECUTION × ×
T.PERTURBATION × ×
T.RAM × ×
T.RNG × The RNG is provided
by the SoC.
Considered in A.RNG
and OE.RNG
T.SPY × ×
T.TEE_FIRMWARE_DOWNGRADE × ×
T.STORAGE_CORRUPTION × ×
CC Huawei iTrustee Software V5.0 Security Target 2 Conformance Claim
Copyright © Huawei Technologies Co., Ltd.
12
Organizational Security Policies
OSP.INTEGRATION_CONFIGURATION × ×
OSP.SECRETS × ×
Table 5: TEE PP SPDs vs iTrustee ST
The following table shows the security objectives of the [TEE PP] that are applicable to the current ST:
TOE Objectives TEE
PP
iTrustee Included
Security Objectives for the TOE
O.CA_TA_IDENTIFICATION × ×
O.KEYS_USAGE × ×
O.TEE_ID × Changed into O.TEE_ID
+
OE.INTEGRATION_CONFIGURATION
+
OE.INITIALIZATION
O.INITIALIZATION × Changed into OE.INITIALIZATION
O.INSTANCE_TIME × ×
O.OPERATION × ×
O.RNG × Changed into OE.RNG. The RNG is
provided by SoC
O.RUNTIME_CONFIDENTIALITY × ×
O.RUNTIME_INTEGRITY × ×
O.TA_AUTHENTICITY × ×
O.TA_ISOLATION × ×
O.TEE_DATA_PROTECTION × ×
O.TEE_ISOLATION × ×
O.TRUSTED_STORAGE × ×
O.INI_INTERNAL ×
Security Objectives for the Operational Environment
OE.INTEGRATION_CONFIGURATION × ×
OE.PROTECTION_AFTER_DELIVERY × ×
OE.ROLLBACK × ×
OE.SECRETS × ×
OE.TA_DEVELOPMENT × ×
OE.TRUSTED_HARDWARE ×
OE.RNG ×
OE.INITIALIZATION ×
Table 6: TEE PP Security Objectives vs iTrustee ST
The following table shows the SFRs of the [TEE PP] that are applicable to the iTrustee ST:
SFRs in [TEE PP] iTrustee
Included
Applicable to
Hardware/Firmware
1. Identification
FIA_ATD.1 User attribute definition ×
FIA_UID.2 User identification before any action ×
FIA_USB.1 User-subject binding ×
FMT_SMR.1 Security roles ×
2.Confidentiality, Integrity and Isolation
FDP_IFC.2/Runtime Complete information flow
control
×
FDP_IFF.1/Runtime Simple security attributes ×
FDP_ITT.1/Runtime Basic internal transfer Hardware Only
CC Huawei iTrustee Software V5.0 Security Target 2 Conformance Claim
Copyright © Huawei Technologies Co., Ltd.
13
protection
FDP_RIP.1/Runtime Subset residual information
protection
×
FPT_ITT.1/Runtime Basic internal TSF data transfer
protection
Hardware Only
3.Cryptography
FCS_COP.1 Cryptographic operation ×
FDP_ACC.1/TA_keys Subset access control ×
FDP_ACF.1/TA_keys Security attribute based access
control
×
FMT_MSA.1/TA_keys Management of security
attributes
×
FMT_MSA.3/TA_keys Static attribute initialization ×
4.Initialization, Operation and Firmware Integrity
FAU_ARP.1 Security alarms ×
FDP_SDI.2 Stored data integrity monitoring and
action
×
FPT_FLS.1 Failure with preservation of secure state ×
FPT_INI.1 TSF initialization × SFR modified to cover
only the secure
initialization process
that ensures the
integrity of the TOE’s
internal tasks.
FMT_SMF.1 Specification of Management Functions ×
FPT_TEE.1 Testing of external entities ×
5.TEE Identification
FAU_SAR.1 Audit review ×
FAU_STG.1 Protected audit trail storage ×
6.Instance Time
FPT_STM.1/Instance time Reliable time stamps ×
FCS_RNG.1 Random numbers generation -Hardware Only
7.Trusted Storage
FDP_ACC.1/Trusted Storage Subset access control ×
FDP_ACF.1/Trusted Storage Security attribute based
access control
×
FDP_ROL.1/Trusted Storage Basic rollback ×
FMT_MSA.1/Trusted Storage Management of
security attributes
×
FMT_MSA.3/Trusted Storage Static attribute
initialization
×
FDP_ITT.1/Trusted Storage Basic internal transfer
protection
×
Additional SFRs in this ST
FCS_CKM.4
Table 7: SFRs of the [TEE PP] that are applicable to iTrustee ST
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
14
3 TOE Security Problem Definition
3.1 Assets
This section presents the assets of the TOE and their properties: authenticity, consistency, integrity,
confidentiality, monotonicity, randomness, atomicity, read-only and device binding.
TEE identification
TEE identification data that is globally unique among all GlobalPlatform TEEs whatever the
manufacturer, vendor or integrator. This data is typically stored in the Trusted OTP memory of
the TEE.
Properties: unique and non-modifiable.
Application Note: The TEE identifier is intended to be public and exposed to any software
running on the device, not only to Trusted Applications.
TA code
The code of the installed Trusted Applications. This data is typically stored in external
non-volatile memory shared with REE and potentially accessible by it.
Properties: authenticity and consistency (which implies runtime integrity).
TA data and keys
Data and keys managed and stored by a TA using the TEE security services. Data and keys are
owned either by the user (the owner of the TEE-enabled device) or by the TA service provider.
This data is typically stored in external non-volatile memory shared with REE and potentially
accessible by it.
Properties: authenticity, consistency (which implies runtime integrity), atomicity,
confidentiality and device binding.
TA instance time
Monotonic time during TA instance lifetime. Not affected by transitions through low power
states. Not persistent over TEE reset or TA shut-down.
Properties: monotonicity.
TEE runtime data
Runtime TEE data, including execution variables, runtime context, etc. This data is stored in
volatile memory.
Properties: consistency (or integrity as these notions are equivalent for non-persistent data)
and confidentiality, including random numbers generated by the TEE.
TEE persistent data
TEE persistent data, including TEE cryptographic keys (for instance keys to authenticate TA
code) and TA properties. This data is typically stored in external non-volatile memory shared
with REE and potentially accessible by it.
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
15
Properties: authenticity, consistency (which implies runtime integrity), confidentiality and
device binding.
TEE firmware
The TEE binary, containing TEE code and constant data such as versioning information. This
asset is typically stored in external non-volatile memory shared with REE and potentially
accessible by it.
Properties: authenticity, integrity.
TEE initialization code and data
Initialization code and data (for instance cryptographic certificates) used from iTrustee start-
up to the complete activation of the TEE security services. Authentication of the TEE is part
of its initialization.
Properties: integrity.
TEE storage root of trust
The root of trust of the TEE storage that is used to bind the stored data and keys to the TEE.
Properties: integrity and confidentiality.
3.2 Users / Subjects
There are two kinds of users of the TOE: Trusted Applications, which use the TOE services through the
TEE Internal API, and the Rich Execution Environment (including Client Applications), which uses the
TOE's services exported by the Trusted Applications.
Trusted Application (TA)
All the Trusted Applications running on the TEE are users of the TOE, through the TEE
Internal API.
Rich Execution Environment (REE)
The Rich Execution Environment, hosting the standard OS, the TEE Client API and the Client
Applications (CA) that use the services of the Trusted Applications, is a user of the TOE.
3.3 Threats
This section presents threats by providing the general goal, the assets threatened and in some cases,
typical identification and/or exploitation attack paths. Some of the threats constitute in fact steps of
longer attack paths related for instance to the disclosure or modification of assets. Nevertheless, they are
stated separately to facilitate the tracing of the countermeasures.
T.ABUSE_FUNCT
An attacker accesses TEE functionalities outside of their expected availability range thus
violating irreversible phases of the TEE life cycle or state machine.
An attacker manages to instantiate an illegal TEE or to start-up the TEE in an insecure state or
to enter an insecure state, allowing the attacker to obtain sensitive data or compromise the
TSF (bypass, deactivate or change security services).
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
16
Assets threatened directly: TEE initialization code and data (integrity), TEE runtime data
(confidentiality, integrity), TA code (authenticity, consistency).
Assets threatened indirectly: TA data and keys (confidentiality, authenticity, consistency)
including instance time.
Application Note:
Attack paths may consist, for instance, in using commands in unexpected contexts or with
unexpected parameters, impersonation of authorized entities or exploiting badly implemented
reset functionalities that provides undue privileges.
In particular a fake application running in the Rich OS which masquerades as a security
application running in the TEE can grab PINs and passwords and run the real security
application on behalf of the user. However, such threat is not countered by the TEE alone and
must be taken into account in the design of the use case, for instance by using an applicative
authenticated communication channel between the client and the TA.
T.CLONE
An attacker manages to copy TEE related data of a first device on a second device and makes
this device accept them as genuine data.
Assets threatened directly: All data and keys (authenticity, device-binding), TEE identification
data (authenticity, integrity).
T.FLASH_DUMP
An attacker partially or totally recovers the content of the external Flash in clear text, thus
disclosing sensitive TA and TEE data and potentially allowing the attacker to mount other
attacks.
Assets threatened directly (confidentiality, authenticity, consistency): TA data and keys, TEE
persistent data.
Application Note:
An attack path consists for instance in performing a (partial) memory dump through the REE,
purely via software or with a USB connection.
During identification, another example consists of unsoldering a flash memory and dumping
its content, revealing a secret key that provides privileged access to many devices of the same
model.
T.IMPERSONATION
An attacker impersonates a Trusted Application to gain unauthorized access to the services
and data of another Trusted Application.
Assets threatened directly (confidentiality, integrity): TEE runtime data.
Assets threatened indirectly: All data and keys (confidentiality, authenticity, consistency).
T.ROGUE_CODE_EXECUTION
An attacker imports malicious code into the TEE to disclose or modify sensitive data.
Assets threatened directly (confidentiality, integrity): TEE runtime data.
Assets threatened indirectly (confidentiality, authenticity, consistency): All.
Application Note:
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
17
Import of code within REE is out of control of the TEE.
T.PERTURBATION
An attacker modifies the behavior of the TEE or a TA in order to disclose or modify sensitive
data or to force the TEE or the TA to execute unauthorized services.
Assets threatened directly: TEE initialization code and data (integrity), TEE storage root of
trust (confidentiality, integrity), TEE runtime data (confidentiality, integrity).
Assets threatened indirectly: All data and keys (confidentiality, authenticity, consistency)
including TA instance time.
Application Note:
Unauthorized use of commands (one or many incorrect commands, undefined commands,
hidden commands, invalid command sequence) or buffer overflow attacks (overwriting buffer
content to modify execution contexts or gaining system privileges) are examples of attack
paths. The TEE can also be attacked through REE or TA "programmer errors" that exploit e.g.
multi-threading or context/session management or closed sessions or by triggering system
resets during execution of commands by the TEE.
T.RAM
An attacker partially or totally recovers RAM content, thus disclosing runtime data and
potentially allowing the attacker to interfere with the TEE initialization code and data.
Assets threatened directly: TEE initialization code and data (integrity), TEE storage root of
trust (confidentiality, integrity), TEE runtime data (confidentiality, integrity).
Assets threatened indirectly: All data and keys (confidentiality, authenticity, consistency).
Application Note:
When the REE and the TEE have shared memory, an attack path consists in the (partial)
memory dump (read/write) by the REE. During the identification phase, another example of
attack path is to snoop on a memory bus, revealing code that is only decrypted at run-time,
and finding a flaw in that code that can be exploited.
T.SPY
An attacker discloses confidential data or keys by means of runtime attacks or unauthorized
access to storage locations.
Assets threatened directly (confidentiality): All data and keys, TEE storage root of trust.
Application Note:
Exploitation of side-channels by a CA or TA (e.g. timing, power consumption), obtention of
residual sensitive data (e.g. improperly cleared memory) or use of undocumented or invalid
command codes are examples of attack paths. The data may be used to exploit the device it
was obtained on, or another device (e.g. shared secret key).
During the identification phase, the attacker may for instance probe external buses.
T.TEE_FIRMWARE_DOWNGRADE
An attacker backs up part or all the TEE firmware and restores it later in order to use obsolete
TEE functionalities.
Assets threatened directly (integrity): TEE firmware.
Assets threatened indirectly: All data and keys (confidentiality, authenticity, consistency).
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
18
T.STORAGE_CORRUPTION
An attacker corrupts all or part of the non-volatile storage used by the TEE including the
trusted storage, in an attempt to trigger unexpected behavior from the storage security
mechanisms. The ultimate goal of the attack is to disclose and/or modify TEE or TA data
and/or code.
Assets threatened directly: TEE storage root of trust (confidentiality, integrity), TEE persistent
data (confidentiality, consistency), TEE firmware (authenticity, integrity), TA data and keys
(confidentiality, authenticity, consistency), TA instance time (integrity), TA code (authenticity,
consistency).
Application Note:
The attack can rely, for instance, on the REE file system or the Flash driver.
3.4 OSP
This section presents the organizational security policies that have to be implemented by the TOE and/or
its operational environment.
OSP.INTEGRATION_CONFIGURATION
Integration and configuration of the TOE by the device manufacturer shall rely on guidelines
defined by the TOE provider, which fulfill the requirements set in GlobalPlatform TEE
specifications and state all the security requirements for the device manufacturer issued from
the TOE evaluation.
OSP.SECRETS
Generation, storage, distribution, destruction, injection of secret data in the TEE or any other
operation performed outside the TEE shall enforce integrity and confidentiality of these data.
This applies to secret data injected before end-usage phase (such as the root of trust of TEE
storage) or during the end-usage phase (such as cryptographic private or symmetric keys,
confidential data).
3.5 Assumptions
This section states the assumptions that hold on the TEE operational environment. These assumptions
have to be met by the operational environment.
A.PROTECTION_AFTER_DELIVERY
It is assumed that the TOE is protected by the environment after delivery and before entering
the final usage phase. It is assumed that the persons manipulating the TOE in the operational
environment apply the TEE guidelines (e.g. user and administrator guidance, installation
documentation, personalization guide). It is also assumed that the persons responsible for the
application of the procedures contained in the guides, and the persons involved in delivery and
protection of the product have the required skills and are aware of the security issues.
A.ROLLBACK
It is assumed that TA developers do not rely on protection of TEE persistent data, TA data and
keys and TA code against full rollback.
CC Huawei iTrustee Software V5.0 Security Target 3 TOE Security Problem Definition
Copyright © Huawei Technologies Co., Ltd.
19
A.TA_DEVELOPMENT
TA developers are assumed to be competent and trustworthy individuals who will comply with
the TA development guidelines set by the TEE provider. In particular, TA developers are
assumed to consider the following principles during the development of the Trusted
Applications:
 CA identifiers are generated and managed by the REE, outside the scope of the TEE.
A TA must not assume that CA identifiers are genuine
 TAs must not disclose any sensitive data to the REE through any CA (interaction
with the CA may require authentication means)
 Data written to memory that are not under the TA instance's exclusive control may
have changed at next read
 Reading twice from the same location in memory that is not under the TA instance's
exclusive control can return different values.
 When using the trusted storage TOE security function, the TA developers must use a
random data structure when updating TA data.
A.INTEGRATION
It is assumed that the TOE will be installed and configured correctly on the dedicated
hardware according to the installation guidance documentation, and all the hardware,
firmware components of TEE will be adequately protected. The internal communication data
transferred between separated physical components will be protected from disclosure and
modification by the TOE environment. It is assumed also that the firmware installed in the
device is the version that was intended.
A.SECUREBOOT
It is assumed that the TOE will be started in a secure mode which will ensure:
 the authenticity of the TOE firmware
 the integrity of the TEE initialization code and data
 the integrity of the storage root of trust
 the integrity of the TEE identification data
 the version of the firmware to prevent downgrade to previous versions
A.SECURE_HARDWARE/FIRMWARE
It is assumed that the TOE will run on secure hardware/firmware as defined in [TEE PP]; i.e
hardware/firmware provide the security features required by the TOE and are sufficiently
protected from any attack that may cause those features to provide false results. In particular,
it is assumed that the TOE will run in an isolated environment based on ARM trustzone,
which provides protection of internal data transfer between physically separated components
of the TOE and isolation between the REE and TEE.
A.RNG
It is assumed that the random number generator provided by the trusted peripherals will have
a good quality. The generated random number will not be predictable and will have sufficient
entropy.
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
20
4 Security Objectives
4.1 Objectives for the TOE
This section states the security objectives for the TOE.
O.CA_TA_IDENTIFICATION
The TOE shall provide means to protect the identity of each Trusted Application from usage
by another resident Trusted Application and to distinguish Client Applications from Trusted
Applications.
Application Note:
Client properties are managed either by the Rich OS or by the Trusted OS and these must
ensure that a Client cannot tamper with its own properties in the following sense:
 The Client identity of TOE resident TAs MUST always be determined by the Trusted OS
and the determination of whether it is a TA or not MUST be as trustworthy as the Trusted
OS itself
 When the Client identity corresponds to a TA, then the Trusted OS MUST ensure that the
other Client properties are equal to the properties of the calling TA up to the same level of
trustworthiness that the target TA places in the Trusted OS
 When the Client identity does not correspond to a TA, then the Rich OS is responsible for
ensuring that the Client Application cannot tamper with its own properties. However this
information is not trusted by the Trusted OS.
O.KEYS_USAGE
The TOE shall enforce on cryptographic keys the usage restrictions set by their creators.
O.TEE_ID
The TOE shall provide means to retrieve the TEE identifier.
O.INI_INTERNAL
The TOE shall be started through a secure initialization process that ensures the integrity of
the TOE’s internal tasks.
O.INSTANCE_TIME
The TOE shall provide TA instance time and shall ensure that this time is monotonic during
TA instance lifetime - from TA instance creation until the TA instance is destroyed - and not
impacted by transitions through low power states.
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
21
O.OPERATION
The TOE shall ensure the correct operation of its security functions. In particular, the TOE
shall
 Protect itself against abnormal situations caused by programmer errors or violation of
good practices by the REE (and the CAs indirectly) or by the TAs
 Control the access to its services by the REE and TAs: The TOE shall check the
validity of any operation requested from either the REE or a TA, at any entry point
into the TOE
 Enter a secure state upon failure detection, without exposure of any sensitive data.
Application Note:
 Programmer errors or violation of good practices (e.g. that exploit multi-threading or
context/session management) might become attack-enablers. The REE may be
harmful but < the TOE implementation still guarantees the stability and security of
TOE > (cf. [CAPI]). In any case, a Trusted Application MUST NOT be able to use a
programmer error on purpose to circumvent the security boundaries enforced by an
implementation (cf. [IAPI] and [SA])
 Entry points (cf. [SA]): Software in the REE must not be able to call directly to TOE
Functions or Trusted Core Framework. The REE software must go through protocols
such that the Trusted OS or Trusted Application performs the verification of the
acceptability of the operation that the REE software has requested.
O.RUNTIME_CONFIDENTIALITY
The TOE shall ensure that confidential TEE runtime data and TA data and keys are protected
against unauthorized disclosure. In particular,
 The TOE shall not export any sensitive data, random numbers or secret keys to the
REE
 The TOE shall grant access to sensitive data, random numbers or secret keys only to
authorized TAs
 The TOE shall clean up sensitive resources as soon as it can determine that their
values are no longer needed.
O.RUNTIME_INTEGRITY
The TOE shall ensure that the TEE runtime data, the TA code and the TA data and keys are
protected against unauthorized modification at runtime when stored in volatile memory.
O.TA_AUTHENTICITY
The TOE shall verify code authenticity of Trusted Applications.
O.TA_ISOLATION
The TOE shall isolate the TAs from each other based on the hardware MMU: Each TA shall
access its own execution and storage space, which is shared among all the instances of the TA
but separated from the spaces of any other TA.
Application Note:
This objective contributes to the enforcement of the confidentiality and the integrity of the
TOE.
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
22
O.TEE_DATA_PROTECTION
The TOE shall ensure the authenticity, consistency and confidentiality of TEE persistent data.
O.TEE_ISOLATION
The TOE shall prevent (based on the hardware MMU) the REE and the TAs from accessing
the TEE own execution and storage space and resources.
Application Note:
This objective contributes to the enforcement of the correct execution of the TOE. Note that
resource allocation can change during runtime as long as it does not break isolation between
TEE resources during their usage and REE/TAs.
O.TRUSTED_STORAGE
The TOE shall provide Trusted Storage services for persistent TA general-purpose data and
key material such that:
 The confidentiality of the stored data and keys is enforced
 The authenticity of the stored data and keys is enforced
 The consistency of each TA stored data and keys is enforced
 The atomicity of the operations that modify the storage is enforced.
The TOE Trusted Storage shall be bound to the hosting device, which means that the storage
space must be accessible or modifiable only by authorized TAs running on the same TOE and
device as when the data was created.
The table below summarizes which security objectives relate to the assets stored in
non-volatile and/or volatile memory.
Asset In non-volatile memory In volatile memory
TEE runtime data N/A O.RUNTIME_INTEGRITY
TA code O.TA_AUTHENTICITY O.RUNTIME_INTEGRITY
TA data and keys O.TRUSTED_STORAGE O.RUNTIME_INTEGRITY
TEE persistent data O.TEE_DATA_PROTECTION O.TEE_DATA_PROTECTION
Table 8 Assets store location
4.2 Objectives for the Operational Environment
This section states the security objectives for the TOE operational environment covering all the
assumptions and the organizational security policies that apply to the environment.
The following security objectives apply to any TOE operational environment that does not implement
any additional security feature.
OE.INTEGRATION_CONFIGURATION
The TOE shall be installed and configured correctly to ensure the TOE running in a secure
state. The device manufacturer shall apply the TOE preparative guidance [AGD_PRE] for
performing the secure installation of the TOE.
The process of TEE identifier generating shall ensure statistical uniqueness of the TEE
identifier.
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
23
OE.PROTECTION_AFTER_DELIVERY
The TOE shall be protected by the environment after delivery and before entering the final
usage phase. The persons manipulating the TOE in the operational environment shall apply
the TOE guidance documents defined in [AGD_PRE] and [AGD_OPE].
The persons responsible for the application of the procedures contained in the guides, and the
persons involved in delivery and protection of the product must have the required skills and
are aware of the security issues.
OE.ROLLBACK
The TA developer shall take into account that the TOE does not provide full rollback
protection of TOE persistent data, TA data and keys and TA code.
OE.SECRETS
Management of secret data (e.g. generation, storage, distribution, destruction, loading into the
product of cryptographic private keys, symmetric keys, user authentication data) performed
outside the TOE shall enforce integrity and confidentiality of these data.
OE.TA_DEVELOPMENT
TA developers shall comply with the TA development guidelines set by the TOE provider. In
particular, TA developers shall apply the following security recommendations during the
development of the Trusted Applications:
 CA identifiers are generated and managed by the REE, outside the scope of the TOE;
TAs do not assume that CA identifiers are genuine
 TAs do not disclose any sensitive data to the REE through any CA (interaction with
the CA may require authentication means)
 TAs shall not assume that data written to a shared buffer can be read unchanged later
on; TAs should always read data only once from the shared buffer and then validate it
 TAs should copy the contents of shared buffers into TA instance-owned memory
whenever these contents are required to be constant.
 TA developers should apply for TA identifiers from the TOE manufacture before
deploying the TA into the TOE. All of the TA identifiers are generated, issued and
managed by the TOE manufacture.
 When using the trusted storage TOE security function, the TA developers shall use a
random data structure when updating TA data.
OE.INITIALIZATION
The TEE shall be started through a secure initialization process that ensures:
 the integrity of the TEE initialization code and data used to load the TEE firmware
 the authenticity of the TEE firmware
 the TEE is bound to the SoC of the device. In particular, the TEE shall protect the
TEE firmware against downgrade attacks
 the integrity of the storage root of trust
 the integrity of the TEE identification data.
After completion of the initialization process the TOE is running in a secure state.
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
24
Application Note:
The fact that the process is bound to the SoC means that the root of trust for the TEE data
cannot be modified or tampered with (cf. [SA]).
OE.RNG
The hardware which the TOE runs on shall provide a random number generator’s quality.
Random numbers shall not be predictable and shall have sufficient entropy.
OE.TRUSTED_HARDWARE
Trusted hardware/firmware which the TOE runs on shall provide the essential security
features required by the TOE and shall be sufficiently protected from any attack that may
cause those features to provide false results. In particular, trusted hardware shall provide:
 a protection of the communication between physically separated parts of the TOE.
 security mechanisms to implement trust storage function and more information to
implement log service when error is detected.
 a timer to provide reliable time.
Application Note:
Trusted hardware includes Huawei Kirin series SoC, secure storage, RAM mapped to secure
world, etc.
4.3 Security Objectives Rationale
4.3.1 Coverage
The following tables provide mappings between TOE SPD and Security Objectives.
Threats Security Objectives
T.ABUSE_FUNCT O.INI_INTERNAL, O.OPERATION,
O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY,
O.TEE_DATA_PROTECTION,
O.TEE_ISOLATION,
OE.TA_DEVELOPMENT,
O.KEYS_USAGE, O.TA_AUTHENTICITY,
OE.INITIALIZATION,
OE.TRUSTED_HARDWARE
T.CLONE O.TEE_ID, O.INI_INTERNAL,
OE.INITIALIZATION,
O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY,
O.TEE_DATA_PROTECTION,
O.TRUSTED_STORAGE,
OE.INTEGRATION_CONFIGURATION,
OE.TRUSTED_HARDWARE
T.FLASH_DUMP O.TRUSTED_STORAGE,
OE.TRUSTED_HARDWARE
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
25
T.IMPERSONATION O.CA_TA_IDENTIFICATION,
O.OPERATION,
O.RUNTIME_INTEGRITY,
OE.TRUSTED_HARDWARE
T.ROGUE_CODE_EXECUTION O.OPERATION,
O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY,
O.TEE_DATA_PROTECTION,
O.TRUSTED_STORAGE,
OE.INTEGRATION_CONFIGURATION,
OE.PROTECTION_AFTER_DELIVERY,
O.TA_AUTHENTICITY,
O.INI_INTERNAL, OE.INITIALIZATION,
OE.TRUSTED_HARDWARE
T.PERTURBATION O.INI_INTERNAL, OE.INITIALIZATION,
O.OPERATION, O.INSTANCE_TIME,
O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY,
O.TA_ISOLATION,
O.TEE_DATA_PROTECTION,
O.TEE_ISOLATION,
O.TA_AUTHENTICITY,
OE.TRUSTED_HARDWARE
T.RAM O.INI_INTERNAL, OE.INITIALIZATION,
O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY,
O.TA_ISOLATION, O.TEE_ISOLATION
T.SPY O.RUNTIME_CONFIDENTIALITY,
O.TA_ISOLATION, O.TEE_ISOLATION,
O.TRUSTED_STORAGE,
OE.TRUSTED_HARDWARE
T.TEE_FIRMWARE_DOWNGRADE OE.INITIALIZATION,
OE.INTEGRATION_CONFIGURATION,
OE.PROTECTION_AFTER_DELIVERY
T.STORAGE_CORRUPTION O.OPERATION,
OE.ROLLBACK,
O.TEE_DATA_PROTECTION,
O.TRUSTED_STORAGE,
O.TA_AUTHENTICITY,
OE.INITIALIZATION,
OE.TRUSTED_HARDWARE
Table 9: Threats and Security Objectives – Coverage
Security Objectives Threats
O.CA_TA_IDENTIFICATION T.IMPERSONATION
O.KEYS_USAGE T.ABUSE_FUNCT
O.TEE_ID T.CLONE
O.INI_INTERNAL T.ABUSE_FUNCT, T.CLONE,
T.ROGUE_CODE_EXECUTION,
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
26
T.PERTURBATION, T.RAM
O.INSTANCE_TIME T.PERTURBATION
O.OPERATION T.ABUSE_FUNCT, T.IMPERSONATION,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION,
T.STORAGE_CORRUPTION
O.RUNTIME_CONFIDENTIALITY T.ABUSE_FUNCT, T.CLONE,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION, T.RAM, T.SPY
O.RUNTIME_INTEGRITY T.ABUSE_FUNCT, T.CLONE,
T.IMPERSONATION,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION, T.RAM
O.TA_AUTHENTICITY T.ABUSE_FUNCT,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION,
T.STORAGE_CORRUPTION
O.TA_ISOLATION T.PERTURBATION, T.RAM, T.SPY
O.TEE_DATA_PROTECTION T.ABUSE_FUNCT, T.CLONE,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION,
T.STORAGE_CORRUPTION
O.TEE_ISOLATION T.ABUSE_FUNCT, T.PERTURBATION,
T.RAM, T.SPY
O.TRUSTED_STORAGE T.CLONE, T.FLASH_DUMP,
T.ROGUE_CODE_EXECUTION, T.SPY,
T.STORAGE_CORRUPTION
OE.INTEGRATION_CONFIGURATI
ON
T.ROGUE_CODE_EXECUTION,
T.TEE_FIRMWARE_DOWNGRADE
OE.PROTECTION_AFTER_DELIVE
RY
T.ROGUE_CODE_EXECUTION,
T.TEE_FIRMWARE_DOWNGRADE
OE.ROLLBACK T.STORAGE_CORRUPTION
OE.SECRETS
OE.TA_DEVELOPMENT T.ABUSE_FUNCT
OE.INITIALIZATION T.ABUSE_FUNCT, T.CLONE,
T.ROGUE_CODE_EXECUTION,
T.PERTURBATION, T.RAM,
T.TEE_FIRMWARE_DOWNGRADE,
T.STORAGE_CORRUPTION
OE.RNG
OE.TRUSTED_HARDWARE T.ABUSE_FUNCT, T.CLONE, T.FLASH_DUMP,
T.IMPERSONATION, T.ROGUE_CODE_EXECUTION,
T.RAM, T.SPY, T.STORAGE_CORRUPTION,
T.PERTURBATION
Table 10: Security Objectives and Threats – Coverage
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
27
Organizational Security Policies Security Objectives
OSP.INTEGRATION_CONFIGURAT
ION
OE.INTEGRATION_CONFIGURATION
OSP.SECRETS OE.SECRETS
Table 11: OSPs and Security Objectives - Coverage
Security Objectives Organizational Security Policies
OE.INTEGRATION_CONFIGURATI
ON
OSP.INTEGRATION_CONFIGURATION
OE.SECRETS OSP.SECRETS
Table 12: Security Objectives and OSPs – Coverage
Assumptions Security Objectives for the Operational Environment
A.PROTECTION_AFTER_DELIVER
Y
OE.PROTECTION_AFTER_DELIVERY
A.ROLLBACK OE.ROLLBACK
A.TA_DEVELOPMENT OE.TA_DEVELOPMENT
A.SECUREBOOT OE.INITIALIZATION
A.INTEGRATION OE.INTEGRATION_CONFIGURATION,
OE.TRUSTED_HARDWARE, OE.INITIALIZATION
A.SECURE_HARDWARE/FIRMWA
RE
OE.TRUSTED_HARDWARE
A.RNG OE.RNG
Table 13: Assumptions and Security Objectives for the Operational Environment – Coverage
Security Objectives for the Operational
Environment
Assumptions
OE.INTEGRATION_CONFIGURATI
ON
A.INTEGRATION
OE.PROTECTION_AFTER_DELIVE
RY
A.PROTECTION_AFTER_DELILVERY
OE.ROLLBACK A.ROLLBACK
OE.SECRETS
OE.TA_DEVELOPMENT A.TA_DEVELOPMENT
OE.TRUSTED_HARDWARE A.SECURE_HARDWARE/FIRMWARE,
A.INTEGRATION
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
28
OE.INITIALIZATION A.SECUREBOOT, A.INTEGRATION
OE.RNG A.RNG
Table 14: Security Objectives for the Operational Environment and Assumptions - Coverage
4.3.2 Rationale
4.3.2.1 Threats
T.ABUSE_FUNCT The combination of the following objectives ensures protection against abuse of
functionality:
o O.INI_INTERNAL and OE.INITIALIZATION ensures that the TEE security functionality
is correctly initialized
o O.OPERATION ensures correct operation of the security functionality and a proper
management of failures
o O.RUNTIME_CONFIDENTIALITY prevents exposure of confidential data
o O.RUNTIME_INTEGRITY ensures protection against unauthorized modification of
security functionality at runtime
o O.TA_AUTHENTICITY ensures that the authenticity of TA code is verified
o O.TEE_DATA_PROTECTION ensures that the data used by the TEE are authentic and
consistent
o O.TEE_ISOLATION enforces the separation between the TEE and the outside (REE and
TAs)
o O.KEYS_USAGE controls the usage of cryptographic keys
o OE.TA_DEVELOPMENT enforces TA development principles, which are meant in
particular to prevent disclosing information or performing modifications upon request of
unauthorized entities
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.CLONE The combination of the following objectives ensures protection against cloning:
o O.TEE_ID provides the unique TEE identification means
o O.INI_INTERNAL and OE.INITIALIZATION ensure that the TEE is bound to the SoC of
the device
o O.RUNTIME_CONFIDENTIALITY prevents exposure of confidential data, in particular
TSF data used to bind the TEE to the device
o O.RUNTIME_INTEGRITY prevents against unauthorized modification at runtime of
security functionalities or data used to detect or prevent cloning
o O.TEE_DATA_PROTECTION prevents the TEE from using TEE data that is inconsistent
or not authentic
o O.TRUSTED_STORAGE ensures that the trusted storage is bound to the device and
prevents the TEE from using data that is inconsistent or not authentic
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
29
o OE.INTEGRATION_CONFIGURATION ensures that the TEE identifier is in fact unique
when generated outside the TOE
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.FLASH_DUMP The combination of the following objectives ensures protection against flash dump
attacks:
o O.TRUSTED_STORAGE ensures the confidentiality of the data stored in external memory.
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.IMPERSONATION The combination of the following objectives ensures protection against
application impersonation attacks:
o O.CA_TA_IDENTIFICATION ensures the protection of Client identities and the possibility
to distinguish Client Applications and Trusted Applications
o O.OPERATION ensures the verification of Client identities before any operation on their
behalf
o O.RUNTIME_INTEGRITY prevents against unauthorized modification of security
functionality at runtime
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.ROGUE_CODE_EXECUTION The combination of the following objectives ensures protection
against import of malicious code:
o O.INI_INTERNAL and OE.INITIALIZATION ensures that the TEE security functionality
is correctly initialized and the integrity of TEE firmware
o O.OPERATION ensures correct operation of the security functionality
o O.RUNTIME_CONFIDENTIALITY covers runtime TEE data which might influence the
behavior of the TEE
o O.TA_AUTHENTICITY ensures that the authenticity of TA code is verified
o O.RUNTIME_INTEGRITY ensures protection against unauthorized modification of
security functionality at runtime
o O.TEE_DATA_PROTECTION covers persistent TEE data which might influence the
behavior of the TEE
o O.TRUSTED_STORAGE ensures protection of the storage from which code might be
imported
o OE.INTEGRATION_CONFIGURATION covers the import of foreign code in a phase other
than the end-user phase
o OE.PROTECTION_AFTER_DELIVERY covers the import of foreign code in a phase other
than the end-user phase
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.PERTURBATION The combination of the following objectives ensures protection against
perturbation attacks:
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
30
o O.INI_INTERNAL and OE.INITIALIZATION ensures that the TEE security functionality
is correctly initialized
o O.OPERATION ensures correct operation of the security functionality and a proper
management of failures
o O.RUNTIME_CONFIDENTIALITY covers runtime TEE data which might influence the
behavior of the TEE
o O.TA_AUTHENTICITY ensures that the authenticity of TA code is verified
o O.RUNTIME_INTEGRITY ensures protection against unauthorized modification of
security functionality at runtime
o O.TA_ISOLATION ensures the separation of the TA
o O.TEE_DATA_PROTECTION covers persistent TEE data which might influence the
behavior of the TEE
o O.TEE_ISOLATION enforces the separation between the TEE and the outside (REE and
TAs).
o O.INSTANCE_TIME and OE.TRUSTED_HARDWARE ensure the reliability of instance
time stamps.
T.RAM The combination of the following objectives ensures protection against RAM attacks:
o O.INI_INTERNAL and OE.INITIALIZATION ensures that the TEE security functionality
is correctly initialized and that the initialization process is protected from the REE
o O.RUNTIME_CONFIDENTIALITY prevents exposure of confidential data at runtime
o O.RUNTIME_INTEGRITY protects against unauthorized modification of code and data at
runtime
o O.TA_ISOLATION provides a memory barrier between TAs
o O.TEE_ISOLATION provides a memory barrier between the TEE and the REE
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.SPY The combination of the following objectives ensures protection against disclosure:
o O.RUNTIME_CONFIDENTIALITY ensures protection of confidential data at runtime
o O.TA_ISOLATION ensures the separation between TAs
o O.TEE_ISOLATION ensures that neither REE nor TAs can access TEE data
o O.TRUSTED_STORAGE ensures that data stored in the trusted storage locations is
accessible by the TA owner only
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
T.TEE_FIRMWARE_DOWNGRADE The combination of the following objectives ensures
protection against TEE firmware downgrade:
o OE.INITIALIZATION ensures that the firmware that is executed is the version that was
intended
CC Huawei iTrustee Software V5.0 Security Target 4 Security Objectives
Copyright © Huawei Technologies Co., Ltd.
31
o OE.INTEGRATION_CONFIGURATION ensures that the firmware installed in the device
is the version that was intended
o OE.PROTECTION_AFTER_DELIVERY ensures that the firmware has not been modified
after delivery.
T.STORAGE_CORRUPTION The combination of the following objectives ensures protection against
corruption of non-volatile storage:
o O.OPERATION ensures the correct operation of the TEE security functionality, including
storage
o O.TEE_DATA_PROTECTION ensures that stored TEE data are genuine and consistent
o O.TRUSTED_STORAGE enforces detection of corruption of the TA's storage
o O.TA_AUTHENTICITY ensures that the authenticity of TA code is verified
o OE.INITIALIZATION ensures that the firmware that is executed is the version that was
intended
o OE.ROLLBACK states the limits of the properties enforced by the TSF
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
4.3.2.2 OSPs
OSP.INTEGRATION_CONFIGURATION The objective OE.INTEGRATION_CONFIGURATION
directly covers this OSP.
OSP.SECRETS The objective OE.SECRETS directly covers this OSP.
4.3.2.3 Assumptions
A.PROTECTION_AFTER_DELIVERY The objective OE.PROTECTION_AFTER_DELIVERY
directly covers this assumption.
A.ROLLBACK The objective OE.ROLLBACK directly covers this assumption.
A.TA_DEVELOPMENT The objective OE.TA_DEVELOPMENT directly covers this assumption.
A.INTEGRATION The combination of the following objectives covers this assumption:
o OE.INTEGRATION_CONFIGURATION ensures that the hardware, firmware and other
components will be installed and configured correctly in the device.
o OE.TRUSTED_HARDWARE ensures that the trusted hardware/firmware which the TOE
runs on provide the required essential security features.
o OE.INITIALIZATION ensures that the firmware installed in the device is the version that
was intended.
A.SECUREBOOT The objective OE.INITIALIZATION directly covers this assumption.
A.SECURE_HARDWARE/FIRMWARE The objective OE.TRUSTED_HARDWARE directly covers
this assumption.
A.RNG The objective OE.RNG directly covers this assumption.
CC Huawei iTrustee Software V5.0 Security Target 5 Extended Components Definition
Copyright © Huawei Technologies Co., Ltd.
32
5 Extended Components
Definition
5.1 Extended Family FPT_INI - TSF initialization
5.1.1 Description
To define the security functional requirements of the TOE an additional family (FPT_INI) of the Class FPT
(Protection of the TSF) is introduced here. This family describes the functional requirements for the initialization
of the TSF by a dedicated function of the TOE that ensures the initialization in a correct and secure operational
state.
The family TSF Initialization (FPT_INI) is specified as follows.
5.1.2 Family behavior
Description
FPT_INI.1 Requires the TOE to provide a TSF initialization function that brings the TSF into a secure operational
state at power-on.
Hierarchical to: No other components.
Management: No management activities are foreseen.
Audit: No actions are defined to be auditable.
Definition
FPT_INI.1 TSF initialization
FPT_INI.1.1 The TOE initialization function shall verify [assignment: list of implementation-dependent
verifications] prior to establishing the TSF in a secure initial state.
FPT_INI.1.2 The TOE initialization function shall detect and respond to errors and failures during initialization
such that the TOE either successfully completes initialization or is halted.
FPT_INI.1.3 The TOE initialization function shall not be able to arbitrarily interact with the TSF after TOE
initialization completes.
Dependencies: No dependencies.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
33
6 Security Requirements
6.1 Conventions
The conventions used in descriptions of the SFRs are as follows:
(1) Assignment: Indicated with italicized text;
(2) Refinement: Indicated with bold text and strikethroughs, if necessary;
(3) Selection: Indicated with underlined text;
(4) Assignment within a Selection: Indicated with italicized and underlined text;
(5) Iteration: Indicated by appending the iteration number in parenthesis, e.g. (1), (2), (3)
and /or by adding a string starting with “/”;
(6) Application Notes are marked as 'Application Note:' formatted with italicized text;
(7) References: Indicated with [square brackets].
6.2 Definitions of security policies
The statement of the security functional requirements rely on the following characterization of the TEE
in terms of users, subjects, objects, information, user data, TSF data, operations and their security
attributes (cf. CC Part 1 [CC1] for the definition of these notions).
Users stand for entities outside the TOE:
• Client Applications (CA), with security attribute "CA_identity" (CA identifier)
• Trusted Applications (TA), with security attribute "TA_identity" (TA identifier),
"TA_properties".
Subjects stand for active entities inside the TOE:
• S.TA_INSTANCE: any TA instance with security attribute "TA_identity" (TA identifier)
• S.TA_INSTANCE_SESSION: any session within a given TA instance, with security
attribute "client_identity" (CA identifier)
• S.API: the TEE Internal API, with security attributes "caller" (TA identifier)
• S.RESOURCE: Software component which may be used alternatively by the TEE or the
REE, with security attribute "state" (TEE/REE). Note: When the state is REE, the TEE
may access the resource.
• S.RAM_UNIT: RAM addressable unit, with security attribute "rights: (TA identifier/REE)
->(Read/Write/ReadWrite/NoAccess). For instance, an addressable unit may be allocated
or have its access rights changed upon TA instance creation or when sharing memory
references between a client (CA, TA) and a TA. Notes: 1) A RAM_UNIT typically stands
for a byte in the C language; 2) there is no RAM access restriction applicable to the TEE
itself
• S.COMM_AGENT: proxy between CAs in the REE and the TEE and its TAs.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
34
Objects stand for passive entities inside the TOE:
• OB.TA_STORAGE (user data): Trusted Storage space of a TA, with security attributes
"owner" (TA identifier), "inExtMem" (True/False) and "TEE_identity" (TEE identifier).
• OB.SRT (TSF data): the TEE Storage Root of Trust, with security attribute
"TEE_identity" (TEE identifier).
Cryptographic objects are a special kind of TEE objects:
• OB.TA_KEY (user data): (handle to a) user key (persistent or transient), with security
attributes "usage", "owner" (TA identifier), "isExtractable" (True/False).
Information stands for data exchanged between subjects:
• I.RUNTIME_DATA (user data or TSF Data depending on the owner): data belonging to
the TA or to the TEE itself. Stands for parameter values, return values, content of memory
regions in cleartext. Note: Data that is encrypted and authenticated is not considered
I.RUNTIME_DATA.
TSF data consists of runtime TSF data and TSF persistent data (also called TEE persistent data)
necessary to provide the security services. It includes all the security attributes of users, subjects, objects
and information.
Cryptographic operations on user keys performed by S.API on behalf of TA_INSTANCE:
• OP.USE_KEY: any cryptographic operation that uses a key
• OP.EXTRACT_KEY: any operation that populates a key.
Trusted Storage operations performed by S.API on behalf of TA_INSTANCE:
• OP.LOAD: any operation used to get back persistent objects (data and keys) to be used by
the TA
• OP.STORE: any operation used to store persistent objects (data and keys). It stands for
object creation, object deletion, object renaming, object truncation and write to an object.
Other operations:
• Any operation executed by the TEE on behalf of a TA_INSTANCE.
This ST defines the following access control and information flow security functional policies (SFP):
Runtime Data Information Flow Control SFP:
• Purpose: To control the flow of runtime data from and to executable entities and memory.
This policy contributes to ensure the integrity and confidentiality of runtime data
• Subjects: S.TA_INSTANCE, S.TA_INSTANCE_SESSION, S.API, S.COMM_AGENT,
S.RESOURCE, S.RAM_UNIT
• Information: I.RUNTIME_DATA
• Security attributes: S.RESOURCE.state, S.RAM_UNIT.rights and S.API.caller
• SFR instances: FDP_IFC.2/Runtime, FDP_IFF.1/Runtime.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
35
TA Keys Access Control SFP:
• Purpose: To control the access to TA keys, which is granted to the TA that owns the key
only. This policy contributes to the confidentiality of TA keys.
• Subjects: S.API, S.TA_INSTANCE and any other subject in the TEE
• Objects: OB.TA_KEY
• Security attributes: OB.TA_KEY.usage, OB.TA_KEY.owner, OB.TA_KEY.isExtractable,
and S.API.caller
• Operations: OP.USE_KEY, OP.EXTRACT_KEY
• SFR instances: FDP_ACC.1/TA_Keys, FDP_ACF.1/TA_keys, FMT_MSA.1/TA_keys,
FMT_MSA.3/TA_keys, FMT_SMF.1.
Trusted Storage Access Control SFP:
• Purpose: To control the access to TA storage where persistent TA data and keys are stored,
which is granted on behalf of the owner TA only. This policy also enforces the binding of
TA trusted storage to the TEE storage root of trust OB.SRT
• Subjects: S.API
• Objects: OB.TA_STORAGE, OB.SRT
• Security attributes: S.API.caller, OB.TA_STORAGE.owner,
OB.TA_STORAGE.inExtMem, OB.TA_STORAGE.TEE_identity and
OB.SRT.TEE_identity
• Operations: OP.LOAD, OP.STORE
• SFR instances: FDP_ACC.1/Trusted Storage, FDP_ACF.1/Trusted Storage,
FDP_ROL.1/Trusted Storage, FMT_MSA.1/Trusted Storage, FMT_MSA.3/Trusted
Storage, FMT_SMF.1.
6.3 Security Functional Requirements
6.3.1 Identification
FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: CA_identity, TA_identity, TA_properties.
Application Note:
The lifespan of the attributes in such a list is the following:
• CA_identity: The lifetime of this attribute is that of the lifetime of the client session to the
TA
• TA_identity: The availability of this attribute is that of the availability of the TA to clients,
limited further by the TAs presence in the system
• TA_properties: The lifetime of this attribute is that of the availability of the TA to clients,
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
36
limited further by the TAs presence in the system.
FIA_UID.2 User identification before any action
FIA_UID.2.1 The TSF shall require each user to be successfully identified before allowing
any other TSF-mediated actions on behalf of that user.
Application Note:
User stands for Client Application or Trusted Application.
FIA_USB.1 User-subject binding
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects
acting on the behalf of that user:
o Client (CA or TA) identity, codified into the client_identity of the requested TA session
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user
security attributes with subjects acting on the behalf of users:
o If the client is a TA, then the client_identity must be equal to the TA_identity of the TA
subject that is the client
o If the client is a CA, then the client identity must indicate the CA client.
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of users:
o No modification of client_identity is allowed after initialization
Application Note:
The TOE Internal API defines the codification rules of the CA identity.
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles
o TSF
o TA_User
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application Note:
The TA_User role is the TSF running on behalf of a TA, upon request from the REE (by
Client Applications) or from other TAs.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
37
6.3.2 Confidentiality, Integrity and Isolation
FDP_IFC.2/Runtime Complete information flow control
FDP_IFC.2.1/Runtime The TSF shall enforce the Runtime Data Information Flow Control
SFP on
o Subjects: S.TA_INSTANCE, S.TA_INSTANCE_SESSION, S.API, S.COMM_AGENT,
S.RESOURCE, S.RAM_UNIT
o Information: I.RUNTIME_DATA
and all operations that cause that information to flow to and from subjects covered by the SFP.
FDP_IFC.2.2/Runtime The TSF shall ensure that all operations that cause any information in
the TOE to flow to and from any subject in the TOE are covered by an information flow
control SFP.
Application Note:
The flow control policy specifies the conditions to communicate runtime data from one
subject to another. It applies to operations that are standard interfaces of these subjects.
FDP_IFF.1/Runtime Simple security attributes
FDP_IFF.1.1/Runtime The TSF shall enforce the Runtime Data Information Flow Control
SFP based on the following types of subject and information security attributes:
S.RESOURCE.state, S.RAM_UNIT.rights and S.API.caller.
FDP_IFF.1.2/Runtime The TSF shall permit an information flow between a controlled
subject and controlled information via a controlled operation if the following rules hold:
o Rules for information flow between S.TA_INSTANCE and S.RAM_UNIT:
 Flow of I.RUNTIME_DATA from S.TA_INSTANCE to S.RAM_UNIT is allowed
only if S.RAM_UNIT.rights(S.TA_INSTANCE) is Write or ReadWrite
 Flow of I.RUNTIME_DATA from S.RAM_UNIT to S.TA_INSTANCE is allowed
only if S.RAM_UNIT.rights(S.TA_INSTANCE) is Read or ReadWrite
o Rules for information flow from and to S.COMM_AGENT:
 Flow of I.RUNTIME_DATA from S.COMM_AGENT to S.RAM_UNIT is
allowed only if S.RAM_UNIT.rights(REE) is Write or ReadWrite
 Flow of I.RUNTIME_DATA from S.RAM_UNIT to S.COMM_AGENT is
allowed only if S.RAM_UNIT.rights(REE) is Read or ReadWrite
o Rules for information flow from and to S.API:
 Flow of I.RUNTIME_DATA from S.API to S.RAM_UNIT is allowed only if
S.RAM_UNIT.rights(S.API.caller) is Write or ReadWrite
 Flow of I.RUNTIME_DATA from S.RAM_UNIT to S.API is allowed only if
S.RAM_UNIT.rights(S.API.caller) is Read or ReadWrite
o Rules for information flow from and to S.RESOURCE:
 Flow of I.RUNTIME_DATA between S.API and S.RESOURCE is allowed only
if the resource is under TEE control (S.RESOURCE.state = TEE).
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
38
FDP_IFF.1.3/Runtime The TSF shall enforce the none.
FDP_IFF.1.4/Runtime The TSF shall explicitly authorize an information flow based on the
following rules:
o Rules for information flow from and to S.TA_INSTANCE_SESSION:
 Flow of I.RUNTIME_DATA that are parameter or return values is allowed
between S.TA_INSTANCE_SESSION and S.COMM_AGENT
 Flow of I.RUNTIME_DATA that are parameter or return values is allowed
between S.TA_INSTANCE_SESSION and S.API.
FDP_IFF.1.5/Runtime The TSF shall explicitly deny an information flow based on the
following rules: Any information flow involving a TEE subject unless one of the conditions
stated in FDP_IFF.1.1/1.2/1.3/1.4 holds.
FDP_RIP.1/Runtime Subset residual information protection
FDP_RIP.1.1/Runtime The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the following objects:
TEE and TA runtime objects.
Application Note:
This operation applies in particular upon:
o Failure detection (cf. FPT_FLS.1)
o TA instance and TA session closing.
6.3.3 Cryptography
FCS_COP.1 Cryptographic operation
FCS_COP.1.1 The TSF shall perform cryptographic operations in accordance with a
specified cryptographic algorithm (algorithm name and supported modes listed in Table 3)
and cryptographic key sizes (key sizes listed in Table 3) that meet the following: (standard
listed in Table 3).
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method physical deletion of key value by overwriting with a
constant pattern that meets the following: none.
FDP_ACC.1/TA_keys Subset access control
FDP_ACC.1.1/TA_keys The TSF shall enforce the TA Keys Access Control SFP on
o Subjects: S.API, S.TA_INSTANCE and any other subject in the TEE
o Objects: OB.TA_KEY
o Operations: OP.USE_KEY, OP.EXTRACT_KEY.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
39
FDP_ACF.1/TA_keys Security attribute based access control
FDP_ACF.1.1/TA_keys The TSF shall enforce the TA Keys Access Control SFP to objects
based on the following: OB.TA_KEY.usage, OB.TA_KEY.owner, OB_TA_KEY.isExtractable
and S.API.caller.
FDP_ACF.1.2/TA_keys The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
o OP.USE_KEY is allowed if the following conditions hold:
 The TA instance that requested the operation to the API owns the key
(S.API.caller = OB.TA_KEY.owner)
 The intended usage of the key (OB.TA_KEY.usage) matches the requested
Operation
o OP.EXTRACT_KEY is allowed if the following conditions hold:
 The TA instance that requested the operation to the API owns the key
(S.API.caller = OB.TA_KEY.owner)
 The operation attempts to extract the public part of OB.TA_KEY or the key is
extractable (OB.TA_KEY.isExtractable = True).
FDP_ACF.1.3/TA_keys The TSF shall explicitly authorize access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/TA_keys The TSF shall explicitly deny access of subjects to objects based on
the following additional rules:
o Any access to a user key attempted directly from S.TA_INSTANCE or any other subject
of the TEE that is not S.API
o Any access to a user key attempted from S.API without valid caller (S.API.caller is
undefined)
FMT_MSA.1/TA_keys Management of security attributes
FMT_MSA.1.1/TA_keys The TSF shall enforce the TA Keys Access Control SFP to restrict
the ability to change_default, query and modify the security attributes OB.TA_KEY.usage,
OB.TA_KEYS.isExtractable and OB.TA_KEY.owner to the following roles:
o change_default, query and modify OB.TA_KEY.usage to TA_User role
o query OB.TA_KEY.owner to the TSF role.
FMT_MSA.3/TA_keys Static attribute initialization
FMT_MSA.3.1/TA_keys The TSF shall enforce the TA Keys Access Control SFP to provide
restrictive default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/TA_keys The TSF shall allow the TA_User role to specify alternative initial
values to override the default values when an object or information is created.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
40
6.3.4 Initialization and Operation Integrity
FAU_ARP.1 Security alarms
FAU_ARP.1.1 The TSF shall enter a safe state upon detection of a potential security
violation.
Refinement:
The TSF shall take the following actions upon detection of a potential security violation:
o detection of consistency violation of TA data, TA code or TEE data: reject the
error or malicious data.
FDP_SDI.2 Stored data integrity monitoring and action
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
integrity errors on all objects, based on the following attributes: user data attributes.
Refinement:
The TSF shall monitor TEE runtime data, TEE persistent data, TA data and keys and
TA code stored in containers controlled by the TSF for authenticity and consistency
errors on all objects, based on the following attributes: TEE runtime data, TEE
persistent data, TA data and keys and TA code.
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall take secure action that
does not depend on the compromised data.
Refinement:
o Upon detection of authenticity or consistency errors in TEE runtime data or TEE
persistent data, the TSF shall stop the execution of the TSF and return an error
o Upon detection of TA code authenticity or consistency errors, the TSF shall abort
the execution of the TA instance
o Upon detection of TA data or TA keys authenticity or consistency errors, the TSF
shall not give back any compromised data
Application Note:
This SFR applies to TEE runtime data in volatile memory (this data is not stored in
non-volatile memory) and to TEE persistent data, TA data and keys and TA code in both
volatile and non-volatile memory.
This SFR is used for both TSF and user data as similar mechanisms are involved to
protect the consistency of this data.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
41
FPT_FLS.1 Failure with preservation of secure state
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur:
o Device binding failure
o Cryptographic operation failure
o Invalid CA requests, in particular bad-formed requests
o Panic states
o TA code, TA data or TA keys authenticity or consistency failure
o TEE data (in particular TA properties, TEE keys and all security attributes)
authenticity or consistency failure
o TEE initialization failure
o Unexpected commands in the current TEE state
Application Note:
Device binding failure occurs when (part of) the stored data has not been bound by the
same TEE.
If everything goes well since TOE start, the TOE works in normal state. When failure
occurred, the TOE stop the failure module running so that the TOE will not leak any
sensitive information like encryption key, key structure data to REE world.
FPT_INI.1 TSF initialization
FPT_INI.1.1 The TOE initialization function shall verify the integrity of the TOE internal
tasks prior to establishing the TSF in a secure initial state.
FPT_INI.1.2 The TOE initialization function shall detect and respond to errors and failures
during initialization such that the TOE either successfully completes initialization or is halted.
FPT_INI.1.3 The TOE initialization function shall not be able to arbitrarily interact with the
TSF after TOE initialization completes.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
o Management of TA keys security attributes
o Provision of Trusted Storage security attributes to authorized users.
FPT_TEE.1 Testing of external entities
FPT_TEE.1.1 The TSF shall run a suite of tests prior execution to check the fulfillment of
authenticity of TA code.
FPT_TEE.1.2 If the test fails, the TSF shall not start the execution of the TA instance.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
42
6.3.5 TEE Identification
FAU_SAR.1 Audit review
FAU_SAR.1.1 The TSF shall provide all users with the capability to read TEE identifier from
the audit records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable for the user to
interpret the information.
FAU_STG.1 Protected audit trail storage
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from
unauthorized deletion.
FAU_STG.1.2 The TSF shall be able to prevent unauthorized modifications to the stored
audit records in the audit trail.
Application Note:
The audit record in this SFR refer to the TEE identifier.
The TEE identifier is generated on-TEE, and the generating algorithm is defined by the
manufacturer who will guarantee the TEE identifier to be unique.
When the TOE startup, TOE will read DIEID and HUK from Efuse and generate the TEE
identifier based on that two parameters. The TEE identifier is stored in TEE’s volatile memory
and will be lost when TOE shutdown.
This identifier shall not be modified during the end-usage phase.
6.3.6 Trusted Storage
FDP_ACC.1/Trusted Storage Subset access control
FDP_ACC.1.1/Trusted Storage The TSF shall enforce the Trusted Storage Access Control
SFP on
o Subjects: S.API
o Objects: OB.TA_STORAGE, OB.SRT
o Operations: OP.LOAD, OP.STORE.
FDP_ACF.1/Trusted Storage Security attribute based access control
FDP_ACF.1.1/Trusted Storage The TSF shall enforce the Trusted Storage Access Control
SFP to objects based on the following: S.API.caller, OB.TA_STORAGE.owner,
OB.TA_STORAGE.inExtMem, OB.TA_STORAGE.TEE_identity and OB.SRT.TEE_identity.
FDP_ACF.1.2/Trusted Storage The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
o OP.LOAD of an object from OB.TA_STORAGE is allowed if the following conditions
hold:
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
43
• The operation is performed by S.API
• The load request comes from an instance of the owner of the trusted storage space
(S.API.caller = OB.TA_STORAGE.owner)
• OB.TA_STORAGE is bound to the TEE storage root of trust OB.SRT
(OB.TA_STORAGE.TEE_identity = OB.SRT.TEE_identity)
• If OB.TA_STORAGE is located in external memory accessible to the REE
(OB.TA_STORAGE.inExtMem = True) then the object is authenticated and
decrypted before load
o OP.STORE of an object to OB.TA_STORAGE is allowed if the following conditions
hold:
• The operation is performed by S.API
• The store request comes from an instance of the owner of the trusted storage space
(S.API.caller = OB.TA_STORAGE.owner)
• OB.TA_STORAGE is bound to the TEE storage root of trust OB.SRT
(OB.TA_STORAGE.TEE_identity = OB.SRT.TEE_identity)
• If OB.TA_STORAGE is located in external memory accessible to the REE
(OB.TA_STORAGE.inExtMem = True) then the object is signed and encrypted
before storage.
FDP_ACF.1.3/Trusted Storage The TSF shall explicitly authorize access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1.4/Trusted Storage The TSF shall explicitly deny access of subjects to objects
based on the following additional rules:
o Any access to a trusted storage attempted from S.API without valid caller (S.API.caller
= undefined)
o Any access to a trusted storage that was bound to a different TEE
(OB.TA_STORAGE.TEE_identity different from OB.SRT.TEE_identity)
o Any access to a trusted storage from a subject different from S.API
FDP_ROL.1/Trusted Storage Basic rollback
FDP_ROL.1.1/Trusted Storage The TSF shall enforce Trusted Storage Access Control SFP
to permit the rollback of the unsuccessful or interrupted OP.STORE operation on the storage.
FDP_ROL.1.2/Trusted Storage The TSF shall permit operations to be rolled back within the
store operation failed.
Application Note:
This SFR enforces atomicity of any write operation [IAPI].
FMT_MSA.1/Trusted Storage Management of security attributes
FMT_MSA.1.1/Trusted Storage The TSF shall enforce the Trusted Storage Access Control
SFP to restrict the ability to query the security attributes OB.TA_STORAGE.owner,
OB.TA_STORAGE.inExtMem, OB.TA_STORAGE.TEE_identity and OB.SRT.TEE_identity to
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
44
TA_User role.
FMT_MSA.3/Trusted Storage Static attribute initialization
FMT_MSA.3.1/Trusted Storage The TSF shall enforce the Trusted Storage Access Control
SFP to provide restrictive default values for security attributes that are used to enforce the
SFP.
FMT_MSA.3.2/Trusted Storage The TSF shall allow the TA_User to specify alternative
initial values to override the default values when an object or information is created.
FDP_ITT.1/Trusted Storage Basic internal transfer protection
FDP_ITT.1.1/Trusted Storage The TSF shall enforce the Trusted Storage Access Control
SFP to prevent the disclosure and modification of user data when it is transmitted between
physically-separated parts of the TOE.
6.3.7 Instance Time
FPT_STM.1/Instance time Reliable time stamps
FPT_STM.1.1/Instance time The TSF shall be able to provide reliable time stamps.
Refinement:
The TSF shall be able to provide time stamps to TA instances such that time stamps are
monotonic during the TA instance lifetime.
Application Note:
The refinement provides the meaning of the reliability that is expected.
6.4 Security Functional Requirements Rationale
6.4.1 Security Objectives for the TOE
O.CA_TA_IDENTIFICATION The following requirements contribute to fulfill the objective:
o FIA_ATD.1 enforces the management of the Client and TA identity and properties as
security attributes, which then become TSF data, protected in integrity and confidentiality
o FIA_UID.2 requires the identification of Client application or TA before any action, thus
allowing the access to services and data to authorized users only
o FIA_USB.1 enforces the association of the user identity to the active entity that acts on
behalf of the user and to check that this is a valid identity.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
45
O.KEYS_USAGE The following requirements contribute to fulfill the objective:
o FCS_COP.1 allows to specify the cryptographic operations in the scope of the evaluation if
any
o FDP_ACC.1/TA_keys, FDP_ACF.1/TA_keys, FMT_MSA.1/TA_keys,
FMT_MSA.3/TA_keys, FMT_SMR.1 and FMT_SMF.1 state the key access policy, which
grants access to the owner of the key only.
O.TEE_ID The following requirements contribute to fulfill the objective:
o FAU_SAR.1 enforces TEE identifier access capabilities
o FAU_STG.1 enforces TEE identifier storage capabilities
O.INI_INTERNAL The following requirements contribute to fulfill the objective:
o FPT_FLS.1 states that the TEE has to reach a secure state upon initialization or device
binding failure
o FPT_INI.1 enforces the initialization of the TSF through a secure process including the
verification of the integrity of the TOE internal tasks.
O.INSTANCE_TIME The following requirement fulfills the objective:
o FPT_STM.1/Instance time enforces the reliability of TA instance time.
O.OPERATION The following requirements contribute to fulfill the objective:
o FAU_ARP.1 states the TEE responses to potential security violations
o FDP_SDI.2 enforces the monitoring of consistency and authenticity of TEE data and TA,
and it states the behavior in case of failure
o FIA_ATD.1, FIA_UID.2 and FIA_USB.1 ensure that actions are performed by identified
users
o FMT_SMR.1 states the two operational roles enforced by the TEE
o FPT_FLS.1 states that abnormal operations have to lead to a secure state
o FDP_ACC.1/Trusted Storage, FDP_ACF.1/Trusted Storage, FMT_MSA.1/Trusted Storage,
FMT_MSA.3/Trusted Storage and FMT_SMF.1 state the policy for controlling access to TA
storage
o FDP_IFC.2/Runtime and FDP_IFF.1/Runtime state the policy for controlling access to TA
and TEE execution spaces
o FDP_ACC.1/TA_keys, FDP_ACF.1/TA_keys, FMT_MSA.1/TA_keys,
FMT_MSA.3/TA_keys and FMT_SMF.1 state the key access policy.
O.RUNTIME_CONFIDENTIALITY The following requirements contribute to fulfill the objective:
o FDP_IFC.2/Runtime and FDP_IFF.1/Runtime ensure read access to authorized entities only
o FDP_RIP.1/Runtime states resource clean up policy.
O.RUNTIME_INTEGRITY The following requirements contribute to fulfill the objective:
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
46
o FDP_IFC.2/Runtime and FDP_IFF.1/Runtime state TEE and TA runtime data policy, which
grants write access to authorized entities only
o FDP_SDI.2 monitors the authenticity and consistency of TEE code, the TEE runtime data,
the TA code and the TA data and keys and states the response upon failure.
O.TA_AUTHENTICITY The following requirements contribute to fulfill the objective:
o FDP_SDI.2 enforces the consistency and authenticity of TA code during storage
o FPT_TEE.1 enforces the check of authenticity of TA code prior execution
o FCS_COP.1 states the cryptography used to verify the authenticity of TA code
O.TA_ISOLATION The following requirements contribute to fulfill the objective:
o FDP_ACC.1/Trusted Storage, FDP_ACF.1/Trusted Storage, FMT_MSA.1/Trusted Storage,
FMT_MSA.3/Trusted Storage and FMT_SMF.1 state the policy for controlling access to TA
storage
o FCS_COP.1 state the cryptographic algorithms used for Trusted Storage to ensure
confidentiality and authenticity of TA data
o FDP_IFC.2/Runtime and FDP_IFF.1/Runtime state the policy for controlling access to TA
execution space
o FPT_FLS.1 enforces TA isolation by maintaining a secure state, in particular in case of
panic states.
O.TEE_DATA_PROTECTION The following requirements contribute to fulfill the objective:
o FCS_COP.1 states the cryptography used to protect consistency and confidentiality of the
TEE data in external memory, if applicable
o FDP_SDI.2 monitors the authenticity and consistency of TEE persistent data and states the
response upon failure
O.TEE_ISOLATION The following requirements contribute to fulfill the objective:
o FDP_IFC.2/Runtime and FDP_IFF.1/Runtime state the policy for controlling access to TEE
execution space.
O.TRUSTED_STORAGE The following requirements contribute to fulfill the objective:
o FCS_COP.1 states the cryptography used to protect integrity and confidentiality of the TA
data in external memory, if applicable
o FDP_ACC.1/Trusted Storage, FDP_ACF.1/Trusted Storage, FDP_ROL.1/Trusted Storage,
FMT_MSA.1/Trusted Storage, FMT_MSA.3/Trusted Storage and FMT_SMF.1 state Storage
state the policy for accessing TA trusted storage and protecting the confidentiality of data
o FDP_SDI.2 enforces the consistency and authenticity of the trusted storage
o FDP_ITT.1/Trusted Storage ensure protection against disclosure of TEE and TA data that is
transferred between resources
o FPT_FLS.1 maintains a secure state.
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
47
6.4.2 Rationale tables of Security Objectives and SFRs
Security Objectives Security Functional Requirements Rationale
O.CA_TA_IDENTIFICATION FIA_ATD.1, FIA_UID.2, FIA_USB.1 Section 6.4.1
O.KEYS_USAGE
FDP_ACC.1/TA_keys, FDP_ACF.1/TA_keys,
FMT_MSA.1/TA_keys, FMT_MSA.3/TA_keys,
FMT_SMF.1, FCS_COP.1, FMT_SMR.1,
FCS_CKM.4
Section 6.4.1
O.TEE_ID FAU_SAR.1, FAU_STG.1 Section 6.4.1
O.INI_INTERNAL FPT_FLS.1, FPT_INI.1 Section 6.4.1
O.INSTANCE_TIME FPT_STM.1/Instance time Section 6.4.1
O.OPERATION
FAU_ARP.1, FDP_SDI.2, FIA_ATD.1,
FIA_UID.2, FIA_USB.1, FMT_SMR.1,
FPT_FLS.1, FDP_IFC.2/Runtime,
FDP_IFF.1/Runtime, FMT_SMF.1,
FDP_ACC.1/Trusted Storage,
FDP_ACF.1/Trusted Storage,
FMT_MSA.1/Trusted Storage,
FMT_MSA.3/Trusted Storage,
FDP_ACC.1/TA_keys, FDP_ACF.1/TA_keys,
FMT_MSA.1/TA_keys, FMT_MSA.3/TA_keys
Section 6.4.1
O.RUNTIME_CONFIDENTIALITY
FDP_IFC.2/Runtime, FDP_IFF.1/Runtime,
FDP_RIP.1/Runtime,
Section 6.4.1
O.RUNTIME_INTEGRITY
FDP_IFC.2/Runtime, FDP_IFF.1/Runtime,
FDP_SDI.2
Section 6.4.1
O.TA_AUTHENTICITY FDP_SDI.2, FCS_COP.1, FPT_TEE.1, FCS_CKM.4 Section 6.4.1
O.TA_ISOLATION
FDP_ACC.1/Trusted Storage,
FDP_ACF.1/Trusted Storage,
FDP_IFC.2/Runtime, FDP_IFF.1/Runtime,
FMT_MSA.1/Trusted Storage,
FMT_MSA.3/Trusted Storage, FMT_SMF.1,
FCS_COP.1, FPT_FLS.1, FCS_CKM.4
Section 6.4.1
O.TEE_DATA_PROTECTION FDP_SDI.2, FCS_COP.1, FCS_CKM.4 Section 6.4.1
O.TEE_ISOLATION FDP_IFC.2/Runtime, FDP_IFF.1/Runtime Section 6.4.1
O.TRUSTED_STORAGE
FDP_ACC.1/Trusted Storage,
FDP_ACF.1/Trusted Storage,
FDP_ROL.1/Trusted Storage, FDP_SDI.2,
FMT_MSA.1/Trusted Storage,
FMT_MSA.3/Trusted Storage, FCS_COP.1,
FMT_SMF.1, FPT_FLS.1,
FDP_ITT.1/Trusted Storage, FCS_CKM.4
Section 6.4.1
Table 15: Security Objectives and SFRs - Coverage
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
48
Security Functional
Requirements
Objectives
FIA_ATD.1 O.CA_TA_IDENTIFICATION, O.OPERATION
FIA_UID.2 O.CA_TA_IDENTIFICATION, O.OPERATION
FIA_USB.1 O.CA_TA_IDENTIFICATION, O.OPERATION
FMT_SMR.1 O.KEYS_USAGE, O.OPERATION
FDP_IFC.2/Runtime O.OPERATION, O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY, O.TA_ISOLATION,
O.TEE_ISOLATION
FDP_IFF.1/Runtime O.OPERATION, O.RUNTIME_CONFIDENTIALITY,
O.RUNTIME_INTEGRITY, O.TA_ISOLATION,
O.TEE_ISOLATION
FDP_RIP.1/Runtime O.RUNTIME_CONFIDENTIALITY
FCS_COP.1, FCS_CKM.4 O.KEYS_USAGE, O.TA_AUTHENTICITY, O.TA_ISOLATION,
O.TEE_DATA_PROTECTION, O.TRUSTED_STORAGE
FDP_ACC.1/TA_keys O.KEYS_USAGE, O.OPERATION
FDP_ACF.1/TA_keys O.KEYS_USAGE, O.OPERATION
FMT_MSA.1/TA_keys O.KEYS_USAGE, O.OPERATION
FMT_MSA.3/TA_keys O.KEYS_USAGE, O.OPERATION
FAU_ARP.1 O.OPERATION
FDP_SDI.2 O.OPERATION, O.RUNTIME_INTEGRITY,
O.TA_AUTHENTICITY, O.TEE_DATA_PROTECTION,
O.TRUSTED_STORAGE
FPT_FLS.1 O.INI_INTERNAL, O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FPT_INI.1 O.INI_INTERNAL
FMT_SMF.1 O.KEYS_USAGE, O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FPT_TEE.1 O.TA_AUTHENTICITY
FAU_SAR.1 O.TEE_ID
FAU_STG.1 O.TEE_ID
FPT_STM.1/Instance time O.INSTANCE_TIME
FDP_ACC.1/Trusted Storage O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FDP_ACF.1/Trusted Storage O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FDP_ROL.1/Trusted
Storage
O.TRUSTED_STORAGE
FMT_MSA.1/Trusted
Storage
O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FMT_MSA.3/Trusted
Storage
O.OPERATION, O.TA_ISOLATION,
O.TRUSTED_STORAGE
FDP_ITT.1/Trusted
Storage
O.TRUSTED_STORAGE
Table 16: SFRs and Security Objectives
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
49
6.4.3 SFRs Dependencies
The dependency analysis for the security functional requirements shows that the basis for mutual
support and internal consistency between all defined functional requirements is satisfied. All
dependencies between the chosen functional components are analyzed, and non-dissolved dependencies
are appropriately explained in section 6.4.4. The following table shows the dependencies between the
SFRs of the TOE.
SFRs CC Dependencies Satisfied Dependencies
FIA_ATD.1 No Dependencies
FIA_UID.2 No Dependencies
FIA_USB.1 (FIA_ATD.1) FIA_ATD.1
FMT_SMR.1 (FIA_UID.1) FIA_UID.2
FDP_IFC.2/Runtime (FDP_IFF.1) FDP_IFF.1/Runtime
FDP_IFF.1/Runtime (FDP_IFC.1) and (FMT_MSA.3) FDP_IFC.2/Runtime
FDP_RIP.1/Runtime No Dependencies
FCS_CKM.4
(FCS_CKM.1 or FDP_ITC.1 or
FDP_ITC.2)
FCS_COP.1
(FCS_CKM.1 or FDP_ITC.1 or
FDP_ITC.2) and (FCS_CKM.4)
FCS_CKM.4
FDP_ACC.1/TA_keys (FDP_ACF.1) FDP_ACF.1/TA_keys
FDP_ACF.1/TA_keys (FDP_ACC.1) and (FMT_MSA.3)
FDP_ACC.1/TA_keys,
FMT_MSA.3/TA_keys
FMT_MSA.1/TA_keys
(FDP_ACC.1 or FDP_IFC.1) and
(FMT_SMF.1) and (FMT_SMR.1)
FMT_SMR.1,
FDP_ACC.1/TA_keys,
FMT_SMF.1
FMT_MSA.3/TA_keys (FMT_MSA.1) and (FMT_SMR.1)
FMT_SMR.1,
FMT_MSA.1/TA_keys
FAU_ARP.1 (FAU_SAA.1)
FDP_SDI.2 No Dependencies
FPT_FLS.1 No Dependencies
FPT_INI.1 No Dependencies
FMT_SMF.1 No Dependencies
FPT_TEE.1 No Dependencies
FAU_SAR.1 (FAU_GEN.1)
FAU_STG.1 (FAU_GEN.1)
FPT_STM.1/Instance time No Dependencies
FDP_ACC.1/Trusted
Storage
(FDP_ACF.1) FDP_ACF.1/Trusted Storage
FDP_ACF.1/Trusted Storage (FDP_ACC.1) and (FMT_MSA.3)
FDP_ACC.1/Trusted Storage,
FMT_MSA.3/Trusted storage
FDP_ROL.1/Trusted
Storage
(FDP_ACC.1 or FDP_IFC.1) FDP_ACC.1/Trusted storage
FMT_MSA.1/Trusted
Storage
(FDP_ACC.1 or FDP_IFC.1) and
(FMT_SMF.1) and (FMT_SMR.1)
FMT_SMR.1, FMT_SMF.1,
FDP_ACC.1/Trusted Storage
FMT_MSA.3/Trusted
Storage
(FMT_MSA.1) and (FMT_SMR.1)
FMT_SMR.1,
FMT_MSA.1/Trusted Storage
FDP_ITT.1/Trusted Storage (FDP_ACC.1 or FDP_IFC.1) FDP_ACC.1/Trusted storage
Table 17: SFRs Dependencies
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
50
6.4.4 Rationale for the exclusion of Dependencies
The dependency FMT_MSA.3 of FDP_IFF.1/Runtime is discarded. There is no management of
security attributes by authorized users for this information flow control SFP as all security attributes are
exclusively managed by the TSF, therefore the dependency FMT_MSA.3 is not applicable.
The dependency FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 of FCS_COP.1 is discarded. The TEE
storage root of trust cryptographic key used for cryptographic operations in FCS_COP.1 is set during
manufacturing.
The dependency FAU_SAA.1 of FAU_ARP.1 is discarded. The potential security violations are
explicitly defined in the FAU_ARP.1 requirement. There is no audited event defined in the SFR of this
ST.
The dependency FAU_GEN.1 of FAU_SAR.1 is discarded. This dependency is discarded as the only
audit record considered is the TEE identifier and this identifier is set before TOE delivery and
non-modifiable afterwards.
The dependency FAU_GEN.1 of FAU_STG.1 is discarded. This dependency is discarded as the only
audit record considered is the TEE identifier and this identifier is set before TOE delivery and
non-modifiable afterwards.
6.5 Security Assurance Requirements Rationale
The assurance level defined in this ST consists of the predefined assurance package EAL 4 with the
augmentation ALC_FLR.1.
EAL4 allows a TOE developer to attain a reasonably high assurance level without the need for highly
specialized processes and practices. It is considered to be the highest level that could be applied to an
existing product line without undue expense and complexity. As such, EAL4 is appropriate for
commercial products that can be applied to moderate to high security functions.
The augmentation with FLR.1 ensures that the TOE will be maintained and supported in the future,
requiring the TOE developer to have the procedures to track and correct flaws in the TOE and to
distribute the flaw information and corrections to TOE users. The following table shows the
dependencies between the Security Assurance Requirements (SARs).
Requirements CC Dependencies Satisfied Dependencies
ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.4, ADV_TDS.3
ADV_FSP.4 (ADV_TDS.1) ADV_TDS.3
ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.3, ALC_TAT.1
ADV_TDS.3 (ADV_FSP.4) ADV_FSP.4
AGD_OPE.1 (ADV_FSP.1) ADV_FSP.4
AGD_PRE.1 No Dependencies
ALC_CMC.4 (ALC_CMS.1) and (ALC_DVS.1)
and (ALC_LCD.1)
ALC_CMS.4, ALC_DVS.1,
ALC_LCD.1
ALC_CMS.4 No Dependencies
CC Huawei iTrustee Software V5.0 Security Target 6 Security Requirements
Copyright © Huawei Technologies Co., Ltd.
51
Requirements CC Dependencies Satisfied Dependencies
ALC_DEL.1 No Dependencies
ALC_DVS.1 No Dependencies
ALC_LCD.1 No Dependencies
ALC_FLR.1 No Dependencies
ALC_TAT.1 (ADV_IMP.1) ADV_IMP.1
ASE_CCL.1 (ASE_ECD.1) and (ASE_INT.1)
and (ASE_REQ.1)
ASE_ECD.1, ASE_INT.1,
ASE_REQ.2
ASE_ECD.1 No Dependencies
ASE_INT.1 No Dependencies
ASE_OBJ.2 (ASE_SPD.1) ASE_SPD.1
ASE_REQ.2 (ASE_ECD.1) and (ASE_OBJ.2) ASE_ECD.1, ASE_OBJ.2
ASE_SPD.1 No Dependencies
ASE_TSS.1 (ADV_FSP.1) and (ASE_INT.1)
and (ASE_REQ.1)
ADV_FSP.4, ASE_INT.1,
ASE_REQ.2
ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ADV_FSP.4, ATE_FUN.1
ATE_DPT.1 (ADV_ARC.1) and (ADV_TDS.2)
and (ATE_FUN.1)
ADV_ARC.1, ADV_TDS.3,
ATE_FUN.1
ATE_FUN.1 (ATE_COV.1) ATE_COV.2
ATE_IND.2 (ADV_FSP.2) and (AGD_OPE.1)
and (AGD_PRE.1) and
(ATE_COV.1) and (ATE_FUN.1)
ADV_FSP.4, AGD_OPE.1,
AGD_PRE.1, ATE_COV.2,
ATE_FUN.1
AVA_VAN.3 (ADV_ARC.1) and (ADV_FSP.4)
and (ADV_IMP.1) and
(ADV_TDS.3) and (AGD_OPE.1)
and (AGD_PRE.1) and
(ATE_DPT.1)
ADV_ARC.1, ADV_FSP.4,
ADV_IMP.1, ADV_TDS.3,
AGD_OPE.1, AGD_PRE.1,
ATE_DPT.1
Table 18: SARs Dependencies
CC Huawei iTrustee Software V5.0 Security Target 7 TOE Summary Specification
Copyright © Huawei Technologies Co., Ltd.
52
7 TOE Summary Specifica
tion
For every security function a short identifier is specified in brackets to allow direct referencing to single
items in other documents.
7.1 Protection of TSF
The TOE provides several security mechanisms to ensure TOE’s self-security. Detailed functions
include:
o The TOE can run internal TA and external TA. Internal TA is encrypted signed together with iTrustee
image by Huawei, will be checked signature and decrypted in the secure boot process, External TAs are
encrypted and signed independently by Huawei, will be decrypted and check the signature before
loading into the TOE. The TOE will stop loading TA if tampering detected.
o The TOE will enter a secure state when some key operation error occurred, to protect the TOE’s data
from leaking out.
o The TOE will stop the TSF execution if an integrity error of the TEE runtime data or the TEE
persistent data is detected.
(FPT_TEE.1, FPT_FLS.1, FDP_SDI.2, FMT_SMF.1, FMT_SMR.1)
7.2 Trusted Storage
The TOE provides trusted storage service for its security functions. The trust storage resides in Trusted
core framework. TAs running in the TEE can load or store its owning files through Trusted Storage
service, but any intention to access other TA’s file will be prevented.
o The trusted storage service is the only task that have the permission to access the file in Trusted
Storage. The TOE will reject any request to access trusted file from other tasks.
o The trusted storage service in TOE will receive trusted file access request from other TA, if the request
is illegal or the TA has no permission to access the trusted file, the request will be denied.
CC Huawei iTrustee Software V5.0 Security Target 7 TOE Summary Specification
Copyright © Huawei Technologies Co., Ltd.
53
o The trusted storage service will encrypt the data before write the data into the trusted file, and the
encrypted key is binding to the request TA, Different TA use different key. The trusted storage service
will decrypt the data and send back to the reading request TA.
o If the file write operation failed, The TOE will detect the failure and rollback to previous state.
(FDP_ACC.1/Trusted storage, FDP_ACF.1/Trusted Storage, FDP_ROL.1/Trusted Storage,
FMT_MSA.1/Trusted Storage, FMT_MSA.3/Trusted Storage, FDP_ITT.1/Trusted Storage,
FMT_SMF.1)
7.3 Cryptographic Support
The TOE provides software cryptographic operations to support TOE’s security functions such as CA
Authentication which will verify the signature of CA, TA signature verification, trust storage etc. For
that, The TOE provides a series of cryptographic operations such as hash calculation, HMAC
calculation, signature generation, encryption and decryption in accordance with the cryptographic
algorithms specified in Table 3. The TOE provides also:
O Cryptographic key destruction.
O TA_Keys in accordance with GP Internal API Specification [IAPI], including management of keys
security attributes.
(FCS_COP.1, FDP_ACC.1/TA_Keys, FDP_ACF.1/TA_keys, FMT_MSA.1/TA_keys,
FMT_MSA.3/TA_keys, FCS_CKM.4, FMT_SMF.1)
7.4 User Identification and Authentication
The TOE must identify and authenticate CA when opening a session, by verifying the signature of CA
and checking if the target TA is allowed. After successful authentication, the TOE provides the identity
of CA to the target TA for the white-CA-list comparing. The TOE must identify and authenticate TA by
its signature. Any further actions performing by CA/TA user must be prevent before successful
authentication. Both identifiers of CA and TA cannot be modified during their life cycle.
(FIA_ATD.1, FIA_UID.2, FIA_USB.1)
7.5 Security Audit
The TOE will detect potential security violation such as violation of TA data, TA code or TEE data, and
generate audit log. The TOE will send the log info from TEE to REE, which can be read by human with
tool.
Every audit log record of TOE contains TEE identifier which is generated on-TEE. The users can
retrieve the TEE identifier from the TOE through a proprietary API.
Audit log records are only accessible to the root user, so they are protected from unauthorized deletion
and modification.
(FAU_ARP.1, FAU_SAR.1, FAU_STG.1)
CC Huawei iTrustee Software V5.0 Security Target 7 TOE Summary Specification
Copyright © Huawei Technologies Co., Ltd.
54
7.6 Protection of TA
When TA is loaded, the TSF will check the signature of it so that integrity and authenticity are ensured.
For each loaded TA, the TSF will create an isolated running environment, any reading or writing
accesses from other TAs are forbidden. And TSF will monitor the authenticity and consistency of TA
code, data and keys, when a failure occurs, the TSF will cleanup all those data and the TA will exit.
(FDP_IFC.2/Runtime, FDP_IFF.1/Runtime, FDP_RIP.1/Runtime, FDP_SDI.2)
7.7 Security Instantiation
TEE instantiation through a secure initialization process using assets bound to the SoC that ensures the
authenticity and contributes to the integrity of the TEE code running in the device.
Each step of the startup process contains components that are cryptographically signed to ensure
integrity and that proceed only after verifying the chain of trust. This includes the onchiprom, fastboot,
bootloaders, kernel, and so on. This secure boot chain helps ensure that TOE's instantiation aren't
tampered with.
(FPT_INI.1)
7.8 Reliable time stamps
The TOE get security time from the SoC and provides unified time stamps to all the TAs. The time
stamp provided by the TOE will increase monotonically from the TOE starting-up, no matter the TOE is
running or sleeping.
(FPT_STM.1)
CC Huawei iTrustee Software V5.0 Security Target 8 Abbreviations, Terminology and References
Copyright © Huawei Technologies Co., Ltd.
55
8 Abbreviations,
Terminology and References
8.1 Abbreviations
AES Advanced Encryption Standard (defined in [AES])
CA Client Application
CC Common Criteria
CEM Common Evaluation Methodology
CM Configuration Management
DRM Digital Rights Management
EAL Evaluation Assurance Level
IPC Inter-Process Communication
NFC Near Field Communication
OS Operating System
OSP Organizational Security Policy
PCB Printed Circuit Board
PP Protection Profile
RAM Random Access Memory
REE Rich Execution Environment
RFC Request For Comments
ROM Read Only Memory
RSA Rivest / Shamir / Adleman asymmetric algorithm (defined in [RSA])
SAR Security Assurance Requirement
SE Secure Element
SFR Security Functional Requirement
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm (defined in [SHA])
SoC System-on-Chip
SPD Security Problem Definition
ST Security Target
CC Huawei iTrustee Software V5.0 Security Target 8 Abbreviations, Terminology and References
Copyright © Huawei Technologies Co., Ltd.
56
TA Trusted Application
TEE Trusted Execution Environment
TOE Target of Evaluation
TSF TOE Security Functions
TSS TOE Summary Specification
8.2 Terminology
This section contains definitions of technical terms that are used with a meaning specific to this
document. Terms defined in the [CC1], [CC2] and [CC3] are not reiterated here, unless stated otherwise.
Term Definition
Application
Programming
Interface (API)
A set of rules that software programs can follow to communicate
with each other.
Client Application
(CA)
An application running outside of the Trusted Execution
Environment (TEE) making use of the TEE Client API that
accesses facilities provided by the Trusted Applications inside the
TEE.
Contrast Trusted Application.
Consistency A property of the TEE persistent storage that stands at the same
time for runtime and startup consistency.
Runtime consistency stands for the guarantee that the following
clauses hold:
• Read/Read: Two successful readings from the same storage
location give the same value if the TEE did not write to this
location and the TEE was not reset in between
• Write/Read: A successful reading from a given storage location
gives the value that the TEE last wrote to this location if the TEE
was not reset in between.
Startup consistency stands for the guarantee that the following
clause holds:
• During a given power cycle, the stored data used at startup is
the data for which runtime consistency was enforced on the same
TEE on a previous power cycle.
Consistency implies runtime integrity of what is unsuccessfully
written and read back – values or code. However the stored data
used at startup may be restored from an old power cycle, not the
latest one. It is still consistent at start-up because it corresponds to a
memory snapshot at a given time, but it represents an integrity loss
compared with the latest power cycle.
This notion is weaker than integrity that must be preserved between
power cycles.
Device binding Device binding is the property of data being only usable on a
unique given system instance, here a TEE.
Execution
Environment
(EE)
A set of hardware and software components that provide facilities
(computing, memory management, input/out, etc.) necessary to
support applications.
Monotonicity Monotonicity is the property of a variable whose value is either
always increasing or always decreasing over time.
Power cycle A power cycle is the lapse between the moment a device is turned
on and the moment the device is turned off afterwards.
CC Huawei iTrustee Software V5.0 Security Target 8 Abbreviations, Terminology and References
Copyright © Huawei Technologies Co., Ltd.
57
Production TEE A TEE residing in a device that is in the end user phase of its life
cycle.
REE
Communication
Agent
An REE Rich OS driver that enables communication between the
REE and the TEE.
Contrast TEE Communication Agent.
Rich Execution
Environment
(REE)
An environment that is provided and governed by a Rich OS,
potentially in conjunction with other supporting operating systems
and hypervisors; it is outside of the TEE. This environment and
applications running on it are considered un-trusted.
Contrast Trusted Execution Environment.
Rich OS Typically an OS providing a much wider variety of features than
that of the OS running inside the TEE. It may be very open in its
ability to accept applications. It will have been developed with
functionality and performance as key goals, rather than security.
Due to the size and needs of the Rich OS it will run in an execution
environment that may be larger than the TEE hardware (often
called an REE – Rich Execution Environment) with much lower
physical security boundaries. From the TEE viewpoint, everything
in the REE has to be considered un-trusted, though from the Rich
OS point of view there may be internal trust structures.
Contrast Trusted OS.
Root of Trust
(RoT)
Generally the smallest distinguishable set of hardware, firmware,
and/or software that must be inherently trusted and which is closely
tied to the logic and environment on which it performs its trusted
actions.
System-on-Chip
(SoC)
An electronic system all of whose components are included in a
single integrated circuit.
TA instance time /
TA
persistent time
Time value available to a Trusted Application through the TEE
Internal API. The API offers two types of time values: System
Time, which exists only during runtime, and Persistent time, which
persists over resets. System Time must be monotonic for a given
TA instance, and the returned value is called “TA instance time”.
Persistent time depends only on the TA but not on a particular
instance, it must be monotonic even across power cycles. Its
monotonicity across power cycles is related to the Time and
Rollback optional PP-module [TEE PP].
TEE Client API The software interface used by clients running in the REE to
communicate with the TEE and with the Trusted Applications
executed by the TEE.
TEE
Communication
Agent
A TEE Trusted OS driver that enables communication between
REE and TEE. Contrast REE Communication Agent.
TEE Internal API The software interface exposing TEE functionality to Trusted
Applications.
TEE Service
Library
A software library that includes all security related drivers.
Trusted
Application (TA)
An application running inside the Trusted Execution Environment
that exports security related functionality to Client Applications
outside of the TEE.
Contrast Client Application.
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 can access, and resists a set of defined threats. There are
CC Huawei iTrustee Software V5.0 Security Target 8 Abbreviations, Terminology and References
Copyright © Huawei Technologies Co., Ltd.
58
multiple technologies that can be used to implement a TEE, and the
level of security achieved varies accordingly. For more
information, see OMTP ATE TR1 [OMTP-TR1].
Contrast Rich Execution Environment.
Trusted OS The operating system running in the TEE. It has been designed
primarily to enable the TEE using security-based design
techniques. It provides the GlobalPlatform TEE Internal API to
Trusted Applications and a proprietary method to enable the
GlobalPlatform TEE Client API software interface from other EE.
Contrast Rich OS.
Trusted Storage In GlobalPlatform TEE documents, trusted storage indicates
storage that is protected to at least the robustness level defined for
OMTP Secure Storage (in section 5 of [OMTP-TR1]). It is
protected either by the hardware of the TEE, or cryptographically
by keys held in the TEE. If keys are used they are at least of the
strength used to instantiate the TEE. A GlobalPlatform TEE
Trusted Storage is not considered hardware tamper resistant to the
levels achieved by Secure Elements.
8.3 References
[CC1] Common Criteria for Information Technology Security Evaluation, Part
1: Introduction and general model. Version 3.1. Revision 5. April 2017.
CCMB-2017-04-001.
[CC2] Common Criteria for Information Technology Security Evaluation, Part
2: Security functional requirements. Version 3.1. Revision 5. April 2017.
CCMB-2017-04-002.
[CC3] Common Criteria for Information Technology Security Evaluation, Part
3: Security assurance requirements. Version 3.1. Revision 5. April 2017.
CCMB-2017-04-003.
[TEE PP] GlobalPlatform Device Committee - TEE Protection Profile Version
1.2.1, Public Release November 2016, Document Reference:
GPD_SPE_021
[OMTP-TR1] Open Mobile Terminal Platform Advanced Trusted Environment
OMTP TR1 v1.1
[WP] The Trusted Execution Environment: Delivering Enhanced Security at a
Lower Cost to the Mobile Market, GlobalPlatform White paper, Feb
2011
[SA] TEE System Architecture, GlobalPlatform (Last applicable version)
[IAPI] TEE Internal API Specification, GlobalPlatform (Last applicable version)
[CAPI] TEE Client API Specification, GlobalPlatform (Last applicable version)
[AES] ADVANCED ENCRYPTION STANDARD (AES). FIPS PUB 197.
November 2011.
[RSA] RSA Cryptographic Standard. PCKS#1 v2.2. October 2012
[SHA] SECURE HASH STANDARD. FIPS PUB 180-4. March 2012
END