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