GP CA接口：TEE Client API V1.0官方规范与专利声明

需积分: 10 8 浏览量更新于2024-07-18 收藏 825KB PDF 举报

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

领优惠券(最高得80元）

"TEE_Client_API_Specification-V1.0_c.pdf" 是 GlobalPlatform (GP) 发布的一份接口规格文档，专注于 Trusted Execution Environment (TEE) 客户端API的详细规范。该文档版权属于 GlobalPlatform Inc.，自2010年7月公开发布以来，版本为1.0。这份技术文档旨在为TEE客户端应用程序开发者提供一套安全、可信的编程接口，以便在设备上执行隔离的、受保护的操作，例如加密数据处理或执行敏感应用。文档的核心内容包括对TEE技术的概述，强调了它如何确保在设备硬件层面上实现数据的隐私和完整性。它邀请接收者在发现可能因实施本规格而侵犯的专利权或其他知识产权时，提交相关信息，并附带支持性文档。由于TEE技术的性质，它可能会不断更新、修订和扩展，因此任何使用此规格的信息都必须遵循GlobalPlatform的许可协议，未经授权的使用是被严格禁止的。 "GP CA" 标签表明文档与GlobalPlatform的证书授权(Certificate Authority, CA)功能有关，这可能是文档中涉及TEE客户端API的一个子集，可能涉及到安全证书的生成、管理和使用，以保证TEE环境中通信的可信性。该文档详细描述了API的不同组件，包括但不限于认证流程、数据封装和解封装、安全操作环境的创建和管理，以及错误处理和异常情况的处理机制。开发者指南中会包含接口的调用方法、参数说明和返回值解读，以确保兼容性和正确实施。此外，文档还强调了保密性和合规性的重要性，因为TEE客户端API的设计目的是在高度受限的环境下运行，这可能涉及到金融交易、医疗记录等敏感信息的处理。遵循该规格的开发人员需要遵守严格的隐私政策和数据保护法规。阅读和理解"TEE_Client_API_Specification-V1.0_c.pdf"对于想要利用TEE技术构建安全应用的开发者来说，是一项关键任务，它提供了实现可信赖执行环境的必要蓝图，确保了在移动设备、嵌入式系统等场景下的安全性与效率。

资源详情

资源推荐

TEE Client API Specification 10/58

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.

3. Principles and Concepts

This section explains the underlying principles and concepts of the TEE Client API in detail, explaining

how each class of features should be used.

3.1. Design Principles

The key design principles of the TEE Client API are:

 C language:

o C is the common denominator for practically all of the application frameworks and

operating systems hosting Client Applications.

o It is accepted that alternative language bindings – such as a Java API – may be needed in

the future, but these are outside of the scope of this specification.

 Blocking functions:

o Most Client Application developers are familiar with synchronous functions which block

waiting for the underlying task to complete before returning to the calling code. An

asynchronous interface is hard to design, hard to port in rich OS environments, and is

generally difficult to use for developers familiar with synchronous APIs.

o In addition it is assumed that multi-threading support is available on all target platforms;

this is required for Implementations to support cancellation of blocking API functions.

 Source-level portability:

o To enable compile-time and design-time optimization, this standard places no requirement

on binary compatibility. Client Application developers will need to recompile their code

against an appropriate implementation-defined version of the TEE Client API headers in

order to function correctly on that Implementation.

 Client-side memory allocations:

o Where possible the design of the TEE Client API has placed the responsibility for memory

allocation on the calling Client Application code. This gives the Client developer choice of

memory allocation locations, enabling simple optimizations such as stack-based allocation

or enhanced flexibility using placements in static global memory or thread-local storage.

o This design choice is evident in the API by the use of pointers to structures rather than

opaque handles to represent any manipulated objects.

 Aim for zero-copy data transfer:

o The features of the TEE Client API are chosen to maximize the possibility of zero-copy

data transfer between the Client Application and the Trusted Application, provided that the

host operating system and hardware implementation can support it. This minimizes

communications overhead and improves software efficiency, especially on cached

processors where data copies are an expensive operation because of the cache pollution

they cause.

o However, short messages can also be passed by copy, which avoids the overhead of

sharing memory.

 Support memory sharing by pointers:

o The TEE Client API will be used to implement higher-level APIs, such as cryptography or

secure storage, where the caller will often provide memory buffers for input or output data

using simple C pointers. The TEE Client API must allow efficient sharing of this type of

memory, and as such does not rely on the Client Application being able to use bulk

memory buffers allocated by the TEE Client API.

11/58 TEE Client API Specification

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.

 Specify only communication mechanisms:

o This API focuses on defining the underlying communications channel. It does not define

the format of the messages which pass over the channel, or the protocols used by specific

Trusted Applications. These must be defined in other specifications.

3.2. Fundamental Concepts

This section outlines the behavior of the TEE Client API, and introduces key concepts and terminology.

3.2.1. TEE Contexts

A TEE Context is an abstraction of the logical connection which exists between a Client Application and a

TEE. A TEE Context must be initialized before a Session can be created between the Client Application

and a Trusted Application running within the TEE which that TEE Context represents. The TEE Context

should be finalized when the connection with the TEE is no longer required, allowing resources to be

released.

It is possible for a Client Application to initialize multiple TEE Contexts concurrently, either with the same

underlying TEE, or with multiple TEEs if they are available. The number of concurrent contexts which may

exist is implementation-defined, and may additionally depend on run-time resource constraints.

3.2.2. Sessions

A Session is an abstraction of the logical connection which exists between a Client Application and a

specific Trusted Application. A Session is opened by the Client Application within the scope of a particular

TEE Context. The number of concurrent Sessions which may exist is implementation-defined, depending

on the design of the TEE and the Trusted Applications in use, and may additionally depend on run-time

resource constraints.

When creating a new Session the Client Application must identify the Trusted Applications which it wishes

to connect to using the Universally Unique IDentifier (UUID) of the Trusted Application. The open session

operation allows an initial data exchange to be made with the Trusted Application, if this is required in the

protocol between the Client Application and the Trusted Application.

Connection Methods: Login

Some Trusted Applications may require the Implementation to identify or authenticate the Client

Application or the user executing it. For example, a Trusted Application may restrict access to the data or

functionality it provides based on the identity of the user running the Client Application in the rich operating

environment. When opening a Session the Client Application can nominate which connection method it

wants to use and hence which login credentials are presented to the TEE or Trusted Application. It is likely

that the connection method will form part of the protocol exposed by the Trusted Application in use;

attempting to open a Session with an incorrect connection method may result in a failed attempt.

3.2.3. Commands

A Command is the unit of communication between a Client Application and a Trusted Application within a

Session. When starting a new Command the Client Application identifies the function in the Trusted

Application which it wishes to execute by passing a numeric identifier, and may also provide an operation

payload in accordance with the protocol the Trusted Application exposes for that function. The Command

invocation blocks the Client Application thread, waiting for an answer from the Trusted Application. A

Client Application may use multiple threads to have multiple Commands which are outstanding

concurrently. The number of concurrent Commands which may exist is implementation-defined,

depending on the design of the TEE and the Trusted Applications in use, and may additionally depend on

run-time resource constraints.

TEE Client API Specification 12/58

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.

Operation Payload

An operation to open a Session or to invoke a generic Command can carry an optional payload, the

definition of which is passed inside a set of Operation Parameters (see section 3.2.5) stored in the

operation structure. In this version of the specification up to 4 Parameters can be specified for each

operation.

Each Parameter is either a Memory Reference or a Value Parameter and is associated with a direction: it

can be input, output, or both input and output. For Memory Reference Parameters, the specified direction

of data flow determines when the underlying memory buffers need to be synchronized with the Trusted

Application.

Memory Reference Parameters are used to exchange data through shared memory buffers. Value

Parameters carry a small amount of data in the form of two 32-bit integers without the burden of sharing or

synchronizing memory.

The format of the data structures held in the Memory References or Value Parameters is defined by the

protocol of the Trusted Application function in use, and hence outside of the scope of this specification.

Temporary Shared Memory Registration

Memory References refer either to a Registered Memory Reference or a Temporary Memory Reference:

 a Registered Memory Reference is a region within a block of Shared Memory (see section 3.2.4)

that was created before the operation

 a Temporary Memory Reference directly specifies a buffer of memory owned by the Client

Application, which is temporarily registered by the TEE Client API for the duration of the operation

being performed

A Temporary Memory Reference may be null, which can be used to denote a special case for the

parameter. Output Memory References that are null are typically used to request the required output size.

Return Codes and Return Origins

The answer to an open Session and a invoke Command operation always contains a Return code, which

is a 32-bit numeric value indicating success or the reason for failure, and an Return origin, which is a 32-

bit numeric value indicating the source of the return code in the Implementation. The standard error codes

and return origins are described in sections 4.4.2 and 4.4.3.

When the return origin is TEEC_ORIGIN_TRUSTED_APP then the return code is defined by the Trusted

Application‟s protocol. Note that, critically, this means that a Client Application cannot just test against

TEEC_SUCCESS, as the Trusted Application may use another code to indicate success. To enable simpler

error handling code in the Client Application it is recommended that the Trusted Application developers

choose „0‟ as their literal value of their success return code constant.

Events and Callbacks

This specification does not define a primitive way for a Trusted Application to spontaneously signal an

event to the Client Application or perform callbacks to the Client code. However, these types of usage

patterns can be constructed using Commands. For example, event signals can be implemented by having

the Client Application send a Command which blocks inside the Trusted Application until the event occurs

inside the TEE. When the event occurs the Trusted Application passes control back to the Client

Application; the TEEC_InvokeCommand will return and the Client Application can handle the event which

was signaled.

剩余57页未读，继续阅读

ningshao1945

粉丝: 2
资源: 11

GP CA接口：TEE Client API V1.0官方规范与专利声明

TEE_Client_API_Specification-V1.0_c_watermark.pdf

可信执行环境（TEE）相关资料_inse工具是什么_inse工具_inSEtee_inSE工具_teeinse区别_

GPD_TEE_Internal_API_Specification_v1.0.pdf

tee_client_api_specification-v1.0_c.pdf

gst-launch-1.0的各种插件使用

TEE_STORAGE_PRIVATE_REE

./tools/chef_deploy_quick.sh chef_json_common.json | tee -a deploy.out，这条命令什么意思

Error downloading packages: 3:docker-ce-24.0.7-1.el7.x86_64: [Errno 256] No more mirrors to try.

停止gstreamer录像管道pipeline的linux命令

MTK_TEE_DRAM_SIZE = 0x5500000，扩大怎么扩大

OP-TEE xtest

帮我写一份linux优化脚本

这条命令什么意思./tools/chef_deploy_quick.sh | tee -a deploy.out

set -x CFG_PATH=$1 DIR=$2 PORT=$3 mkdir -p ./outputs/$DIR TIME=$(date +"%Y%m%d_%H%M%S") python -u main.py \ --cfg_path $CFG_PATH \ --output_dir ./outputs/$DIR \ --time_str $TIME \ --port ${PORT} \ 2>&1 | tee ./outputs/$DIR/$TIME.log

echo "FGP_AFFINITY_FAILED found, OPTS_TRY_ALL_HOST is $OPTS_TRY_ALL_HOST" | tee -a subloop.log翻译成python

最新资源