1Runtime Security Engine (RSE) 2============================= 3 4This document focuses on the relationship between the Runtime Security Engine 5(RSE) and the application processor (AP). According to the ARM reference design 6the RSE is an independent core next to the AP and the SCP on the same die. It 7provides fundamental security guarantees and runtime services for the rest of 8the system (e.g.: trusted boot, measured boot, platform attestation, 9key management, and key derivation). 10 11At power up RSE boots first from its private ROM code. It validates and loads 12its own images and the initial images of SCP and AP. When AP and SCP are 13released from reset and their initial code is loaded then they continue their 14own boot process, which is the same as on non-RSE systems. Please refer to the 15``RSE documentation`` [1]_ for more details about the RSE boot flow. 16 17The last stage of the RSE firmware is a persistent, runtime component. Much 18like AP_BL31, this is a passive entity which has no periodical task to do and 19just waits for external requests from other subsystems. RSE and other 20subsystems can communicate with each other over message exchange. RSE waits 21in idle for the incoming request, handles them, and sends a response then goes 22back to idle. 23 24RSE communication layer 25----------------------- 26 27The communication between RSE and other subsystems are primarily relying on the 28Message Handling Unit (MHU) module. The number of MHU interfaces between RSE 29and other cores is IMPDEF. Besides MHU other modules also could take part in 30the communication. RSE is capable of mapping the AP memory to its address space. 31Thereby either RSE core itself or a DMA engine if it is present, can move the 32data between memory belonging to RSE or AP. In this way, a bigger amount of data 33can be transferred in a short time. 34 35The MHU comes in pairs. There is a sender and receiver side. They are connected 36to each other. An MHU interface consists of two pairs of MHUs, one sender and 37one receiver on both sides. Bidirectional communication is possible over an 38interface. One pair provides message sending from AP to RSE and the other pair 39from RSE to AP. The sender and receiver are connected via channels. There is an 40IMPDEF number of channels (e.g: 4-16) between a sender and a receiver module. 41 42The RSE communication layer provides two ways for message exchange: 43 44- ``Embedded messaging``: The full message, including header and payload, are 45 exchanged over the MHU channels. A channel is capable of delivering a single 46 word. The sender writes the data to the channel register on its side and the 47 receiver can read the data from the channel on the other side. One dedicated 48 channel is used for signalling. It does not deliver any payload it is just 49 meant for signalling that the sender loaded the data to the channel registers 50 so the receiver can read them. The receiver uses the same channel to signal 51 that data was read. Signalling happens via IRQ. If the message is longer than 52 the data fit to the channel registers then the message is sent over in 53 multiple rounds. Both, sender and receiver allocate a local buffer for the 54 messages. Data is copied from/to these buffers to/from the channel registers. 55- ``Pointer-access messaging``: The message header and the payload are 56 separated and they are conveyed in different ways. The header is sent 57 over the channels, similar to the embedded messaging but the payload is 58 copied over by RSE core (or by DMA) between the sender and the receiver. This 59 could be useful in the case of long messages because transaction time is less 60 compared to the embedded messaging mode. Small payloads are copied by the RSE 61 core because setting up DMA would require more CPU cycles. The payload is 62 either copied into an internal buffer or directly read-written by RSE. Actual 63 behavior depends on RSE setup, whether the partition supports memory-mapped 64 ``iovec``. Therefore, the sender must handle both cases and prevent access to 65 the memory, where payload data lives, while the RSE handles the request. 66 67The RSE communication layer supports both ways of messaging in parallel. It is 68decided at runtime based on the message size which way to transfer the message. 69 70.. code-block:: bash 71 72 +----------------------------------------------+ +-------------------+ 73 | | | | 74 | AP | | | 75 | | +--->| SRAM | 76 +----------------------------------------------| | | | 77 | BL1 / BL2 / BL31 | | | | 78 +----------------------------------------------+ | +-------------------+ 79 | ^ | ^ ^ 80 | send IRQ | receive |direct | | 81 V | |access | | 82 +--------------------+ +--------------------+ | | | 83 | MHU sender | | MHU receiver | | | Copy data | 84 +--------------------+ +--------------------+ | | | 85 | | | | | | | | | | | 86 | | channels | | | | channels | | | | | 87 | | e.g: 4-16 | | | | e.g: 4-16 | | | V | 88 +--------------------+ +--------------------+ | +-------+ | 89 | MHU receiver | | MHU sender | | +->| DMA | | 90 +--------------------+ +--------------------+ | | +-------+ | 91 | ^ | | ^ | 92 IRQ | receive | send | | | Copy data | 93 V | | | V V 94 +----------------------------------------------+ | | +-------------------+ 95 | |--+-+ | | 96 | RSE | | SRAM | 97 | | | | 98 +----------------------------------------------+ +-------------------+ 99 100.. Note:: 101 102 The RSE communication layer is not prepared for concurrent execution. The 103 current use case only requires message exchange during the boot phase. In 104 the boot phase, only a single core is running and the rest of the cores are 105 in reset. 106 107Message structure 108^^^^^^^^^^^^^^^^^ 109A description of the message format can be found in the ``RSE communication 110design`` [2]_ document. 111 112Source files 113^^^^^^^^^^^^ 114- RSE comms: ``drivers/arm/rse`` 115- MHU driver: ``drivers/arm/mhu`` 116 117 118API for communication over MHU 119^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 120The API is defined in these header files: 121 122- ``include/drivers/arm/rse_comms.h`` 123- ``include/drivers/arm/mhu.h`` 124 125RSE provided runtime services 126----------------------------- 127 128RSE provides the following runtime services: 129 130- ``Measured boot``: Securely store the firmware measurements which were 131 computed during the boot process and the associated metadata (image 132 description, measurement algorithm, etc.). More info on measured boot service 133 in RSE can be found in the ``measured_boot_integration_guide`` [3]_ . 134- ``Delegated attestation``: Query the platform attestation token and derive a 135 delegated attestation key. More info on the delegated attestation service 136 in RSE can be found in the ``delegated_attestation_integration_guide`` [4]_ . 137- ``OTP assets management``: Public keys used by AP during the trusted boot 138 process can be requested from RSE. Furthermore, AP can request RSE to 139 increase a non-volatile counter. Please refer to the 140 ``RSE key management`` [5]_ document for more details. 141 142Runtime service API 143^^^^^^^^^^^^^^^^^^^ 144The RSE provided runtime services implement a PSA aligned API. The parameter 145encoding follows the PSA client protocol described in the 146``Firmware Framework for M`` [6]_ document in chapter 4.4. The implementation is 147restricted to the static handle use case therefore only the ``psa_call`` API is 148implemented. 149 150 151Software and API layers 152^^^^^^^^^^^^^^^^^^^^^^^ 153 154.. code-block:: bash 155 156 +----------------+ +---------------------+ 157 | BL1 / BL2 | | BL31 | 158 +----------------+ +---------------------+ 159 | | 160 | extend_measurement() | get_delegated_key() 161 | | get_platform_token() 162 V V 163 +----------------+ +---------------------+ 164 | PSA protocol | | PSA protocol | 165 +----------------+ +---------------------+ 166 | | 167 | psa_call() | psa_call() 168 | | 169 V V 170 +------------------------------------------------+ 171 | RSE communication protocol | 172 +------------------------------------------------+ 173 | ^ 174 | mhu_send_data() | mhu_receive_data() 175 | | 176 V | 177 +------------------------------------------------+ 178 | MHU driver | 179 +------------------------------------------------+ 180 | ^ 181 | Register access | IRQ 182 V | 183 +------------------------------------------------+ 184 | MHU HW on AP side | 185 +------------------------------------------------+ 186 ^ 187 | Physical wires 188 | 189 V 190 +------------------------------------------------+ 191 | MHU HW on RSE side | 192 +------------------------------------------------+ 193 | ^ 194 | IRQ | Register access 195 V | 196 +------------------------------------------------+ 197 | MHU driver | 198 +------------------------------------------------+ 199 | | 200 V V 201 +---------------+ +------------------------+ 202 | Measured boot | | Delegated attestation | 203 | service | | service | 204 +---------------+ +------------------------+ 205 206 207RSE based Measured Boot 208----------------------- 209 210Measured Boot is the process of cryptographically measuring (computing the hash 211value of a binary) the code and critical data used at boot time. The 212measurement must be stored in a tamper-resistant way, so the security state 213of the device can be attested later to an external party. RSE provides a runtime 214service which is meant to store measurements and associated metadata alongside. 215 216Data is stored in internal SRAM which is only accessible by the secure runtime 217firmware of RSE. Data is stored in so-called measurement slots. A platform has 218IMPDEF number of measurement slots. The measurement storage follows extend 219semantics. This means that measurements are not stored directly (as it was 220taken) instead they contribute to the current value of the measurement slot. 221The extension implements this logic, where ``||`` stands for concatenation: 222 223.. code-block:: bash 224 225 new_value_of_measurement_slot = Hash(old_value_of_measurement_slot || measurement) 226 227Supported hash algorithms: sha-256, sha-512 228 229Measured Boot API 230^^^^^^^^^^^^^^^^^ 231 232Defined here: 233 234- ``include/lib/psa/measured_boot.h`` 235 236.. code-block:: c 237 238 psa_status_t 239 rse_measured_boot_extend_measurement(uint8_t index, 240 const uint8_t *signer_id, 241 size_t signer_id_size, 242 const uint8_t *version, 243 size_t version_size, 244 uint32_t measurement_algo, 245 const uint8_t *sw_type, 246 size_t sw_type_size, 247 const uint8_t *measurement_value, 248 size_t measurement_value_size, 249 bool lock_measurement); 250 251Measured Boot Metadata 252^^^^^^^^^^^^^^^^^^^^^^ 253 254The following metadata can be stored alongside the measurement: 255 256- ``Signer-id``: Mandatory. The hash of the firmware image signing public key. 257- ``Measurement algorithm``: Optional. The hash algorithm which was used to 258 compute the measurement (e.g.: sha-256, etc.). 259- ``Version info``: Optional. The firmware version info (e.g.: 2.7). 260- ``SW type``: Optional. Short text description (e.g.: BL1, BL2, BL31, etc.) 261 262.. Note:: 263 Version info is not implemented in TF-A yet. 264 265 266The caller must specify in which measurement slot to extend a certain 267measurement and metadata. A measurement slot can be extended by multiple 268measurements. The default value is IMPDEF. All measurement slot is cleared at 269reset, there is no other way to clear them. In the reference implementation, 270the measurement slots are initialized to 0. At the first call to extend the 271measurement in a slot, the extend operation uses the default value of the 272measurement slot. All upcoming extend operation on the same slot contributes 273to the previous value of that measurement slot. 274 275The following rules are kept when a slot is extended multiple times: 276 277- ``Signer-id`` must be the same as the previous call(s), otherwise a 278 PSA_ERROR_NOT_PERMITTED error code is returned. 279 280- ``Measurement algorithm``: must be the same as the previous call(s), 281 otherwise, a PSA_ERROR_NOT_PERMITTED error code is returned. 282 283In case of error no further action is taken (slot is not locked). If there is 284a valid data in a sub-sequent call then measurement slot will be extended. The 285rest of the metadata is handled as follows when a measurement slot is extended 286multiple times: 287 288- ``SW type``: Cleared. 289- ``Version info``: Cleared. 290 291.. Note:: 292 293 Extending multiple measurements in the same slot leads to some metadata 294 information loss. Since RSE is not constrained on special HW resources to 295 store the measurements and metadata, therefore it is worth considering to 296 store all of them one by one in distinct slots. However, they are one-by-one 297 included in the platform attestation token. So, the number of distinct 298 firmware image measurements has an impact on the size of the attestation 299 token. 300 301The allocation of the measurement slot among RSE, Root and Realm worlds is 302platform dependent. The platform must provide an allocation of the measurement 303slot at build time. An example can be found in 304``tf-a/plat/arm/board/tc/tc_bl1_measured_boot.c`` 305Furthermore, the memory, which holds the metadata is also statically allocated 306in RSE memory. Some of the fields have a static value (measurement algorithm), 307and some of the values have a dynamic value (measurement value) which is updated 308by the bootloaders when the firmware image is loaded and measured. The metadata 309structure is defined in 310``include/drivers/measured_boot/rse/rse_measured_boot.h``. 311 312.. code-block:: c 313 314 struct rse_mboot_metadata { 315 unsigned int id; 316 uint8_t slot; 317 uint8_t signer_id[SIGNER_ID_MAX_SIZE]; 318 size_t signer_id_size; 319 uint8_t version[VERSION_MAX_SIZE]; 320 size_t version_size; 321 uint8_t sw_type[SW_TYPE_MAX_SIZE]; 322 size_t sw_type_size; 323 void *pk_oid; 324 bool lock_measurement; 325 }; 326 327Signer-ID API 328^^^^^^^^^^^^^ 329 330This function calculates the hash of a public key (signer-ID) using the 331``Measurement algorithm`` and stores it in the ``rse_mboot_metadata`` field 332named ``signer_id``. 333Prior to calling this function, the caller must ensure that the ``signer_id`` 334field points to the zero-filled buffer. 335 336Defined here: 337 338- ``include/drivers/measured_boot/rse/rse_measured_boot.h`` 339 340.. code-block:: c 341 342 int rse_mboot_set_signer_id(struct rse_mboot_metadata *metadata_ptr, 343 const void *pk_oid, 344 const void *pk_ptr, 345 size_t pk_len) 346 347 348- First parameter is the pointer to the ``rse_mboot_metadata`` structure. 349- Second parameter is the pointer to the key-OID of the public key. 350- Third parameter is the pointer to the public key buffer. 351- Fourth parameter is the size of public key buffer. 352- This function returns 0 on success, a signed integer error code 353 otherwise. 354 355Build time config options 356^^^^^^^^^^^^^^^^^^^^^^^^^ 357 358- ``MEASURED_BOOT``: Enable measured boot. It depends on the platform 359 implementation whether RSE or TPM (or both) backend based measured boot is 360 enabled. 361- ``MBOOT_RSE_HASH_ALG``: Determine the hash algorithm to measure the images. 362 The default value is sha-256. 363 364Measured boot flow 365^^^^^^^^^^^^^^^^^^ 366 367.. figure:: ../resources/diagrams/rse_measured_boot_flow.svg 368 :align: center 369 370Sample console log 371^^^^^^^^^^^^^^^^^^ 372 373.. code-block:: bash 374 375 INFO: Measured boot extend measurement: 376 INFO: - slot : 6 377 INFO: - signer_id : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 378 INFO: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 379 INFO: - version : 380 INFO: - version_size: 0 381 INFO: - sw_type : FW_CONFIG 382 INFO: - sw_type_size: 10 383 INFO: - algorithm : 2000009 384 INFO: - measurement : aa ea d3 a7 a8 e2 ab 7d 13 a6 cb 34 99 10 b9 a1 385 INFO: : 1b 9f a0 52 c5 a8 b1 d7 76 f2 c1 c1 ef ca 1a df 386 INFO: - locking : true 387 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010 388 INFO: Loading image id=24 at address 0x4001300 389 INFO: Image id=24 loaded: 0x4001300 - 0x400153a 390 INFO: Measured boot extend measurement: 391 INFO: - slot : 7 392 INFO: - signer_id : b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 73 393 INFO: : e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da 394 INFO: - version : 395 INFO: - version_size: 0 396 INFO: - sw_type : TB_FW_CONFIG 397 INFO: - sw_type_size: 13 398 INFO: - algorithm : 2000009 399 INFO: - measurement : 05 b9 dc 98 62 26 a7 1c 2d e5 bb af f0 90 52 28 400 INFO: : f2 24 15 8a 3a 56 60 95 d6 51 3a 7a 1a 50 9b b7 401 INFO: - locking : true 402 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300 403 INFO: BL1: Loading BL2 404 INFO: Loading image id=1 at address 0x404d000 405 INFO: Image id=1 loaded: 0x404d000 - 0x406412a 406 INFO: Measured boot extend measurement: 407 INFO: - slot : 8 408 INFO: - signer_id : b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 73 409 INFO: : e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da 410 INFO: - version : 411 INFO: - version_size: 0 412 INFO: - sw_type : BL_2 413 INFO: - sw_type_size: 5 414 INFO: - algorithm : 2000009 415 INFO: - measurement : 53 a1 51 75 25 90 fb a1 d9 b8 c8 34 32 3a 01 16 416 INFO: : c9 9e 74 91 7d 28 02 56 3f 5c 40 94 37 58 50 68 417 INFO: - locking : true 418 419Delegated Attestation 420--------------------- 421 422Delegated Attestation Service was mainly developed to support the attestation 423flow on the ``ARM Confidential Compute Architecture`` (ARM CCA) [7]_. 424The detailed description of the delegated attestation service can be found in 425the ``Delegated Attestation Service Integration Guide`` [4]_ document. 426 427In the CCA use case, the Realm Management Monitor (RMM) relies on the delegated 428attestation service of the RSE to get a realm attestation key and the CCA 429platform token. BL31 does not use the service for its own purpose, only calls 430it on behalf of RMM. The access to MHU interface and thereby to RSE is 431restricted to BL31 only. Therefore, RMM does not have direct access, all calls 432need to go through BL31. The RMM dispatcher module of the BL31 is responsible 433for delivering the calls between the two parties. 434 435.. Note:: 436 Currently the connection between the RMM dispatcher and the PSA/RSE layer 437 is not yet implemented. RMM dispatcher just returns hard coded data. 438 439Delegated Attestation API 440^^^^^^^^^^^^^^^^^^^^^^^^^ 441Defined here: 442 443- ``include/lib/psa/delegated_attestation.h`` 444 445.. code-block:: c 446 447 psa_status_t 448 rse_delegated_attest_get_delegated_key(uint8_t ecc_curve, 449 uint32_t key_bits, 450 uint8_t *key_buf, 451 size_t key_buf_size, 452 size_t *key_size, 453 uint32_t hash_algo); 454 455 psa_status_t 456 rse_delegated_attest_get_token(const uint8_t *dak_pub_hash, 457 size_t dak_pub_hash_size, 458 uint8_t *token_buf, 459 size_t token_buf_size, 460 size_t *token_size); 461 462Attestation flow 463^^^^^^^^^^^^^^^^ 464 465.. figure:: ../resources/diagrams/rse_attestation_flow.svg 466 :align: center 467 468Sample attestation token 469^^^^^^^^^^^^^^^^^^^^^^^^ 470 471Binary format: 472 473.. code-block:: bash 474 475 INFO: DELEGATED ATTEST TEST START 476 INFO: Get delegated attestation key start 477 INFO: Get delegated attest key succeeds, len: 48 478 INFO: Delegated attest key: 479 INFO: 0d 2a 66 61 d4 89 17 e1 70 c6 73 56 df f4 11 fd 480 INFO: 7d 1f 3b 8a a3 30 3d 70 4c d9 06 c3 c7 ef 29 43 481 INFO: 0f ee b5 e7 56 e0 71 74 1b c4 39 39 fd 85 f6 7b 482 INFO: Get platform token start 483 INFO: Get platform token succeeds, len: 1086 484 INFO: Platform attestation token: 485 INFO: d2 84 44 a1 01 38 22 a0 59 03 d1 a9 0a 58 20 00 486 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 487 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19 488 INFO: 01 00 58 21 01 cb 8c 79 f7 a0 0a 6c ce 12 66 f8 489 INFO: 64 45 48 42 0e c5 10 bf 84 ee 22 18 b9 8f 11 04 490 INFO: c7 22 31 9d fb 19 09 5c 58 20 aa aa aa aa aa aa 491 INFO: aa aa bb bb bb bb bb bb bb bb cc cc cc cc cc cc 492 INFO: cc cc dd dd dd dd dd dd dd dd 19 09 5b 19 30 00 493 INFO: 19 09 5f 89 a4 05 58 20 bf e6 d8 6f 88 26 f4 ff 494 INFO: 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d a2 6a 495 INFO: df 34 c3 29 48 9a dc 38 04 67 31 2e 36 2e 30 2b 496 INFO: 30 01 64 52 54 5f 30 02 58 20 90 27 f2 46 ab 31 497 INFO: 85 36 46 c4 d7 c6 60 ed 31 0d 3c f0 14 de f0 6c 498 INFO: 24 0b de b6 7a 84 fc 3f 5b b7 a4 05 58 20 b3 60 499 INFO: ca f5 c9 8c 6b 94 2a 48 82 fa 9d 48 23 ef b1 66 500 INFO: a9 ef 6a 6e 4a a3 7c 19 19 ed 1f cc c0 49 04 67 501 INFO: 30 2e 30 2e 30 2b 30 01 64 52 54 5f 31 02 58 20 502 INFO: 52 13 15 d4 9d b2 cf 54 e4 99 37 44 40 68 f0 70 503 INFO: 7d 73 64 ae f7 08 14 b0 f7 82 ad c6 17 db a3 91 504 INFO: a4 05 58 20 bf e6 d8 6f 88 26 f4 ff 97 fb 96 c4 505 INFO: e6 fb c4 99 3e 46 19 fc 56 5d a2 6a df 34 c3 29 506 INFO: 48 9a dc 38 04 67 31 2e 35 2e 30 2b 30 01 64 52 507 INFO: 54 5f 32 02 58 20 8e 5d 64 7e 6f 6c c6 6f d4 4f 508 INFO: 54 b6 06 e5 47 9a cc 1b f3 7f ce 87 38 49 c5 92 509 INFO: d8 2f 85 2e 85 42 a4 05 58 20 bf e6 d8 6f 88 26 510 INFO: f4 ff 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d 511 INFO: a2 6a df 34 c3 29 48 9a dc 38 04 67 31 2e 35 2e 512 INFO: 30 2b 30 01 60 02 58 20 b8 01 65 a7 78 8b c6 59 513 INFO: 42 8d 33 10 85 d1 49 0a dc 9e c3 ee df 85 1b d2 514 INFO: f0 73 73 6a 0c 07 11 b8 a4 05 58 20 b0 f3 82 09 515 INFO: 12 97 d8 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 516 INFO: 49 59 f6 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 6a 517 INFO: 46 57 5f 43 4f 4e 46 49 47 00 02 58 20 21 9e a0 518 INFO: 13 82 e6 d7 97 5a 11 13 a3 5f 45 39 68 b1 d9 a3 519 INFO: ea 6a ab 84 23 3b 8c 06 16 98 20 ba b9 a4 05 58 520 INFO: 20 b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 32 521 INFO: 73 e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 9a 522 INFO: da 04 60 01 6d 54 42 5f 46 57 5f 43 4f 4e 46 49 523 INFO: 47 00 02 58 20 41 39 f6 c2 10 84 53 c5 17 ae 9a 524 INFO: e5 be c1 20 7b cc 24 24 f3 9d 20 a8 fb c7 b3 10 525 INFO: e3 ee af 1b 05 a4 05 58 20 b0 f3 82 09 12 97 d8 526 INFO: 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 49 59 f6 527 INFO: 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 65 42 4c 5f 528 INFO: 32 00 02 58 20 5c 96 20 e1 e3 3b 0f 2c eb c1 8e 529 INFO: 1a 02 a6 65 86 dd 34 97 a7 4c 98 13 bf 74 14 45 530 INFO: 2d 30 28 05 c3 a4 05 58 20 b0 f3 82 09 12 97 d8 531 INFO: 3a 37 7a 72 47 1b ec 32 73 e9 92 32 e2 49 59 f6 532 INFO: 5e 8b 4a 4a 46 d8 22 9a da 04 60 01 6e 53 45 43 533 INFO: 55 52 45 5f 52 54 5f 45 4c 33 00 02 58 20 f6 fb 534 INFO: 62 99 a5 0c df db 02 0b 72 5b 1c 0b 63 6e 94 ee 535 INFO: 66 50 56 3a 29 9c cb 38 f0 ec 59 99 d4 2e a4 05 536 INFO: 58 20 b0 f3 82 09 12 97 d8 3a 37 7a 72 47 1b ec 537 INFO: 32 73 e9 92 32 e2 49 59 f6 5e 8b 4a 4a 46 d8 22 538 INFO: 9a da 04 60 01 6a 48 57 5f 43 4f 4e 46 49 47 00 539 INFO: 02 58 20 98 5d 87 21 84 06 33 9d c3 1f 91 f5 68 540 INFO: 8d a0 5a f0 d7 7e 20 51 ce 3b f2 a5 c3 05 2e 3c 541 INFO: 8b 52 31 19 01 09 78 1c 68 74 74 70 3a 2f 2f 61 542 INFO: 72 6d 2e 63 6f 6d 2f 43 43 41 2d 53 53 44 2f 31 543 INFO: 2e 30 2e 30 19 09 62 71 6e 6f 74 2d 68 61 73 68 544 INFO: 2d 65 78 74 65 6e 64 65 64 19 09 61 44 ef be ad 545 INFO: de 19 09 60 77 77 77 77 2e 74 72 75 73 74 65 64 546 INFO: 66 69 72 6d 77 61 72 65 2e 6f 72 67 58 60 29 4e 547 INFO: 4a d3 98 1e 3b 70 9f b6 66 ed 47 33 0e 99 f0 b1 548 INFO: c3 f2 bc b2 1d b0 ae 90 0c c4 82 ff a2 6f ae 45 549 INFO: f6 87 09 4a 09 21 77 ec 36 1c 53 b8 a7 9b 8e f7 550 INFO: 27 eb 7a 09 da 6f fb bf cb fd b3 e5 e9 36 91 b1 551 INFO: 92 13 c1 30 16 b4 5c 49 5e c0 c1 b9 01 5c 88 2c 552 INFO: f8 2f 3e a4 a2 6d e4 9d 31 6a 06 f7 a7 73 553 INFO: DELEGATED ATTEST TEST END 554 555JSON format: 556 557.. code-block:: JSON 558 559 { 560 "CCA_PLATFORM_CHALLENGE": "b'0000000000000000000000000000000000000000000000000000000000000000'", 561 "CCA_PLATFORM_INSTANCE_ID": "b'01CB8C79F7A00A6CCE1266F8644548420EC510BF84EE2218B98F1104C722319DFB'", 562 "CCA_PLATFORM_IMPLEMENTATION_ID": "b'AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD'", 563 "CCA_PLATFORM_LIFECYCLE": "secured_3000", 564 "CCA_PLATFORM_SW_COMPONENTS": [ 565 { 566 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", 567 "SW_COMPONENT_VERSION": "1.6.0+0", 568 "SW_COMPONENT_TYPE": "RT_0", 569 "MEASUREMENT_VALUE": "b'9027F246AB31853646C4D7C660ED310D3CF014DEF06C240BDEB67A84FC3F5BB7'" 570 }, 571 { 572 "SIGNER_ID": "b'B360CAF5C98C6B942A4882FA9D4823EFB166A9EF6A6E4AA37C1919ED1FCCC049'", 573 "SW_COMPONENT_VERSION": "0.0.0+0", 574 "SW_COMPONENT_TYPE": "RT_1", 575 "MEASUREMENT_VALUE": "b'521315D49DB2CF54E49937444068F0707D7364AEF70814B0F782ADC617DBA391'" 576 }, 577 { 578 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", 579 "SW_COMPONENT_VERSION": "1.5.0+0", 580 "SW_COMPONENT_TYPE": "RT_2", 581 "MEASUREMENT_VALUE": "b'8E5D647E6F6CC66FD44F54B606E5479ACC1BF37FCE873849C592D82F852E8542'" 582 }, 583 { 584 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'", 585 "SW_COMPONENT_VERSION": "1.5.0+0", 586 "SW_COMPONENT_TYPE": "", 587 "MEASUREMENT_VALUE": "b'B80165A7788BC659428D331085D1490ADC9EC3EEDF851BD2F073736A0C0711B8'" 588 }, 589 { 590 "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", 591 "SW_COMPONENT_VERSION": "", 592 "SW_COMPONENT_TYPE": "FW_CONFIG\u0000", 593 "MEASUREMENT_VALUE": "b'219EA01382E6D7975A1113A35F453968B1D9A3EA6AAB84233B8C06169820BAB9'" 594 }, 595 { 596 "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", 597 "SW_COMPONENT_VERSION": "", 598 "SW_COMPONENT_TYPE": "TB_FW_CONFIG\u0000", 599 "MEASUREMENT_VALUE": "b'4139F6C2108453C517AE9AE5BEC1207BCC2424F39D20A8FBC7B310E3EEAF1B05'" 600 }, 601 { 602 "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", 603 "SW_COMPONENT_VERSION": "", 604 "SW_COMPONENT_TYPE": "BL_2\u0000", 605 "MEASUREMENT_VALUE": "b'5C9620E1E33B0F2CEBC18E1A02A66586DD3497A74C9813BF7414452D302805C3'" 606 }, 607 { 608 "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", 609 "SW_COMPONENT_VERSION": "", 610 "SW_COMPONENT_TYPE": "SECURE_RT_EL3\u0000", 611 "MEASUREMENT_VALUE": "b'F6FB6299A50CDFDB020B725B1C0B636E94EE6650563A299CCB38F0EC5999D42E'" 612 }, 613 { 614 "SIGNER_ID": "b'b0f382091297d83a377a72471bec3273e99232e24959f65e8b4a4a46d8229ada'", 615 "SW_COMPONENT_VERSION": "", 616 "SW_COMPONENT_TYPE": "HW_CONFIG\u0000", 617 "MEASUREMENT_VALUE": "b'985D87218406339DC31F91F5688DA05AF0D77E2051CE3BF2A5C3052E3C8B5231'" 618 } 619 ], 620 "CCA_ATTESTATION_PROFILE": "http://arm.com/CCA-SSD/1.0.0", 621 "CCA_PLATFORM_HASH_ALGO_ID": "not-hash-extended", 622 "CCA_PLATFORM_CONFIG": "b'EFBEADDE'", 623 "CCA_PLATFORM_VERIFICATION_SERVICE": "www.trustedfirmware.org" 624 } 625 626RSE OTP Assets Management 627------------------------- 628 629RSE provides access for AP to assets in OTP, which include keys for image 630signature verification and non-volatile counters for anti-rollback protection. 631 632Non-Volatile Counter API 633^^^^^^^^^^^^^^^^^^^^^^^^ 634 635AP/RSE interface for retrieving and incrementing non-volatile counters API is 636as follows. 637 638Defined here: 639 640- ``include/lib/psa/rse_platform_api.h`` 641 642.. code-block:: c 643 644 psa_status_t rse_platform_nv_counter_increment(uint32_t counter_id) 645 646 psa_status_t rse_platform_nv_counter_read(uint32_t counter_id, 647 uint32_t size, uint8_t *val) 648 649Through this service, we can read/increment any of the 3 non-volatile 650counters used on an Arm CCA platform: 651 652- ``Non-volatile counter for CCA firmware (BL2, BL31, RMM).`` 653- ``Non-volatile counter for secure firmware.`` 654- ``Non-volatile counter for non-secure firmware.`` 655 656Public Key API 657^^^^^^^^^^^^^^ 658 659AP/RSE interface for reading the ROTPK is as follows. 660 661Defined here: 662 663- ``include/lib/psa/rse_platform_api.h`` 664 665.. code-block:: c 666 667 psa_status_t rse_platform_key_read(enum rse_key_id_builtin_t key, 668 uint8_t *data, size_t data_size, size_t *data_length) 669 670Through this service, we can read any of the 3 ROTPKs used on an 671Arm CCA platform: 672 673- ``ROTPK for CCA firmware (BL2, BL31, RMM).`` 674- ``ROTPK for secure firmware.`` 675- ``ROTPK for non-secure firmware.`` 676 677References 678---------- 679 680.. [1] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/readme.html 681.. [2] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html 682.. [3] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/measured_boot/measured_boot_integration_guide.rst 683.. [4] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/delegated_attestation/delegated_attest_integration_guide.rst 684.. [5] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_key_management.html 685.. [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 686.. [7] https://developer.arm.com/documentation/DEN0096/A_a/?lang=en 687 688-------------- 689 690*Copyright (c) 2023, Arm Limited. All rights reserved.* 691
