TrustZone API 3.0：安全通信规范

5星 · 超过95%的资源需积分: 10 17 浏览量更新于2024-07-26 5 收藏 640KB PDF 举报

"TrustZone_API_3.0_Specification" TrustZone API 3.0 规范是ARM公司发布的一个安全应用编程接口，用于在通用操作系统中运行的应用程序与专用安全环境之间进行高效且可靠的通信。这个API最初设计的目标是连接一个富操作系统和在ARM处理器上实现ARM架构安全扩展的安全中间件环境。它旨在解决由于缺乏统一的软件开发标准而阻碍安全软件发展的难题。规范的主要内容包括以下几个方面： 1. **接口定义**：TrustZone API定义了一组接口，允许普通应用程序与信任区（TrustZone）内的安全服务进行交互。这些接口通常包括数据传输、服务请求和状态查询等功能，确保了在不同操作系统和安全环境之间的通信安全和高效。 2. **安全通信机制**：API提供了加密和完整性保护的通信机制，以防止在非安全世界与安全世界之间的数据传输过程中被恶意篡改或窃取。这可能包括使用安全通道、密钥管理以及数据认证等技术。 3. **权限管理**：TrustZone API包含了权限管理机制，确保只有经过授权的应用程序才能访问特定的安全服务。这涉及到权限验证和权限控制策略，以防止未授权的访问和滥用。 4. **隔离与隔离级别**：API支持不同的隔离级别，以保护敏感数据和服务免受攻击。这可能涉及对内存、处理器资源以及系统调用的隔离，确保安全域与其他域之间的隔离性。 5. **错误处理与异常管理**：规范详细定义了错误处理机制，包括错误代码、异常处理和恢复流程，以确保在出现故障或攻击时系统的稳定性和恢复能力。 6. **兼容性与可扩展性**：TrustZone API 3.0设计时考虑了与不同安全平台和硬件架构的兼容性，使得第三方供应商可以将其作为接口集成到自己的安全解决方案中。同时，API的可扩展性意味着它可以随着技术的发展而演进，适应新的安全需求。 7. **版本控制与更新**：文档中的版本号（3.0）表明了该API的成熟度和更新历史。开发者可以通过版本号了解API的改进和新增功能，以便于升级和维护。 8. **应用示例**：尽管规范本身可能不包含具体的应用示例，但通常会提供一些应用场景，如移动支付、数字版权管理、身份验证和隐私保护等，帮助开发者理解和使用API。 9. **文档结构**：规范通常包括前言、内容目录、技术细节、使用指南、错误处理和参考信息等多个部分，便于读者查阅和理解。 TrustZone API 3.0 的发布，为开发安全软件提供了标准化的工具，促进了不同厂商之间的互操作性，降低了安全解决方案的开发成本，并有助于构建更安全的生态系统。通过遵循这一规范，安全平台供应商可以提供一致且可靠的服务，同时为应用程序开发者提供了开发安全功能的统一接口。

TrustZone API Specification

PRD29-USGC-000089 3.1 ARM Confidential Page 14 of 82

/* Send the open command to the service. */

uiReturn = TZOperationPerform(

&psOperation, /* Operation structure. */

&uiSvcReturn); /* Return if service error occurs. */

/* Handle error. */

if (uiReturn != TZ_SUCCESS)

{

if(uiReturn == TZ_ERROR_SERVICE)

{

/* Service threw an error – stored in uiSvcReturn. */

/* Can use decoder functions if it sent a message. */

}

else

{

/* System threw an error – stored in uiReturn. */

/* Cannot use decoder functions. */

}

goto exit;

}

/* If here then service returned success - session is open. */

/* Decoder an answer message, if we expect any. For example: */

uiAnswer = TZDecodeUint32(&sOperation);

/* Check decoder has not errored. */

uiReturn = TZDecodeGetError(&sOperation);

if(uiReturn != TZ_SUCCESS)

{

/* A decode error occurred - for example, a type mismatch. */

}

/* Release the operation context: */

exit:

TZOperationRelease(&sOperation);

4.2.3 Invoking service commands

Once a client session is opened, a client can invoke service commands. A command is composed of a

command identifier, which is an unsigned 32-bit integer, and an optional structured message. The service’s

