| Runtime Security Engine (RSE) |
| ============================= |
| |
| This document focuses on the relationship between the Runtime Security Engine |
| (RSE) and the application processor (AP). According to the ARM reference design |
| the RSE is an independent core next to the AP and the SCP on the same die. It |
| provides fundamental security guarantees and runtime services for the rest of |
| the system (e.g.: trusted boot, measured boot, platform attestation, |
| key management, and key derivation). |
| |
| At power up RSE boots first from its private ROM code. It validates and loads |
| its own images and the initial images of SCP and AP. When AP and SCP are |
| released from reset and their initial code is loaded then they continue their |
| own boot process, which is the same as on non-RSE systems. Please refer to the |
| ``RSE documentation`` [1]_ for more details about the RSE boot flow. |
| |
| The last stage of the RSE firmware is a persistent, runtime component. Much |
| like AP_BL31, this is a passive entity which has no periodical task to do and |
| just waits for external requests from other subsystems. RSE and other |
| subsystems can communicate with each other over message exchange. RSE waits |
| in idle for the incoming request, handles them, and sends a response then goes |
| back to idle. |
| |
| RSE communication layer |
| ----------------------- |
| |
| The communication between RSE and other subsystems are primarily relying on the |
| Message Handling Unit (MHU) module. The number of MHU interfaces between RSE |
| and other cores is IMPDEF. Besides MHU other modules also could take part in |
| the communication. RSE is capable of mapping the AP memory to its address space. |
| Thereby either RSE core itself or a DMA engine if it is present, can move the |
| data between memory belonging to RSE or AP. In this way, a bigger amount of data |
| can be transferred in a short time. |
| |
| The MHU comes in pairs. There is a sender and receiver side. They are connected |
| to each other. An MHU interface consists of two pairs of MHUs, one sender and |
| one receiver on both sides. Bidirectional communication is possible over an |
| interface. One pair provides message sending from AP to RSE and the other pair |
| from RSE to AP. The sender and receiver are connected via channels. There is an |
| IMPDEF number of channels (e.g: 4-16) between a sender and a receiver module. |
| |
| The RSE communication layer provides two ways for message exchange: |
| |
| - ``Embedded messaging``: The full message, including header and payload, are |
| exchanged over the MHU channels. A channel is capable of delivering a single |
| word. The sender writes the data to the channel register on its side and the |
| receiver can read the data from the channel on the other side. One dedicated |
| channel is used for signalling. It does not deliver any payload it is just |
| meant for signalling that the sender loaded the data to the channel registers |
| so the receiver can read them. The receiver uses the same channel to signal |
| that data was read. Signalling happens via IRQ. If the message is longer than |
| the data fit to the channel registers then the message is sent over in |
| multiple rounds. Both, sender and receiver allocate a local buffer for the |
| messages. Data is copied from/to these buffers to/from the channel registers. |
| - ``Pointer-access messaging``: The message header and the payload are |
| separated and they are conveyed in different ways. The header is sent |
| over the channels, similar to the embedded messaging but the payload is |
| copied over by RSE core (or by DMA) between the sender and the receiver. This |
| could be useful in the case of long messages because transaction time is less |
| compared to the embedded messaging mode. Small payloads are copied by the RSE |
| core because setting up DMA would require more CPU cycles. The payload is |
| either copied into an internal buffer or directly read-written by RSE. Actual |
| behavior depends on RSE setup, whether the partition supports memory-mapped |
| ``iovec``. Therefore, the sender must handle both cases and prevent access to |
| the memory, where payload data lives, while the RSE handles the request. |
| |
| The RSE communication layer supports both ways of messaging in parallel. It is |
| decided at runtime based on the message size which way to transfer the message. |
| |
| .. code-block:: bash |
| |
| +----------------------------------------------+ +-------------------+ |
| | | | | |
| | AP | | | |
| | | +--->| SRAM | |
| +----------------------------------------------| | | | |
| | BL1 / BL2 / BL31 | | | | |
| +----------------------------------------------+ | +-------------------+ |
| | ^ | ^ ^ |
| | send IRQ | receive |direct | | |
| V | |access | | |
| +--------------------+ +--------------------+ | | | |
| | MHU sender | | MHU receiver | | | Copy data | |
| +--------------------+ +--------------------+ | | | |
| | | | | | | | | | | | |
| | | channels | | | | channels | | | | | |
| | | e.g: 4-16 | | | | e.g: 4-16 | | | V | |
| +--------------------+ +--------------------+ | +-------+ | |
| | MHU receiver | | MHU sender | | +->| DMA | | |
| +--------------------+ +--------------------+ | | +-------+ | |
| | ^ | | ^ | |
| IRQ | receive | send | | | Copy data | |
| V | | | V V |
| +----------------------------------------------+ | | +-------------------+ |
| | |--+-+ | | |
| | RSE | | SRAM | |
| | | | | |
| +----------------------------------------------+ +-------------------+ |
| |
| .. Note:: |
| |
| The RSE communication layer is not prepared for concurrent execution. The |
| current use case only requires message exchange during the boot phase. In |
| the boot phase, only a single core is running and the rest of the cores are |
| in reset. |
| |
| Message structure |
| ^^^^^^^^^^^^^^^^^ |
| A description of the message format can be found in the ``RSE communication |
| design`` [2]_ document. |
| |
| Source files |
| ^^^^^^^^^^^^ |
| - RSE comms: ``drivers/arm/rse`` |
| - MHU driver: ``drivers/arm/mhu`` |
| |
| |
| API for communication over MHU |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| The API is defined in these header files: |
| |
| - ``include/drivers/arm/rse_comms.h`` |
| - ``include/drivers/arm/mhu.h`` |
| |
| RSE provided runtime services |
| ----------------------------- |
| |
| RSE provides the following runtime services: |
| |
| - ``Measured boot``: Securely store the firmware measurements which were |
| computed during the boot process and the associated metadata (image |
| description, measurement algorithm, etc.). More info on measured boot service |
| in RSE can be found in the ``measured_boot_integration_guide`` [3]_ . |
| - ``Delegated attestation``: Query the platform attestation token and derive a |
| delegated attestation key. More info on the delegated attestation service |
| in RSE can be found in the ``delegated_attestation_integration_guide`` [4]_ . |
| - ``OTP assets management``: Public keys used by AP during the trusted boot |
| process can be requested from RSE. Furthermore, AP can request RSE to |
| increase a non-volatile counter. Please refer to the |
| ``RSE key management`` [5]_ document for more details. |
| |
| Runtime service API |
| ^^^^^^^^^^^^^^^^^^^ |
| The RSE provided runtime services implement a PSA aligned API. The parameter |
| encoding follows the PSA client protocol described in the |
| ``Firmware Framework for M`` [6]_ document in chapter 4.4. The implementation is |
| restricted to the static handle use case therefore only the ``psa_call`` API is |
| implemented. |
| |
| |
| Software and API layers |
| ^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| .. code-block:: bash |
| |
| +----------------+ +---------------------+ |
| | BL1 / BL2 | | BL31 | |
| +----------------+ +---------------------+ |
| | | |
| | extend_measurement() | get_delegated_key() |
| | | get_platform_token() |
| V V |
| +----------------+ +---------------------+ |
| | PSA protocol | | PSA protocol | |
| +----------------+ +---------------------+ |
| | | |
| | psa_call() | psa_call() |
| | | |
| V V |
| +------------------------------------------------+ |
| | RSE communication protocol | |
| +------------------------------------------------+ |
| | ^ |
| | mhu_send_data() | mhu_receive_data() |
| | | |
| V | |
| +------------------------------------------------+ |
| | MHU driver | |
| +------------------------------------------------+ |
| | ^ |
| | Register access | IRQ |
| V | |
| +------------------------------------------------+ |
| | MHU HW on AP side | |
| +------------------------------------------------+ |
| ^ |
| | Physical wires |
| | |
| V |
| +------------------------------------------------+ |
| | MHU HW on RSE side | |
| +------------------------------------------------+ |
| | ^ |
| | IRQ | Register access |
| V | |
| +------------------------------------------------+ |
| | MHU driver | |
| +------------------------------------------------+ |
| | | |
| V V |
| +---------------+ +------------------------+ |
| | Measured boot | | Delegated attestation | |
| | service | | service | |
| +---------------+ +------------------------+ |
| |
| |
| RSE based Measured Boot |
| ----------------------- |
| |
| Measured Boot is the process of cryptographically measuring (computing the hash |
| value of a binary) the code and critical data used at boot time. The |
| measurement must be stored in a tamper-resistant way, so the security state |
| of the device can be attested later to an external party. RSE provides a runtime |
| service which is meant to store measurements and associated metadata alongside. |
| |
| Data is stored in internal SRAM which is only accessible by the secure runtime |
| firmware of RSE. Data is stored in so-called measurement slots. A platform has |
| IMPDEF number of measurement slots. The measurement storage follows extend |
| semantics. This means that measurements are not stored directly (as it was |
| taken) instead they contribute to the current value of the measurement slot. |
| The extension implements this logic, where ``||`` stands for concatenation: |
| |
| .. code-block:: bash |
| |
| new_value_of_measurement_slot = Hash(old_value_of_measurement_slot || measurement) |
| |
| Supported hash algorithms: sha-256, sha-512 |
| |
| Measured Boot API |
| ^^^^^^^^^^^^^^^^^ |
| |
| Defined here: |
| |
| - ``include/lib/psa/measured_boot.h`` |
| |
| .. code-block:: c |
| |
| psa_status_t |
| rse_measured_boot_extend_measurement(uint8_t index, |
| const uint8_t *signer_id, |
| size_t signer_id_size, |
| const uint8_t *version, |
| size_t version_size, |
| uint32_t measurement_algo, |
| const uint8_t *sw_type, |
| size_t sw_type_size, |
| const uint8_t *measurement_value, |
| size_t measurement_value_size, |
| bool lock_measurement); |
| |
| Measured Boot Metadata |
| ^^^^^^^^^^^^^^^^^^^^^^ |
| |
| The following metadata can be stored alongside the measurement: |
| |
| - ``Signer-id``: Mandatory. The hash of the firmware image signing public key. |
| - ``Measurement algorithm``: Optional. The hash algorithm which was used to |
| compute the measurement (e.g.: sha-256, etc.). |
| - ``Version info``: Optional. The firmware version info (e.g.: 2.7). |
| - ``SW type``: Optional. Short text description (e.g.: BL1, BL2, BL31, etc.) |
| |
| .. Note:: |
| Version info is not implemented in TF-A yet. |
| |
| |
| The caller must specify in which measurement slot to extend a certain |
| measurement and metadata. A measurement slot can be extended by multiple |
| measurements. The default value is IMPDEF. All measurement slot is cleared at |
| reset, there is no other way to clear them. In the reference implementation, |
| the measurement slots are initialized to 0. At the first call to extend the |
| measurement in a slot, the extend operation uses the default value of the |
| measurement slot. All upcoming extend operation on the same slot contributes |
| to the previous value of that measurement slot. |
| |
| The following rules are kept when a slot is extended multiple times: |
| |
| - ``Signer-id`` must be the same as the previous call(s), otherwise a |
| PSA_ERROR_NOT_PERMITTED error code is returned. |
| |
| - ``Measurement algorithm``: must be the same as the previous call(s), |
| otherwise, a PSA_ERROR_NOT_PERMITTED error code is returned. |
| |
| In case of error no further action is taken (slot is not locked). If there is |
| a valid data in a sub-sequent call then measurement slot will be extended. The |
| rest of the metadata is handled as follows when a measurement slot is extended |
| multiple times: |
| |
| - ``SW type``: Cleared. |
| - ``Version info``: Cleared. |
| |
| .. Note:: |
| |
| Extending multiple measurements in the same slot leads to some metadata |
| information loss. Since RSE is not constrained on special HW resources to |
| store the measurements and metadata, therefore it is worth considering to |
| store all of them one by one in distinct slots. However, they are one-by-one |
| included in the platform attestation token. So, the number of distinct |
| firmware image measurements has an impact on the size of the attestation |
| token. |
| |
| The allocation of the measurement slot among RSE, Root and Realm worlds is |
| platform dependent. The platform must provide an allocation of the measurement |
| slot at build time. An example can be found in |
| ``tf-a/plat/arm/board/tc/tc_bl1_measured_boot.c`` |
| Furthermore, the memory, which holds the metadata is also statically allocated |
| in RSE memory. Some of the fields have a static value (measurement algorithm), |
| and some of the values have a dynamic value (measurement value) which is updated |
| by the bootloaders when the firmware image is loaded and measured. The metadata |
| structure is defined in |
| ``include/drivers/measured_boot/rse/rse_measured_boot.h``. |
| |
| .. code-block:: c |
| |
| struct rse_mboot_metadata { |
| unsigned int id; |
| uint8_t slot; |
| uint8_t signer_id[SIGNER_ID_MAX_SIZE]; |
| size_t signer_id_size; |
| uint8_t version[VERSION_MAX_SIZE]; |
| size_t version_size; |
| uint8_t sw_type[SW_TYPE_MAX_SIZE]; |
| size_t sw_type_size; |
| void *pk_oid; |
| bool lock_measurement; |
| }; |
| |
| Signer-ID API |
| ^^^^^^^^^^^^^ |
| |
| This function calculates the hash of a public key (signer-ID) using the |
| ``Measurement algorithm`` and stores it in the ``rse_mboot_metadata`` field |
| named ``signer_id``. |
| Prior to calling this function, the caller must ensure that the ``signer_id`` |
| field points to the zero-filled buffer. |
| |
| Defined here: |
| |
| - ``include/drivers/measured_boot/rse/rse_measured_boot.h`` |
| |
| .. code-block:: c |
| |
| int rse_mboot_set_signer_id(struct rse_mboot_metadata *metadata_ptr, |
| const void *pk_oid, |
| const void *pk_ptr, |
| size_t pk_len) |
| |
| |
| - First parameter is the pointer to the ``rse_mboot_metadata`` structure. |
| - Second parameter is the pointer to the key-OID of the public key. |
| - Third parameter is the pointer to the public key buffer. |
| - Fourth parameter is the size of public key buffer. |
| - This function returns 0 on success, a signed integer error code |
| otherwise. |
| |
| Build time config options |
| ^^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| - ``MEASURED_BOOT``: Enable measured boot. It depends on the platform |
| implementation whether RSE or TPM (or both) backend based measured boot is |
| enabled. |
| - ``MBOOT_RSE_HASH_ALG``: Determine the hash algorithm to measure the images. |
| The default value is sha-256. |
| |
| Measured boot flow |
| ^^^^^^^^^^^^^^^^^^ |
| |
| .. figure:: ../resources/diagrams/rse_measured_boot_flow.svg |
| :align: center |
| |
| Sample console log |
| ^^^^^^^^^^^^^^^^^^ |
| |
| .. code-block:: bash |
| |
| INFO: Measured boot extend measurement: |
| INFO: - slot : 6 |
| INFO: - signer_id : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
| INFO: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
| INFO: - version : |
| INFO: - version_size: 0 |
| INFO: - sw_type : FW_CONFIG |
| INFO: - sw_type_size: 10 |
| INFO: - algorithm : 2000009 |
| INFO: - measurement : aa ea d3 a7 a8 e2 ab 7d 13 a6 cb 34 99 10 b9 a1 |
| INFO: : 1b 9f a0 52 c5 a8 b1 d7 76 f2 c1 c1 ef ca 1a df |
| INFO: - locking : true |
| INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 |
| INFO: Loading image id=24 at address 0x4001300 |
| INFO: Image id=24 loaded: 0x4001300 - 0x400153a |
| INFO: Measured boot extend measurement: |
| INFO: - slot : 7 |
| INFO: - signer_id : b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 73 |
| INFO: : e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da |
| INFO: - version : |
| INFO: - version_size: 0 |
| INFO: - sw_type : TB_FW_CONFIG |
| INFO: - sw_type_size: 13 |
| INFO: - algorithm : 2000009 |
| INFO: - measurement : 05 b9 dc 98 62 26 a7 1c 2d e5 bb af f0 90 52 28 |
| INFO: : f2 24 15 8a 3a 56 60 95 d6 51 3a 7a 1a 50 9b b7 |
| INFO: - locking : true |
| INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 |
| INFO: BL1: Loading BL2 |
| INFO: Loading image id=1 at address 0x404d000 |
| INFO: Image id=1 loaded: 0x404d000 - 0x406412a |
| INFO: Measured boot extend measurement: |
| INFO: - slot : 8 |
| INFO: - signer_id : b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 73 |
| INFO: : e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da |
| INFO: - version : |
| INFO: - version_size: 0 |
| INFO: - sw_type : BL_2 |
| INFO: - sw_type_size: 5 |
| INFO: - algorithm : 2000009 |
| INFO: - measurement : 53 a1 51 75 25 90 fb a1 d9 b8 c8 34 32 3a 01 16 |
| INFO: : c9 9e 74 91 7d 28 02 56 3f 5c 40 94 37 58 50 68 |
| INFO: - locking : true |
| |
| Delegated Attestation |
| --------------------- |
| |
| Delegated Attestation Service was mainly developed to support the attestation |
| flow on the ``ARM Confidential Compute Architecture`` (ARM CCA) [7]_. |
| The detailed description of the delegated attestation service can be found in |
| the ``Delegated Attestation Service Integration Guide`` [4]_ document. |
| |
| In the CCA use case, the Realm Management Monitor (RMM) relies on the delegated |
| attestation service of the RSE to get a realm attestation key and the CCA |
| platform token. BL31 does not use the service for its own purpose, only calls |
| it on behalf of RMM. The access to MHU interface and thereby to RSE is |
| restricted to BL31 only. Therefore, RMM does not have direct access, all calls |
| need to go through BL31. The RMM dispatcher module of the BL31 is responsible |
| for delivering the calls between the two parties. |
| |
| .. Note:: |
| Currently the connection between the RMM dispatcher and the PSA/RSE layer |
| is not yet implemented. RMM dispatcher just returns hard coded data. |
| |
| Delegated Attestation API |
| ^^^^^^^^^^^^^^^^^^^^^^^^^ |
| Defined here: |
| |
| - ``include/lib/psa/delegated_attestation.h`` |
| |
| .. code-block:: c |
| |
| psa_status_t |
| rse_delegated_attest_get_delegated_key(uint8_t ecc_curve, |
| uint32_t key_bits, |
| uint8_t *key_buf, |
| size_t key_buf_size, |
| size_t *key_size, |
| uint32_t hash_algo); |
| |
| psa_status_t |
| rse_delegated_attest_get_token(const uint8_t *dak_pub_hash, |
| size_t dak_pub_hash_size, |
| uint8_t *token_buf, |
| size_t token_buf_size, |
| size_t *token_size); |
| |
| Attestation flow |
| ^^^^^^^^^^^^^^^^ |
| |
| .. figure:: ../resources/diagrams/rse_attestation_flow.svg |
| :align: center |
| |
| Sample attestation token |
| ^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| Binary format: |
| |
| .. code-block:: bash |
| |
| INFO: DELEGATED ATTEST TEST START |
| INFO: Get delegated attestation key start |
| INFO: Get delegated attest key succeeds, len: 48 |
| INFO: Delegated attest key: |
| INFO: 0d 2a 66 61 d4 89 17 e1 70 c6 73 56 df f4 11 fd |
| INFO: 7d 1f 3b 8a a3 30 3d 70 4c d9 06 c3 c7 ef 29 43 |
| INFO: 0f ee b5 e7 56 e0 71 74 1b c4 39 39 fd 85 f6 7b |
| INFO: Get platform token start |
| INFO: Get platform token succeeds, len: 1086 |
| INFO: Platform attestation token: |
| INFO: d2 84 44 a1 01 38 22 a0 59 03 d1 a9 0a 58 20 00 |
| INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |
| INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 |
| INFO: 01 00 58 21 01 cb 8c 79 f7 a0 0a 6c ce 12 66 f8 |
| INFO: 64 45 48 42 0e c5 10 bf 84 ee 22 18 b9 8f 11 04 |
| INFO: c7 22 31 9d fb 19 09 5c 58 20 aa aa aa aa aa aa |
| INFO: aa aa bb bb bb bb bb bb bb bb cc cc cc cc cc cc |
| INFO: cc cc dd dd dd dd dd dd dd dd 19 09 5b 19 30 00 |
| INFO: 19 09 5f 89 a4 05 58 20 bf e6 d8 6f 88 26 f4 ff |
| INFO: 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d a2 6a |
| INFO: df 34 c3 29 48 9a dc 38 04 67 31 2e 36 2e 30 2b |
| INFO: 30 01 64 52 54 5f 30 02 58 20 90 27 f2 46 ab 31 |
| INFO: 85 36 46 c4 d7 c6 60 ed 31 0d 3c f0 14 de f0 6c |
| INFO: 24 0b de b6 7a 84 fc 3f 5b b7 a4 05 58 20 b3 60 |
| INFO: ca f5 c9 8c 6b 94 2a 48 82 fa 9d 48 23 ef b1 66 |
| INFO: a9 ef 6a 6e 4a a3 7c 19 19 ed 1f cc c0 49 04 67 |
| INFO: 30 2e 30 2e 30 2b 30 01 64 52 54 5f 31 02 58 20 |
| INFO: 52 13 15 d4 9d b2 cf 54 e4 99 37 44 40 68 f0 70 |
| INFO: 7d 73 64 ae f7 08 14 b0 f7 82 ad c6 17 db a3 91 |
| INFO: a4 05 58 20 bf e6 d8 6f 88 26 f4 ff 97 fb 96 c4 |
| INFO: e6 fb c4 99 3e 46 19 fc 56 5d a2 6a df 34 c3 29 |
| INFO: 48 9a dc 38 04 67 31 2e 35 2e 30 2b 30 01 64 52 |
| INFO: 54 5f 32 02 58 20 8e 5d 64 7e 6f 6c c6 6f d4 4f |
| INFO: 54 b6 06 e5 47 9a cc 1b f3 7f ce 87 38 49 c5 92 |
| INFO: d8 2f 85 2e 85 42 a4 05 58 20 bf e6 d8 6f 88 26 |
| INFO: f4 ff 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d |
| INFO: a2 6a df 34 c3 29 48 9a dc 38 04 67 31 2e 35 2e |
| INFO: 30 2b 30 01 60 02 58 20 b8 01 65 a7 78 8b c6 59 |
| INFO: 42 8d 33 10 85 d1 49 0a dc 9e c3 ee df 85 1b d2 |
| INFO: f0 73 73 6a 0c 07 11 b8 a4 05 58 20 b0 f3 82 09 |
| INFO: 12 97 d8 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 |
| INFO: 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 6a |
| INFO: 46 57 5f 43 4f 4e 46 49 47 00 02 58 20 21 9e a0 |
| INFO: 13 82 e6 d7 97 5a 11 13 a3 5f 45 39 68 b1 d9 a3 |
| INFO: ea 6a ab 84 23 3b 8c 06 16 98 20 ba b9 a4 05 58 |
| INFO: 20 b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 |
| INFO: 73 e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a |
| INFO: da 04 60 01 6d 54 42 5f 46 57 5f 43 4f 4e 46 49 |
| INFO: 47 00 02 58 20 41 39 f6 c2 10 84 53 c5 17 ae 9a |
| INFO: e5 be c1 20 7b cc 24 24 f3 9d 20 a8 fb c7 b3 10 |
| INFO: e3 ee af 1b 05 a4 05 58 20 b0 f3 82 09 12 97 d8 |
| INFO: 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 49 59 f6 |
| INFO: 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 65 42 4c 5f |
| INFO: 32 00 02 58 20 5c 96 20 e1 e3 3b 0f 2c eb c1 8e |
| INFO: 1a 02 a6 65 86 dd 34 97 a7 4c 98 13 bf 74 14 45 |
| INFO: 2d 30 28 05 c3 a4 05 58 20 b0 f3 82 09 12 97 d8 |
| INFO: 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 49 59 f6 |
| INFO: 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 6e 53 45 43 |
| INFO: 55 52 45 5f 52 54 5f 45 4c 33 00 02 58 20 f6 fb |
| INFO: 62 99 a5 0c df db 02 0b 72 5b 1c 0b 63 6e 94 ee |
| INFO: 66 50 56 3a 29 9c cb 38 f0 ec 59 99 d4 2e a4 05 |
| INFO: 58 20 b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec |
| INFO: 32 73 e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 |
| INFO: 9a da 04 60 01 6a 48 57 5f 43 4f 4e 46 49 47 00 |
| INFO: 02 58 20 98 5d 87 21 84 06 33 9d c3 1f 91 f5 68 |
| INFO: 8d a0 5a f0 d7 7e 20 51 ce 3b f2 a5 c3 05 2e 3c |
| INFO: 8b 52 31 19 01 09 78 1c 68 74 74 70 3a 2f 2f 61 |
| INFO: 72 6d 2e 63 6f 6d 2f 43 43 41 2d 53 53 44 2f 31 |
| INFO: 2e 30 2e 30 19 09 62 71 6e 6f 74 2d 68 61 73 68 |
| INFO: 2d 65 78 74 65 6e 64 65 64 19 09 61 44 ef be ad |
| INFO: de 19 09 60 77 77 77 77 2e 74 72 75 73 74 65 64 |
| INFO: 66 69 72 6d 77 61 72 65 2e 6f 72 67 58 60 29 4e |
| INFO: 4a d3 98 1e 3b 70 9f b6 66 ed 47 33 0e 99 f0 b1 |
| INFO: c3 f2 bc b2 1d b0 ae 90 0c c4 82 ff a2 6f ae 45 |
| INFO: f6 87 09 4a 09 21 77 ec 36 1c 53 b8 a7 9b 8e f7 |
| INFO: 27 eb 7a 09 da 6f fb bf cb fd b3 e5 e9 36 91 b1 |
| INFO: 92 13 c1 30 16 b4 5c 49 5e c0 c1 b9 01 5c 88 2c |
| INFO: f8 2f 3e a4 a2 6d e4 9d 31 6a 06 f7 a7 73 |
| INFO: DELEGATED ATTEST TEST END |
| |
| JSON format: |
| |
| .. code-block:: JSON |
| |
| { |
| "CCA_PLATFORM_CHALLENGE": "b'0000000000000000000000000000000000000000000000000000000000000000'", |
| "CCA_PLATFORM_INSTANCE_ID": "b'01CB8C79F7A00A6CCE1266F8644548420EC510BF84EE2218B98F1104C722319DFB'", |
| "CCA_PLATFORM_IMPLEMENTATION_ID": "b'AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD'", |
| "CCA_PLATFORM_LIFECYCLE": "secured_3000", |
| "CCA_PLATFORM_SW_COMPONENTS": [ |
| { |
| "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", |
| "SW_COMPONENT_VERSION": "1.6.0+0", |
| "SW_COMPONENT_TYPE": "RT_0", |
| "MEASUREMENT_VALUE": "b'9027F246AB31853646C4D7C660ED310D3CF014DEF06C240BDEB67A84FC3F5BB7'" |
| }, |
| { |
| "SIGNER_ID": "b'B360CAF5C98C6B942A4882FA9D4823EFB166A9EF6A6E4AA37C1919ED1FCCC049'", |
| "SW_COMPONENT_VERSION": "0.0.0+0", |
| "SW_COMPONENT_TYPE": "RT_1", |
| "MEASUREMENT_VALUE": "b'521315D49DB2CF54E49937444068F0707D7364AEF70814B0F782ADC617DBA391'" |
| }, |
| { |
| "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", |
| "SW_COMPONENT_VERSION": "1.5.0+0", |
| "SW_COMPONENT_TYPE": "RT_2", |
| "MEASUREMENT_VALUE": "b'8E5D647E6F6CC66FD44F54B606E5479ACC1BF37FCE873849C592D82F852E8542'" |
| }, |
| { |
| "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", |
| "SW_COMPONENT_VERSION": "1.5.0+0", |
| "SW_COMPONENT_TYPE": "", |
| "MEASUREMENT_VALUE": "b'B80165A7788BC659428D331085D1490ADC9EC3EEDF851BD2F073736A0C0711B8'" |
| }, |
| { |
| "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", |
| "SW_COMPONENT_VERSION": "", |
| "SW_COMPONENT_TYPE": "FW_CONFIG\u0000", |
| "MEASUREMENT_VALUE": "b'219EA01382E6D7975A1113A35F453968B1D9A3EA6AAB84233B8C06169820BAB9'" |
| }, |
| { |
| "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", |
| "SW_COMPONENT_VERSION": "", |
| "SW_COMPONENT_TYPE": "TB_FW_CONFIG\u0000", |
| "MEASUREMENT_VALUE": "b'4139F6C2108453C517AE9AE5BEC1207BCC2424F39D20A8FBC7B310E3EEAF1B05'" |
| }, |
| { |
| "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", |
| "SW_COMPONENT_VERSION": "", |
| "SW_COMPONENT_TYPE": "BL_2\u0000", |
| "MEASUREMENT_VALUE": "b'5C9620E1E33B0F2CEBC18E1A02A66586DD3497A74C9813BF7414452D302805C3'" |
| }, |
| { |
| "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", |
| "SW_COMPONENT_VERSION": "", |
| "SW_COMPONENT_TYPE": "SECURE_RT_EL3\u0000", |
| "MEASUREMENT_VALUE": "b'F6FB6299A50CDFDB020B725B1C0B636E94EE6650563A299CCB38F0EC5999D42E'" |
| }, |
| { |
| "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", |
| "SW_COMPONENT_VERSION": "", |
| "SW_COMPONENT_TYPE": "HW_CONFIG\u0000", |
| "MEASUREMENT_VALUE": "b'985D87218406339DC31F91F5688DA05AF0D77E2051CE3BF2A5C3052E3C8B5231'" |
| } |
| ], |
| "CCA_ATTESTATION_PROFILE": "http://arm.com/CCA-SSD/1.0.0", |
| "CCA_PLATFORM_HASH_ALGO_ID": "not-hash-extended", |
| "CCA_PLATFORM_CONFIG": "b'EFBEADDE'", |
| "CCA_PLATFORM_VERIFICATION_SERVICE": "www.trustedfirmware.org" |
| } |
| |
| RSE OTP Assets Management |
| ------------------------- |
| |
| RSE provides access for AP to assets in OTP, which include keys for image |
| signature verification and non-volatile counters for anti-rollback protection. |
| |
| Non-Volatile Counter API |
| ^^^^^^^^^^^^^^^^^^^^^^^^ |
| |
| AP/RSE interface for retrieving and incrementing non-volatile counters API is |
| as follows. |
| |
| Defined here: |
| |
| - ``include/lib/psa/rse_platform_api.h`` |
| |
| .. code-block:: c |
| |
| psa_status_t rse_platform_nv_counter_increment(uint32_t counter_id) |
| |
| psa_status_t rse_platform_nv_counter_read(uint32_t counter_id, |
| uint32_t size, uint8_t *val) |
| |
| Through this service, we can read/increment any of the 3 non-volatile |
| counters used on an Arm CCA platform: |
| |
| - ``Non-volatile counter for CCA firmware (BL2, BL31, RMM).`` |
| - ``Non-volatile counter for secure firmware.`` |
| - ``Non-volatile counter for non-secure firmware.`` |
| |
| Public Key API |
| ^^^^^^^^^^^^^^ |
| |
| AP/RSE interface for reading the ROTPK is as follows. |
| |
| Defined here: |
| |
| - ``include/lib/psa/rse_platform_api.h`` |
| |
| .. code-block:: c |
| |
| psa_status_t rse_platform_key_read(enum rse_key_id_builtin_t key, |
| uint8_t *data, size_t data_size, size_t *data_length) |
| |
| Through this service, we can read any of the 3 ROTPKs used on an |
| Arm CCA platform: |
| |
| - ``ROTPK for CCA firmware (BL2, BL31, RMM).`` |
| - ``ROTPK for secure firmware.`` |
| - ``ROTPK for non-secure firmware.`` |
| |
| References |
| ---------- |
| |
| .. [1] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/readme.html |
| .. [2] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html |
| .. [3] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/measured_boot/measured_boot_integration_guide.rst |
| .. [4] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/delegated_attestation/delegated_attest_integration_guide.rst |
| .. [5] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_key_management.html |
| .. [6] https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4&hash=3BFD6F3E687F324672F18E5BE9F08EDC48087C93 |
| .. [7] https://developer.arm.com/documentation/DEN0096/A_a/?lang=en |
| |
| -------------- |
| |
| *Copyright (c) 2023, Arm Limited. All rights reserved.* |