GlobalPlatform TEE规范文档：内部核心API规格说明

TrustZone

需积分: 10 166 浏览量更新于2024-07-18 收藏 2.82MB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"该资源包含了GlobalPlatform组织关于TEE(Trusted Execution Environment)的相关规范文档，主要是TEE内部核心API规格书的版本1.1公开发布版。这些文档对于研究TrustZone技术以及OP-TEE等相关安全技术极具参考价值。由于官方网站访问不便，这些资料被下载并分享给需要的同学。" 在信息安全领域，TEE(Trusted Execution Environment)是一种隔离的安全环境，它与主操作系统（通常称为非受信执行环境，Untrusted Execution Environment, UEE）并存，用于保护敏感数据和关键操作。GlobalPlatform是一个国际组织，致力于制定标准，确保设备上的应用和服务能够安全、高效地运行。该组织的规范涉及TEE的实现，以确保跨平台的兼容性和安全性。 "TEEInternalCoreAPISpecification"是GlobalPlatform定义的核心API规范，版本1.1，是开发人员实现和集成TEE服务的重要指南。这个API接口定义了在TEE中运行的可信应用程序（Trusted Applications, TAs）如何与TEE交互，以及如何与外部的非可信应用程序或服务通信。它涵盖了数据管理、安全功能调用、会话管理等多个方面，确保了在TEE内的操作不可被非信任环境篡改或窃取。 TrustZone是ARM架构中实现TEE的一种常见技术，它通过硬件级别的隔离，创建两个独立的安全域：一个为非受信域，运行常规的操作系统和应用；另一个为受信域，提供高度安全的执行环境。OP-TEE（Open Platform TEE）是一个开源项目，实现了GlobalPlatform的TEE规范，允许开发者在TrustZone上构建可信服务。 DRM（Digital Rights Management）则可能与TEE关联，因为TEE可以提供一个安全的环境来执行版权保护的算法，确保数字内容的版权不被侵犯。在这样的环境中，DRM系统可以更有效地控制和管理数字媒体的使用和分发，防止非法复制或共享。在使用这些文档时，需要注意GlobalPlatform的版权声明，使用者需要遵守其许可协议，任何不符合协议的使用都是禁止的。同时，由于技术不断发展，这些规范可能会有更新、修订或扩展，因此，开发者应当保持对最新版本的关注，以便获取最准确的信息。这个资源对于那些希望深入理解TEE、TrustZone、OP-TEE以及与之相关的DRM技术的开发者或研究人员来说，是一个宝贵的参考资料。通过学习和应用这些规范，可以更好地实现设备的安全功能，并开发出符合全球标准的安全应用。

资源详情

资源推荐

16/239 TEE Internal Core API Specification – Public Release v1.1



The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is

governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

1.5 Abbreviations and Notations

Table 1-3: Abbreviations

Term

Definition

AAD Additional Authenticated Data

AE Authenticated Encryption

AES Advanced Encryption Standard

API Application Programming Interface

CA Client Application

CMAC Cipher-based MAC

CRT Chinese Remainder Theorem

CTS CipherText Stealing

DES Data Encryption Standard

DH Diffie-Hellman

DSA Digital Signature Algorithm

ECDH Elliptic Curve Diffie-Hellman

ECDSA Elliptic Curve Digital Signature Algorithm

ETSI European Telecommunications Standards Institute

gcd Greatest Common Divisor

HMAC Hash-based Message Authentication Code

IEEE Institute of Electrical and Electronics Engineers

IETF Internet Engineering Task Force

IPR Intellectual Property Rights

ISO International Organization for Standardization

IV Initialization Vector

MAC Message Authentication Code

MD5 Message Digest 5

MGF Mask Generating Function

NIST National Institute of Standards and Technology

OAEP Optimal Asymmetric Encryption Padding

OS Operating System

PKCS Public Key Cryptography Standards

PSS Probabilistic Signature Scheme

REE Rich Execution Environment

RFC Request For Comments; may denote a memorandum published by the IETF

18/239 TEE Internal Core API Specification – Public Release v1.1



The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is

governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

2 Overview of the TEE Internal Core API

This specification defines a set of C APIs for the development of Trusted Applications (TAs) running inside

a Trusted Execution Environment (TEE). For the purposes of this document a TEE is expected to meet

the requirements defined in [Sys Arch], i.e. it is accessible from a Rich Execution Environment (REE)

through the GlobalPlatform TEE Client API [Client API] but is specifically protected against malicious attacks

and runs only code trusted in integrity and authenticity.

A TEE provides the Trusted Applications an execution environment with defined security boundaries, a set of

security enabling capabilities, and means to communicate with Client Applications running in the Rich

