blob: 21f0ed8bcd2c1a809caea5e86a8b4f0b3d9915de [file] [log] [blame]
Tamas Baneea607c2022-10-13 16:42:48 +02001Runtime 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]_ .
laurenw-arm5b006582023-06-30 17:03:03 -0500137- ``OTP assets management``: Public keys used by AP during the trusted boot
138 process can be requested from RSS. Furthermore, AP can request RSS to
139 increase a non-volatile counter. Please refer to the
140 ``RSS key management`` [5]_ document for more details.
Tamas Baneea607c2022-10-13 16:42:48 +0200141
142Runtime service API
143^^^^^^^^^^^^^^^^^^^
144The RSS 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 | RSS 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 RSS 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
207RSS 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. RSS 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 RSS. 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 rss_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 Signer-id and version info is not implemented in TF-A yet.
264
265The caller must specify in which measurement slot to extend a certain
266measurement and metadata. A measurement slot can be extended by multiple
267measurements. The default value is IMPDEF. All measurement slot is cleared at
268reset, there is no other way to clear them. In the reference implementation,
269the measurement slots are initialized to 0. At the first call to extend the
270measurement in a slot, the extend operation uses the default value of the
271measurement slot. All upcoming extend operation on the same slot contributes
272to the previous value of that measurement slot.
273
274The following rules are kept when a slot is extended multiple times:
275
276- ``Signer-id`` must be the same as the previous call(s), otherwise a
277 PSA_ERROR_NOT_PERMITTED error code is returned.
278
279- ``Measurement algorithm``: must be the same as the previous call(s),
280 otherwise, a PSA_ERROR_NOT_PERMITTED error code is returned.
281
282In case of error no further action is taken (slot is not locked). If there is
283a valid data in a sub-sequent call then measurement slot will be extended. The
284rest of the metadata is handled as follows when a measurement slot is extended
285multiple times:
286
287- ``SW type``: Cleared.
288- ``Version info``: Cleared.
289
290.. Note::
291
292 Extending multiple measurements in the same slot leads to some metadata
293 information loss. Since RSS is not constrained on special HW resources to
294 store the measurements and metadata, therefore it is worth considering to
295 store all of them one by one in distinct slots. However, they are one-by-one
296 included in the platform attestation token. So, the number of distinct
297 firmware image measurements has an impact on the size of the attestation
298 token.
299
300The allocation of the measurement slot among RSS, Root and Realm worlds is
301platform dependent. The platform must provide an allocation of the measurement
302slot at build time. An example can be found in
303``tf-a/plat/arm/board/tc/tc_bl1_measured_boot.c``
304Furthermore, the memory, which holds the metadata is also statically allocated
305in RSS memory. Some of the fields have a static value (measurement algorithm),
306and some of the values have a dynamic value (measurement value) which is updated
307by the bootloaders when the firmware image is loaded and measured. The metadata
308structure is defined in
309``include/drivers/measured_boot/rss/rss_measured_boot.h``.
310
311.. code-block:: c
312
313 struct rss_mboot_metadata {
314 unsigned int id;
315 uint8_t slot;
316 uint8_t signer_id[SIGNER_ID_MAX_SIZE];
317 size_t signer_id_size;
318 uint8_t version[VERSION_MAX_SIZE];
319 size_t version_size;
320 uint8_t sw_type[SW_TYPE_MAX_SIZE];
321 size_t sw_type_size;
322 bool lock_measurement;
323 };
324
325Build time config options
326^^^^^^^^^^^^^^^^^^^^^^^^^
327
328- ``MEASURED_BOOT``: Enable measured boot. It depends on the platform
329 implementation whether RSS or TPM (or both) backend based measured boot is
330 enabled.
331- ``MBOOT_RSS_HASH_ALG``: Determine the hash algorithm to measure the images.
332 The default value is sha-256.
333
334Measured boot flow
335^^^^^^^^^^^^^^^^^^
336
337.. figure:: ../resources/diagrams/rss_measured_boot_flow.svg
338 :align: center
339
340Sample console log
341^^^^^^^^^^^^^^^^^^
342
343.. code-block:: bash
344
345 INFO: Measured boot extend measurement:
346 INFO: - slot : 6
347 INFO: - signer_id : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
348 INFO: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
349 INFO: - version :
350 INFO: - version_size: 0
351 INFO: - sw_type : FW_CONFIG
352 INFO: - sw_type_size: 10
353 INFO: - algorithm : 2000009
354 INFO: - measurement : aa ea d3 a7 a8 e2 ab 7d 13 a6 cb 34 99 10 b9 a1
355 INFO: : 1b 9f a0 52 c5 a8 b1 d7 76 f2 c1 c1 ef ca 1a df
356 INFO: - locking : true
357 INFO: FCONF: Config file with image ID:31 loaded at address = 0x4001010
358 INFO: Loading image id=24 at address 0x4001300
359 INFO: Image id=24 loaded: 0x4001300 - 0x400153a
360 INFO: Measured boot extend measurement:
361 INFO: - slot : 7
362 INFO: - signer_id : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
363 INFO: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
364 INFO: - version :
365 INFO: - version_size: 0
366 INFO: - sw_type : TB_FW_CONFIG
367 INFO: - sw_type_size: 13
368 INFO: - algorithm : 2000009
369 INFO: - measurement : 05 b9 dc 98 62 26 a7 1c 2d e5 bb af f0 90 52 28
370 INFO: : f2 24 15 8a 3a 56 60 95 d6 51 3a 7a 1a 50 9b b7
371 INFO: - locking : true
372 INFO: FCONF: Config file with image ID:24 loaded at address = 0x4001300
373 INFO: BL1: Loading BL2
374 INFO: Loading image id=1 at address 0x404d000
375 INFO: Image id=1 loaded: 0x404d000 - 0x406412a
376 INFO: Measured boot extend measurement:
377 INFO: - slot : 8
378 INFO: - signer_id : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
379 INFO: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
380 INFO: - version :
381 INFO: - version_size: 0
382 INFO: - sw_type : BL_2
383 INFO: - sw_type_size: 5
384 INFO: - algorithm : 2000009
385 INFO: - measurement : 53 a1 51 75 25 90 fb a1 d9 b8 c8 34 32 3a 01 16
386 INFO: : c9 9e 74 91 7d 28 02 56 3f 5c 40 94 37 58 50 68
387 INFO: - locking : true
388
389Delegated Attestation
390---------------------
391
392Delegated Attestation Service was mainly developed to support the attestation
393flow on the ``ARM Confidential Compute Architecture`` (ARM CCA) [7]_.
394The detailed description of the delegated attestation service can be found in
395the ``Delegated Attestation Service Integration Guide`` [4]_ document.
396
397In the CCA use case, the Realm Management Monitor (RMM) relies on the delegated
398attestation service of the RSS to get a realm attestation key and the CCA
399platform token. BL31 does not use the service for its own purpose, only calls
400it on behalf of RMM. The access to MHU interface and thereby to RSS is
401restricted to BL31 only. Therefore, RMM does not have direct access, all calls
402need to go through BL31. The RMM dispatcher module of the BL31 is responsible
403for delivering the calls between the two parties.
404
405.. Note::
406 Currently the connection between the RMM dispatcher and the PSA/RSS layer
407 is not yet implemented. RMM dispatcher just returns hard coded data.
408
409Delegated Attestation API
410^^^^^^^^^^^^^^^^^^^^^^^^^
411Defined here:
412
413- ``include/lib/psa/delegated_attestation.h``
414
415.. code-block:: c
416
417 psa_status_t
418 rss_delegated_attest_get_delegated_key(uint8_t ecc_curve,
419 uint32_t key_bits,
420 uint8_t *key_buf,
421 size_t key_buf_size,
422 size_t *key_size,
423 uint32_t hash_algo);
424
425 psa_status_t
426 rss_delegated_attest_get_token(const uint8_t *dak_pub_hash,
427 size_t dak_pub_hash_size,
428 uint8_t *token_buf,
429 size_t token_buf_size,
430 size_t *token_size);
431
432Attestation flow
433^^^^^^^^^^^^^^^^
434
435.. figure:: ../resources/diagrams/rss_attestation_flow.svg
436 :align: center
437
438Sample attestation token
439^^^^^^^^^^^^^^^^^^^^^^^^
440
441Binary format:
442
443.. code-block:: bash
444
445 INFO: DELEGATED ATTEST TEST START
446 INFO: Get delegated attestation key start
447 INFO: Get delegated attest key succeeds, len: 48
448 INFO: Delegated attest key:
449 INFO: 0d 2a 66 61 d4 89 17 e1 70 c6 73 56 df f4 11 fd
450 INFO: 7d 1f 3b 8a a3 30 3d 70 4c d9 06 c3 c7 ef 29 43
451 INFO: 0f ee b5 e7 56 e0 71 74 1b c4 39 39 fd 85 f6 7b
452 INFO: Get platform token start
453 INFO: Get platform token succeeds, len: 1086
454 INFO: Platform attestation token:
455 INFO: d2 84 44 a1 01 38 22 a0 59 03 d1 a9 0a 58 20 00
456 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
457 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 19
458 INFO: 01 00 58 21 01 cb 8c 79 f7 a0 0a 6c ce 12 66 f8
459 INFO: 64 45 48 42 0e c5 10 bf 84 ee 22 18 b9 8f 11 04
460 INFO: c7 22 31 9d fb 19 09 5c 58 20 aa aa aa aa aa aa
461 INFO: aa aa bb bb bb bb bb bb bb bb cc cc cc cc cc cc
462 INFO: cc cc dd dd dd dd dd dd dd dd 19 09 5b 19 30 00
463 INFO: 19 09 5f 89 a4 05 58 20 bf e6 d8 6f 88 26 f4 ff
464 INFO: 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d a2 6a
465 INFO: df 34 c3 29 48 9a dc 38 04 67 31 2e 36 2e 30 2b
466 INFO: 30 01 64 52 54 5f 30 02 58 20 90 27 f2 46 ab 31
467 INFO: 85 36 46 c4 d7 c6 60 ed 31 0d 3c f0 14 de f0 6c
468 INFO: 24 0b de b6 7a 84 fc 3f 5b b7 a4 05 58 20 b3 60
469 INFO: ca f5 c9 8c 6b 94 2a 48 82 fa 9d 48 23 ef b1 66
470 INFO: a9 ef 6a 6e 4a a3 7c 19 19 ed 1f cc c0 49 04 67
471 INFO: 30 2e 30 2e 30 2b 30 01 64 52 54 5f 31 02 58 20
472 INFO: 52 13 15 d4 9d b2 cf 54 e4 99 37 44 40 68 f0 70
473 INFO: 7d 73 64 ae f7 08 14 b0 f7 82 ad c6 17 db a3 91
474 INFO: a4 05 58 20 bf e6 d8 6f 88 26 f4 ff 97 fb 96 c4
475 INFO: e6 fb c4 99 3e 46 19 fc 56 5d a2 6a df 34 c3 29
476 INFO: 48 9a dc 38 04 67 31 2e 35 2e 30 2b 30 01 64 52
477 INFO: 54 5f 32 02 58 20 8e 5d 64 7e 6f 6c c6 6f d4 4f
478 INFO: 54 b6 06 e5 47 9a cc 1b f3 7f ce 87 38 49 c5 92
479 INFO: d8 2f 85 2e 85 42 a4 05 58 20 bf e6 d8 6f 88 26
480 INFO: f4 ff 97 fb 96 c4 e6 fb c4 99 3e 46 19 fc 56 5d
481 INFO: a2 6a df 34 c3 29 48 9a dc 38 04 67 31 2e 35 2e
482 INFO: 30 2b 30 01 60 02 58 20 b8 01 65 a7 78 8b c6 59
483 INFO: 42 8d 33 10 85 d1 49 0a dc 9e c3 ee df 85 1b d2
484 INFO: f0 73 73 6a 0c 07 11 b8 a4 05 58 20 00 00 00 00
485 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
486 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 04 60 01 6a
487 INFO: 46 57 5f 43 4f 4e 46 49 47 00 02 58 20 21 9e a0
488 INFO: 13 82 e6 d7 97 5a 11 13 a3 5f 45 39 68 b1 d9 a3
489 INFO: ea 6a ab 84 23 3b 8c 06 16 98 20 ba b9 a4 05 58
490 INFO: 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
491 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
492 INFO: 00 04 60 01 6d 54 42 5f 46 57 5f 43 4f 4e 46 49
493 INFO: 47 00 02 58 20 41 39 f6 c2 10 84 53 c5 17 ae 9a
494 INFO: e5 be c1 20 7b cc 24 24 f3 9d 20 a8 fb c7 b3 10
495 INFO: e3 ee af 1b 05 a4 05 58 20 00 00 00 00 00 00 00
496 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
497 INFO: 00 00 00 00 00 00 00 00 00 04 60 01 65 42 4c 5f
498 INFO: 32 00 02 58 20 5c 96 20 e1 e3 3b 0f 2c eb c1 8e
499 INFO: 1a 02 a6 65 86 dd 34 97 a7 4c 98 13 bf 74 14 45
500 INFO: 2d 30 28 05 c3 a4 05 58 20 00 00 00 00 00 00 00
501 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
502 INFO: 00 00 00 00 00 00 00 00 00 04 60 01 6e 53 45 43
503 INFO: 55 52 45 5f 52 54 5f 45 4c 33 00 02 58 20 f6 fb
504 INFO: 62 99 a5 0c df db 02 0b 72 5b 1c 0b 63 6e 94 ee
505 INFO: 66 50 56 3a 29 9c cb 38 f0 ec 59 99 d4 2e a4 05
506 INFO: 58 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00
507 INFO: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
508 INFO: 00 00 04 60 01 6a 48 57 5f 43 4f 4e 46 49 47 00
509 INFO: 02 58 20 98 5d 87 21 84 06 33 9d c3 1f 91 f5 68
510 INFO: 8d a0 5a f0 d7 7e 20 51 ce 3b f2 a5 c3 05 2e 3c
511 INFO: 8b 52 31 19 01 09 78 1c 68 74 74 70 3a 2f 2f 61
512 INFO: 72 6d 2e 63 6f 6d 2f 43 43 41 2d 53 53 44 2f 31
513 INFO: 2e 30 2e 30 19 09 62 71 6e 6f 74 2d 68 61 73 68
514 INFO: 2d 65 78 74 65 6e 64 65 64 19 09 61 44 ef be ad
515 INFO: de 19 09 60 77 77 77 77 2e 74 72 75 73 74 65 64
516 INFO: 66 69 72 6d 77 61 72 65 2e 6f 72 67 58 60 29 4e
517 INFO: 4a d3 98 1e 3b 70 9f b6 66 ed 47 33 0e 99 f0 b1
518 INFO: c3 f2 bc b2 1d b0 ae 90 0c c4 82 ff a2 6f ae 45
519 INFO: f6 87 09 4a 09 21 77 ec 36 1c 53 b8 a7 9b 8e f7
520 INFO: 27 eb 7a 09 da 6f fb bf cb fd b3 e5 e9 36 91 b1
521 INFO: 92 13 c1 30 16 b4 5c 49 5e c0 c1 b9 01 5c 88 2c
522 INFO: f8 2f 3e a4 a2 6d e4 9d 31 6a 06 f7 a7 73
523 INFO: DELEGATED ATTEST TEST END
524
525JSON format:
526
527.. code-block:: JSON
528
529 {
530 "CCA_PLATFORM_CHALLENGE": "b'0000000000000000000000000000000000000000000000000000000000000000'",
531 "CCA_PLATFORM_INSTANCE_ID": "b'01CB8C79F7A00A6CCE1266F8644548420EC510BF84EE2218B98F1104C722319DFB'",
532 "CCA_PLATFORM_IMPLEMENTATION_ID": "b'AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD'",
533 "CCA_PLATFORM_LIFECYCLE": "secured_3000",
534 "CCA_PLATFORM_SW_COMPONENTS": [
535 {
536 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'",
537 "SW_COMPONENT_VERSION": "1.6.0+0",
538 "SW_COMPONENT_TYPE": "RT_0",
539 "MEASUREMENT_VALUE": "b'9027F246AB31853646C4D7C660ED310D3CF014DEF06C240BDEB67A84FC3F5BB7'"
540 },
541 {
542 "SIGNER_ID": "b'B360CAF5C98C6B942A4882FA9D4823EFB166A9EF6A6E4AA37C1919ED1FCCC049'",
543 "SW_COMPONENT_VERSION": "0.0.0+0",
544 "SW_COMPONENT_TYPE": "RT_1",
545 "MEASUREMENT_VALUE": "b'521315D49DB2CF54E49937444068F0707D7364AEF70814B0F782ADC617DBA391'"
546 },
547 {
548 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'",
549 "SW_COMPONENT_VERSION": "1.5.0+0",
550 "SW_COMPONENT_TYPE": "RT_2",
551 "MEASUREMENT_VALUE": "b'8E5D647E6F6CC66FD44F54B606E5479ACC1BF37FCE873849C592D82F852E8542'"
552 },
553 {
554 "SIGNER_ID": "b'BFE6D86F8826F4FF97FB96C4E6FBC4993E4619FC565DA26ADF34C329489ADC38'",
555 "SW_COMPONENT_VERSION": "1.5.0+0",
556 "SW_COMPONENT_TYPE": "",
557 "MEASUREMENT_VALUE": "b'B80165A7788BC659428D331085D1490ADC9EC3EEDF851BD2F073736A0C0711B8'"
558 },
559 {
560 "SIGNER_ID": "b'0000000000000000000000000000000000000000000000000000000000000000'",
561 "SW_COMPONENT_VERSION": "",
562 "SW_COMPONENT_TYPE": "FW_CONFIG\u0000",
563 "MEASUREMENT_VALUE": "b'219EA01382E6D7975A1113A35F453968B1D9A3EA6AAB84233B8C06169820BAB9'"
564 },
565 {
566 "SIGNER_ID": "b'0000000000000000000000000000000000000000000000000000000000000000'",
567 "SW_COMPONENT_VERSION": "",
568 "SW_COMPONENT_TYPE": "TB_FW_CONFIG\u0000",
569 "MEASUREMENT_VALUE": "b'4139F6C2108453C517AE9AE5BEC1207BCC2424F39D20A8FBC7B310E3EEAF1B05'"
570 },
571 {
572 "SIGNER_ID": "b'0000000000000000000000000000000000000000000000000000000000000000'",
573 "SW_COMPONENT_VERSION": "",
574 "SW_COMPONENT_TYPE": "BL_2\u0000",
575 "MEASUREMENT_VALUE": "b'5C9620E1E33B0F2CEBC18E1A02A66586DD3497A74C9813BF7414452D302805C3'"
576 },
577 {
578 "SIGNER_ID": "b'0000000000000000000000000000000000000000000000000000000000000000'",
579 "SW_COMPONENT_VERSION": "",
580 "SW_COMPONENT_TYPE": "SECURE_RT_EL3\u0000",
581 "MEASUREMENT_VALUE": "b'F6FB6299A50CDFDB020B725B1C0B636E94EE6650563A299CCB38F0EC5999D42E'"
582 },
583 {
584 "SIGNER_ID": "b'0000000000000000000000000000000000000000000000000000000000000000'",
585 "SW_COMPONENT_VERSION": "",
586 "SW_COMPONENT_TYPE": "HW_CONFIG\u0000",
587 "MEASUREMENT_VALUE": "b'985D87218406339DC31F91F5688DA05AF0D77E2051CE3BF2A5C3052E3C8B5231'"
588 }
589 ],
590 "CCA_ATTESTATION_PROFILE": "http://arm.com/CCA-SSD/1.0.0",
591 "CCA_PLATFORM_HASH_ALGO_ID": "not-hash-extended",
592 "CCA_PLATFORM_CONFIG": "b'EFBEADDE'",
593 "CCA_PLATFORM_VERIFICATION_SERVICE": "www.trustedfirmware.org"
594 }
595
laurenw-arm5b006582023-06-30 17:03:03 -0500596RSS OTP Assets Management
597-------------------------
598
599RSS provides access for AP to assets in OTP, which include keys for image
600signature verification and non-volatile counters for anti-rollback protection.
601
602Non-Volatile Counter API
603^^^^^^^^^^^^^^^^^^^^^^^^
604
605AP/RSS interface for retrieving and incrementing non-volatile counters API is
606as follows.
607
608Defined here:
609
610- ``include/lib/psa/rss_platform_api.h``
611
612.. code-block:: c
613
614 psa_status_t rss_platform_nv_counter_increment(uint32_t counter_id)
615
616 psa_status_t rss_platform_nv_counter_read(uint32_t counter_id,
617 uint32_t size, uint8_t *val)
618
619Through this service, we can read/increment any of the 3 non-volatile
620counters used on an Arm CCA platform:
621
622- ``Non-volatile counter for CCA firmware (BL2, BL31, RMM).``
623- ``Non-volatile counter for secure firmware.``
624- ``Non-volatile counter for non-secure firmware.``
625
626Public Key API
627^^^^^^^^^^^^^^
628
629AP/RSS interface for reading the ROTPK is as follows.
630
631Defined here:
632
633- ``include/lib/psa/rss_platform_api.h``
634
635.. code-block:: c
636
637 psa_status_t rss_platform_key_read(enum rss_key_id_builtin_t key,
638 uint8_t *data, size_t data_size, size_t *data_length)
639
640Through this service, we can read any of the 3 ROTPKs used on an
641Arm CCA platform:
642
643- ``ROTPK for CCA firmware (BL2, BL31, RMM).``
644- ``ROTPK for secure firmware.``
645- ``ROTPK for non-secure firmware.``
646
Tamas Baneea607c2022-10-13 16:42:48 +0200647References
648----------
649
650.. [1] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/readme.html
651.. [2] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_comms.html
652.. [3] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/measured_boot/measured_boot_integration_guide.rst
653.. [4] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/delegated_attestation/delegated_attest_integration_guide.rst
654.. [5] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_management.html
655.. [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
656.. [7] https://developer.arm.com/documentation/DEN0096/A_a/?lang=en
657
658--------------
659
660*Copyright (c) 2023, Arm Limited. All rights reserved.*