Service IPC compatibility - Attestation

Updated 1,250 Days AgoPublic

Actions

Terminology
This document uses the following terms and abbreviations.

Background
Initial attestation APIs is designed to get a signed token from initial attestation
service which can be used to prove the device identity and integrity towards a
relying party. Initial attestation API is the interface for applications while
initial attestation service is the implementation of the API inside TF-M.

The initial version of initial attestation APIs is working under the library
model. To make it compatible with the IPC model, some updates are required.

Compatibility Overview
The principle of the compatibility is that keeping the existing external
interfaces to avoid unnecessary re-factor in application side. There are some
necessary code lines to implement initial attestation API under IPC mechanism
with calling PSA FF APIs. These code lines are covered with the condition
'TFM_PSA_API' in sources.

Design Prototype
To implement the IPC model for initial attestation service the following parts
need to be modified:

• initial attestation APIs non-secure implementation
• initial attestation APIs secure implementation
• initial attestation request manager
• initial attestation manifest file

The basic flow of IPC communication process:

1. Application calls psa_connect with proper service ID.
2. Application calls psa_call with invec and outvec parameters. Initial attestation request manager extracts the arguments from the input and output vectors, and calls the initial attestation service with the provided parameters.
3. When initial attestation service returns then request manager calls psa_write to provide the service's output to the application.
4. Request manager calls psa_reply to reply return status to the application.
5. Application calls psa_close to finish the function call.

Initial attestation APIs non-secure and secure implementation
PS APIs use IPC client APIs to communicate with initial attestation services.
All the IPC model implementation is conditioned with TFM_PSA_API.
While requesting initial attestation services, a service ID and parameters need
to be provided for psa_connect and psa_call functions. IPC core finds
corresponded service signal for service ID and notifies initial attestation
partition thread. All the SID and minor version definition for the initial
attestation services are defined in tfm_attest_defs.h.
To call initial attestation services, use the corresponding service IDs in the
table below:

Initial attestation request manager
The request manager handles all requests which arrive at the service. It
extracts the arguments from the input and output vectors and calls the
initial attestation service with the provided parameters. Since in IPC model,
partition handles services with PSA FF APIs instead of direct call, a different
wrapper layer is needed to extract the parameters. IPC model uses psa_read to
read parameters from a client input vector and psa_write to write a message
response to a client output vector.
Also, a dispatcher needs to be implemented in initial attestation partition.
Thread in initial attestation partition keeps calling PSA FF APIs to get the
service signals and parameters to be handled, use a service signal to find
corresponded functions then call it with the parameter to get results. Service
signals for each initial attestation service needs to be defined since library
model does not need service signals. Service signals and corresponding service
functions are defined below:

Manifest
To implement an IPC compatible initial attestation partition, the following
definitions must be provided:

• stack size
• thread entry
• service attributes: service ID, service signal

Test Cases
Test cases include non-secure test cases and secure test cases. Interfaces are
not changed for test cases, so test cases do not need to be changed since only
interface internal implementation is changed.

Copyright (c) 2019, Arm Limited. All rights reserved.