Gitiles
Code Review Sign In
git01.mediatek.com / filogic / atf / 61286d2617522d6818e634931a0524ca22f287f2 / . / docs / design_documents / rss.rst
blob: 2be8067955ab8a23c154d5e7c9ebd456c534e1e5 [file] [log] [blame]
Tamas Banf6aed632022-10-13 16:42:48 +0200[diff] [blame]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.*