Execution Environment. This document specifies how to use these capabilities and communication means

for Trusted Applications developed using the C programming language. It does not cover how Trusted

Applications are installed or managed and does not cover other language bindings.

2.1 Trusted Applications

A Trusted Application (TA) is a program that runs in a Trusted Execution Environment (TEE) and exposes

security services to its Clients.

A Trusted Application is command-oriented. Clients access a Trusted Application by opening a session with

the Trusted Application and invoking commands within the session. When a Trusted Application receives a

command, it parses the messages associated with the command, performs any required processing, and

then sends a response back to the client.

A Client typically runs in the Rich Execution Environment and communicates with a Trusted Application using

the TEE Client API [Client API]. It is then called a “Client Application”. It is also possible for a Trusted

Application to act as a client of another Trusted Application, using the Internal Client API (see section 4.9).

The term “Client” covers both cases.

20/239 TEE Internal Core API Specification – Public Release v1.1



The technology provided or described herein is subject to updates, revisions, and extensions by GlobalPlatform. Use of this information is

governed by the GlobalPlatform license agreement and any use inconsistent with that agreement is strictly prohibited.

2.1.2 Instances, Sessions, Tasks, and Commands

When a Client creates a session with a Trusted Application, it connects to an Instance of that Trusted

Application. A Trusted Application instance has physical memory space which is separated from the physical

memory space of all other Trusted Application instances. The Trusted Application instance memory space

holds the Trusted Application instance heap and writable global and static data.

All code executed in a Trusted Application is said to be executed by Tasks. A Task keeps a record of its

execution history (typically realized with a stack) and current execution state. This record is collectively called

a Task context. A Task MUST be created each time the Trusted OS calls an entry point of the Trusted

Application. Once the entry point has returned, an Implementation may recycle a Task to call another entry

point but this MUST appear like a completely new Task was created to call the new entry point.

A Session is used to logically connect multiple commands invoked in a Trusted Application. Each session

has its own state, which typically contains the session context and the context(s) of the Task(s) executing the

session.

A Command is issued within the context of a session and contains a Command Identifier, which is a 32-bit

integer, and four Operation Parameters, which can contain integer values or references to client-owned

shared memory blocks.

It is up to the Trusted Application to define the combinations of commands and their parameters that are

valid to execute. This is outside the scope of this specification.

2.1.3 Sequential Execution of Entry Points

All entry point calls within a given Trusted Application instance are called in sequence, i.e. no more than one

entry point is executed at any point in time. The Trusted Core Framework implementation MUST guarantee

that a commenced entry point call is completed before any new entry point call is allowed to begin execution.

If there is more than one entry point call to complete at any point in time, all but one call MUST be queued by

the Framework. The order in which the Framework queues and picks enqueued calls for execution is

implementation-defined.

It is not possible to execute multiple concurrent commands within a session. The TEE guarantees that a

pending command has completed before a new command is executed.

Since all entry points of a given Trusted Application instance are called in sequence, there is no need to use

any dedicated synchronization mechanisms to maintain consistency of any Trusted Application instance

memory. The sequential execution of entry points inherently guarantees this consistency.

2.1.4 Cancellations

Clients can request the cancellation of open-session and invoke-command operations at any time.

If an operation is requested to be cancelled and has not reached the Trusted Application yet but has been

queued, then the operation is simply retired from the queue.

If the operation has already been transmitted to the Trusted Application, then the task running the operation

is put in the cancelled state. This has an effect on a few “cancellable” functions, such as

TEE_Wait, but this

effect may also be masked by the Trusted Application if it does not want to be affected by client

cancellations. See section 4.10 for more details on how a Trusted Application can handle cancellation

requests and mask their effect.

剩余238页未读，继续阅读

ljk02079

粉丝: 0
资源: 27

GlobalPlatform TEE规范文档：内部核心API规格说明

GP TEE Internal API v1.1

TEE相关文档合集（GlobalPaltform组织）

GPD_TEE_Internal_API_Specification_v1.0.pdf

tee_client_api_specification-v1.0_c.pdf

Android TEE基本框架

TEE占用或分配的内存大小

带tee加载脚本和不带tee加载脚本有甚区别

TEE如何实施加密过程

tee

trusty TEE加密操作

tee 支付安全 存储区域

sudo tee 的使用

tee internal core api specification v1.2.1下载

TEE_STORAGE_PRIVATE_REE

gstreamer tee 怎样使用

linux终端tee

Full TEE和半TEE的区别

TEE Internal APIs

tee实现信任根公钥保护

gpd_tee_protectionprofile_v1.3

最新资源

tee 支付安全存储区域