Rate This Document
Findability
Accuracy
Completeness
Readability

Remote and Local Attestation

Introduction

The TrustZone TEE runs on a physical server. In most scenarios, the physical server is on the device side. ISVs deploy TAs in the TEE on the device side and remotely process their confidential data. To ensure that the service TA works as expected, the remote or local attestation solution is generally adopted. The TA runtime environment verifies the TA integrity.

For details about how to use this feature, see Remote and Local Attestation.

Figure 1 Overall architecture
  • iTrustee SDK: It is a developer tool for the secure OS iTrustee and is used to generate TA binary baseline measurement values for CA and TA compilation.
  • RA Client: initiates a remote attestation request to the target TA and invokes the Kunpeng security library (RA lib) to verify the returned attestation report.
  • RA Service: receives attestation requests, registers attestation keys, obtains attestation reports, and returns attestation reports to the RA Client.
  • Attestation Service: functions as the server to provide the attestation key service and provides the digital signature service for the attestation key in different scenarios.
  • QCA (Quoting CA) lib: It is located in the REE and is provided as a library to respond to remote attestation requests initiated by the verifier.
  • QTA (Quoting TA): A privileged TA in remote attestation. It receives and processes attestation requests from the QCA or TA, Attestation Service certificate import requests, and attestation key generation requests. If remote attestation in a container is supported, it also registers and verifies container information.
  • tcmgr: microkernel service, which functions as a trusted base to provide APIs for upper-layer systems to generate attestation keys, calculate and store measurement values, and generate and sign attestation reports.
  • QCA daemon: A resident process in the container (or VM). When the container is starting, it registers container information with the RA Service on the host. It receives forwarding requests from the RA Service for remote attestation of TAs in the container.
  • QCA lib-report: QCA lib in the container (or VM), which forwards requests to the QTA-report and receives only report requests.
  • QTA-report: QTA in the container (or VM), which is also a privileged TA. It verifies container information from the QTA and obtains TA measurement reports in the container.

TEE OS 1.4.0 and later version supports container-based deployment. Accordingly, to support remote attestation in containers, the QCA and QTA of containers are added and are named QCA lib-report and QTA-report, respectively.

Restrictions

  • The TEE OS firmware version must be 1.3.2 or later.
  • Remote attestation in containers requires that the TEE OS firmware version be 1.4.0 or later.
  • The QCA daemon in a container can only provide the attestation of TAs in the container.
  • The QTA can provide the Provision, SaveAKCert, ValidateAKCert, Report, and Seal capabilities. The QTA-report provides only the Report capability.
  • During remote attestation in a container, the QTA registers and verifies container information. By default, a maximum of 255 containers can be registered concurrently. In addition, the number of containers running TAs concurrently is restricted by other resources. The maximum number is 63 in the TEE OS. If this number is exceeded, TAs in new containers cannot be loaded.
  • Measurement reports are serialized using cJSON in the TEE. Therefore, if you use other JSON libraries to verify measurement reports, the original data (the payload field) for signature verification must be generated in the cJSON format. Otherwise, signature verification fails.