response to a command consists of an unsigned 32-bit return code and an optional answer message.

The protocol that defines the available command identifiers, and the required contents of the messages for each

command, are specific to each service – these must be documented by the service provider.

To invoke a service command, the client must perform the following steps:

1. Prepare the invoke operation using the TZOperationPrepareInvoke function. The client must pass a pointer

to an existing session opened with the service and the required command identifier. Calling this function

allows the implementation to allocate the operation context locally; the implementation will not generally

send anything to the device or service at this stage. When this function returns, the client code can call the

encoder functions to encode a structured message to send to the service.

2. Fill in the command message using the encoder functions. It is acceptable to send an empty message to the

service if no arguments are required; in this case, it is not necessary to call any encoder functions.

3. Call the function TZOperationPerform, or the asynchronous equivalent, to send the command to the service.

The service will process the arguments in the message and can optionally return a new message containing

TrustZone API Specification

PRD29-USGC-000089 3.1 ARM Confidential Page 15 of 82

output from the invoke operation. Once operation perform stage has been started it is not valid to use the

encoder API functions. It is not valid to use the decoder API functions until the perform stage has completed.

4. Decode the service’s answer, if any, using the decoder functions and the decoder handle.

5. Finally, release the operation context using the function TZOperationRelease. This step frees the decoder

used by this operation, allowing it to be used for new commands. The client must have read all data it

requires from the decoder memory before calling this function. The client must call this function even if the

perform function fails, or if the service’s response contains no answer message.

The following code example shows the sequence of operations required to prepare, perform and release a

perform command operation within a service.

tz_device_t sDevice; /* Device connection. */

tz_session_t sSession; /* Service session. */

tz_return_t uiReturn; /* Return value from system. */

tz_return_t uiSvcReturn; /* Return value from service. */

tz_operation_t sOperation; /* Uninitialized operation. */

uint32_t uiAnswer; /* Variable to hold service answer. */

/* Open device connection. */

...

/* Open a service session. */

...

/* Prepare the Invoke operation. */

uiReturn = TZOperationPrepareInvoke(

&sSession, /* An open session. */

42, /* The ID of the command to invoke. */

NULL, /* No time limit. */

&sOperation); /* Operation structure. */

/* Handle error. */

if (uiReturn != TZ_SUCCESS)

{

/* Could not create an Invoke operation for some reason. */

goto exit;

}

/* Encode structured message. */

/* This step may be omitted if the service requires no message. */

TZEncodeUint32(&sOperation, 0x76543210);

/* Send the Invoke command to the service. */

uiReturn = TZOperationPerform(

&psOperation, /* Operation structure. */

&uiSvcReturn); /* Return if service error occurs. */

TrustZone API Specification

PRD29-USGC-000089 3.1 ARM Confidential Page 16 of 82

/* Handle error. */

if (uiReturn != TZ_SUCCESS)

{

if(uiReturn == TZ_ERROR_SERVICE)

{

/* Service threw an error – stored in uiSvcReturn. */

/* Can use decoder functions if it sent a message. */

}

else

{

/* System threw an error – stored in uiReturn. */

/* Cannot use decoder functions. */

}

goto exit;

}

/* If here then service returned success - session is open. */

/* Decode an answer message, if we expect any. For example: */

uiAnswer = TZDecodeUint32(&sOperation);

/* Check decoder hasn not errored. */

uiReturn = TZDecodeGetError(&sOperation);

if(uiReturn != TZ_SUCCESS)

{

/* A decode error occurred; for example a type mismatch. */

}

/* Release the operation context. */

exit:

TZOperationRelease(&sOperation);

4.2.4 Closing a client session

When a client no longer needs to access a service it can close the session. To close a session, the client must

perform the following steps:

1. Prepare the close operation using the TZOperationPrepareClose function. The client must pass an open

session to this function. Calling this function allows the implementation to allocate the operation context

locally; the implementation will not generally send anything to the device or service at this stage.

2. It is not valid to use the encoder functions when constructing a close operation as the operation cannot carry

a payload.

3. Call the function TZOperationPerform, or the asynchronous equivalent, to connect to the service and send

the close message.

4. It is not valid to use the decoder functions when receiving the response to a close operation; it may carry no

payload.

