**Terminology** This document uses the following terms and abbreviations. |Term |Meaning | | ----- | ----- | |API | Application Program Interface | |IPC | Inter-Processes Communication | |PSA | Platform Security Architecture | |PSA FF | Platform Security Architecture Firmware Framework| |SID | Service ID | |TF-M | Trusted Firmware for M-class devices | **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: |Service function |Service ID | |----- |----- | |initial_attest_get_token |TFM_ATTEST_GET_TOKEN_SID | |initial_attest_get_token_size |TFM_ATTEST_GET_TOKEN_SIZE_SID | **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 protected storage layer 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: |Signal |Service Function | |----- |----- | |TFM_ATTEST_GET_TOKEN_SIG |initial_attest_get_token | |TFM_ATTEST_GET_TOKEN_SIZE_SIG |initial_attest_get_token_size | **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.//

**Terminology** This document uses the following terms and abbreviations. |Term |Meaning | | ----- | ----- | |API | Application Program Interface | |IPC | Inter-Processes Communication | |PSA | Platform Security Architecture | |PSA FF | Platform Security Architecture Firmware Framework| |SID | Service ID | |TF-M | Trusted Firmware for M-class devices | **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: |Service function |Service ID | |----- |----- | |initial_attest_get_token |TFM_ATTEST_GET_TOKEN_SID | |initial_attest_get_token_size |TFM_ATTEST_GET_TOKEN_SIZE_SID | **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: |Signal |Service Function | |----- |----- | |TFM_ATTEST_GET_TOKEN_SIG |initial_attest_get_token | |TFM_ATTEST_GET_TOKEN_SIZE_SIG |initial_attest_get_token_size | **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.//

**Terminology** This document uses the following terms and abbreviations. |Term |Meaning | | ----- | ----- | |API | Application Program Interface | |IPC | Inter-Processes Communication | |PSA | Platform Security Architecture | |PSA FF | Platform Security Architecture Firmware Framework| |SID | Service ID | |TF-M | Trusted Firmware for M-class devices | **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: |Service function |Service ID | |----- |----- | |initial_attest_get_token |TFM_ATTEST_GET_TOKEN_SID | |initial_attest_get_token_size |TFM_ATTEST_GET_TOKEN_SIZE_SID | **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 protected storage layerinitial 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: |Signal |Service Function | |----- |----- | |TFM_ATTEST_GET_TOKEN_SIG |initial_attest_get_token | |TFM_ATTEST_GET_TOKEN_SIZE_SIG |initial_attest_get_token_size | **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.//