5. Finally, release the operation context using the function TZOperationRelease. This final stage also releases

the client session; the session is no longer valid after this point.

4.3 Encoding and decoding structured messages

A client uses the TZAPI to encode and decode structured messages exchanged with a service. Structured

messages are a convenient way to develop a robust protocol between the client and a service – enabling an

implementation to provide type safety and defensive protection against buffer overflow issues. Structured

messages can contain three data types: 32-bit unsigned integers, binary arrays, and a complex type

representing a shared memory reference.

TrustZone API Specification

PRD29-USGC-000089 3.1 ARM Confidential Page 17 of 82

Structured messages are strongly-typed; whenever an attempt is made to decode a parameter in a message,

only the decode function corresponding to the actual type of the parameter can succeed. Strongly-typed

structured messages are an effective and centralized protection to type mismatch or buffer overflow attacks,

where a client attempts to send an ill-formed message to a service.

Messages created using the TZAPI are encoded and decoded in first-in-first-out order. That is, messages must

be decoded in the same order as that in which they were encoded.

4.3.1 Encoding data

The TZAPI automatically creates an encoder when it is valid for a client to send a message to a service, i.e.

whenever the client calls one of the TZOperationPrepare* functions. An encoder is created for the operation

when these prepare operations return success; this is represented by a state change in the operation object. The

client can then make use of the API encoder functions to construct the message sent to the service.

A specific function is defined for each data type to be encoded. The names of the encoder functions start with

the prefix TZEncode*. Array encoding allows a zero-copy implementation by allowing a client to encode a space

of known size in the encoder memory, a pointer to which is then returned to the client. The client can then

generate the data to place into the encoded space in the array before issuing the command to the service.

4.3.2 Decoding data

When an operation has completed, the decoder functions allow the client to decode the service’s response,

subject to the following constraints:

• Where the implementation returns

TZ_SUCCESS or TZ_ERROR_SERVICE, the TZAPI implementation

must return a valid decoder even if the service’s response did not include any message – a decoder

containing no data must be returned if this is the case.

• Where the implementation returns an error code which is neither

TZ_SUCCESS, nor

TZ_ERROR_SERVICE, the decoder is not generated and the decoder functions must not be called by the

client.

A specific function is defined in the TZAPI for each data type which can be decoded. As mentioned previously, in

order for a message to be decoded successfully, the sequence of data types extracted from a message must

match the order in which the message was originally encoded.

The names of the decoder functions start with the prefix TZDecode*. The function TZDecodeArraySpace returns

a pointer to a memory buffer owned by the decoder. The client code must finish using the data in the array slot,

or copy it to a safe location in client owned memory, before releasing the operation for which the decoder was

created.

4.3.3 Empty and NULL arrays

Memory arrays can have zero elements (empty) and can also be NULL. The TZAPI encoders and decoders treat

each of these and an independent case and these can be identified uniquely on decode.

4.3.4 Handling encoder and decoder errors

The TZAPI optimizes error management for encoders and decoders by storing an error state in the encoder or

decoder instance.

The encode functions return no error code. If an error occurs, for example an invalid parameter or an out-of-

memory error, the TZAPI implementation sets the encoder error state. When the client then tries to perform the

operation the API will return the error immediately without issuing the command to the secure environment.

There is no mechanism to reset an encoder once an error has occurred – the operation must be released and a

new one created.

The decode functions also return no error code, and similarly set the decoder error state if an error condition

occurs. When the client wants to check that no decoding error has yet occurred, it can call the function

TZDecodeGetError to retrieve the decoder error state. This helps to optimize the client code size because the

client typically needs to check the decoder error state only when the whole message has been decoded.

The following code sequence decodes a sequence of parameters, and checks the error state at the end of the

decode sequence:

剩余81页未读，继续阅读

atemis

粉丝: 0
资源: 5

TrustZone API 3.0：安全通信规范

TrustZone示例代码

TrustZone API文档

Trustzone 白皮书

TrustZone_and_TEE_Whitepaper

trustzone_security_whitepaper

ARM_trustzone_security_whitepaper

Tech_seminar_TrustZone_v7_PUBLIC.pdf

trustzone_security_whitepaper.pdf

DS-5_TrustZone_example

TrustZone_for_Armv8-A.pdf

最新资源