10.5.Runtime Security Engine (RSE)
This document focuses on the relationship between the Runtime Security Engine(RSE) and the application processor (AP). According to the ARM reference designthe RSE is an independent core next to the AP and the SCP on the same die. Itprovides fundamental security guarantees and runtime services for the rest ofthe system (e.g.: trusted boot, measured boot, platform attestation,key management, and key derivation).
At power up RSE boots first from its private ROM code. It validates and loadsits own images and the initial images of SCP and AP. When AP and SCP arereleased from reset and their initial code is loaded then they continue theirown boot process, which is the same as on non-RSE systems. Please refer to theRSEdocumentation[1] for more details about the RSE boot flow.
The last stage of the RSE firmware is a persistent, runtime component. Muchlike AP_BL31, this is a passive entity which has no periodical task to do andjust waits for external requests from other subsystems. RSE and othersubsystems can communicate with each other over message exchange. RSE waitsin idle for the incoming request, handles them, and sends a response then goesback to idle.
10.5.1.RSE communication layer
The communication between RSE and other subsystems are primarily relying on theMessage Handling Unit (MHU) module.
However, this is possible to use this communication protocol with a differentmailbox than MHU, by setting the flagPLAT_MHU=NO_MHU and implementing theAPIs given in the file:include/drivers/arm/rse_comms.h.
The number of MHU interfaces between RSE and other cores is IMPDEF. Besides MHUother modules also could take part in the communication. RSE is capable ofmapping the AP memory to its address space.Thereby either RSE core itself or a DMA engine if it is present, can move thedata between memory belonging to RSE or AP. In this way, a bigger amount of datacan be transferred in a short time.
The MHU comes in pairs. There is a sender and receiver side. They are connectedto each other. An MHU interface consists of two pairs of MHUs, one sender andone receiver on both sides. Bidirectional communication is possible over aninterface. One pair provides message sending from AP to RSE and the other pairfrom RSE to AP. The sender and receiver are connected via channels. There is anIMPDEF number of channels (e.g: 4-16) between a sender and a receiver module.
The RSE communication layer provides two ways for message exchange:
Embeddedmessaging: The full message, including header and payload, areexchanged over the MHU channels. A channel is capable of delivering a singleword. The sender writes the data to the channel register on its side and thereceiver can read the data from the channel on the other side. One dedicatedchannel is used for signalling. It does not deliver any payload it is justmeant for signalling that the sender loaded the data to the channel registersso the receiver can read them. The receiver uses the same channel to signalthat data was read. Signalling happens via IRQ. If the message is longer thanthe data fit to the channel registers then the message is sent over inmultiple rounds. Both, sender and receiver allocate a local buffer for themessages. Data is copied from/to these buffers to/from the channel registers.Pointer-accessmessaging: The message header and the payload areseparated and they are conveyed in different ways. The header is sentover the channels, similar to the embedded messaging but the payload iscopied over by RSE core (or by DMA) between the sender and the receiver. Thiscould be useful in the case of long messages because transaction time is lesscompared to the embedded messaging mode. Small payloads are copied by the RSEcore because setting up DMA would require more CPU cycles. The payload iseither copied into an internal buffer or directly read-written by RSE. Actualbehavior depends on RSE setup, whether the partition supports memory-mappediovec. Therefore, the sender must handle both cases and prevent access tothe memory, where payload data lives, while the RSE handles the request.
The RSE communication layer supports both ways of messaging in parallel. It isdecided at runtime based on the message size which way to transfer the message.
+----------------------------------------------++-------------------+|||||AP|||||+--->|SRAM|+----------------------------------------------|||||BL1/BL2/BL31||||+----------------------------------------------+|+-------------------+|^|^^|sendIRQ|receive|direct||V||access||+--------------------++--------------------+||||MHUsender||MHUreceiver|||Copydata|+--------------------++--------------------+||||||||||||||||channels||||channels|||||||e.g:4-16||||e.g:4-16|||V|+--------------------++--------------------+|+-------+||MHUreceiver||MHUsender||+->|DMA||+--------------------++--------------------+||+-------+||^||^|IRQ|receive|send|||Copydata|V|||VV+----------------------------------------------+||+-------------------+||--+-+|||RSE||SRAM|||||+----------------------------------------------++-------------------+
Note
The RSE communication layer is not prepared for concurrent execution. Thecurrent use case only requires message exchange during the boot phase. Inthe boot phase, only a single core is running and the rest of the cores arein reset.
10.5.1.1.Message structure
A description of the message format can be found in theRSEcommunicationdesign[2] document.
10.5.1.2.Source files
RSE comms:
drivers/arm/rseMHU driver:
drivers/arm/mhu
10.5.1.3.API for communication over MHU
The API is defined in these header files:
include/drivers/arm/rse_comms.hinclude/drivers/arm/mhu.h
10.5.2.RSE provided runtime services
RSE provides the following runtime services:
Measuredboot: Securely store the firmware measurements which werecomputed during the boot process and the associated metadata (imagedescription, measurement algorithm, etc.). More info on measured boot servicein RSE can be found in themeasured_boot_integration_guide[3] .Delegatedattestation: Query the platform attestation token and derive adelegated attestation key. More info on the delegated attestation servicein RSE can be found in thedelegated_attestation_integration_guide[4] .OTPassetsmanagement: Public keys used by AP during the trusted bootprocess can be requested from RSE. Furthermore, AP can request RSE toincrease a non-volatile counter. Please refer to theRSEkeymanagement[5] document for more details.DICEProtectionEnvironment: Securely store the firmware measurementswhich were computed during the boot process and the associated metadata. It isalso capable of representing the boot measurements in the form of acertificate chain, which is queriable. Please refer to theDICEProtectionEnvironment(DPE)[8] document for more details.
10.5.2.1.Runtime service API
The RSE provided runtime services implement a PSA aligned API. The parameterencoding follows the PSA client protocol described in theFirmwareFrameworkforM[6] document in chapter 4.4. The implementation isrestricted to the static handle use case therefore only thepsa_call API isimplemented.
10.5.2.2.Software and API layers
+----------------++---------------------+|BL1/BL2||BL31|+----------------++---------------------+|||extend_measurement()|get_delegated_key()||get_platform_token()VV+----------------++---------------------+|PSAprotocol||PSAprotocol|+----------------++---------------------+|||psa_call()|psa_call()||VV+------------------------------------------------+|RSEcommunicationprotocol|+------------------------------------------------+|^|mhu_send_data()|mhu_receive_data()||V|+------------------------------------------------+|MHUdriver|+------------------------------------------------+|^|Registeraccess|IRQV|+------------------------------------------------+|MHUHWonAPside|+------------------------------------------------+^|Physicalwires|V+------------------------------------------------+|MHUHWonRSEside|+------------------------------------------------+|^|IRQ|RegisteraccessV|+------------------------------------------------+|MHUdriver|+------------------------------------------------+||VV+---------------++------------------------+|Measuredboot||Delegatedattestation||service||service|+---------------++------------------------+
10.5.3.RSE based Measured Boot
Measured Boot is the process of cryptographically measuring (computing the hashvalue of a binary) the code and critical data used at boot time. Themeasurement must be stored in a tamper-resistant way, so the security stateof the device can be attested later to an external party. RSE provides a runtimeservice which is meant to store measurements and associated metadata alongside.
Data is stored in internal SRAM which is only accessible by the secure runtimefirmware of RSE. Data is stored in so-called measurement slots. A platform hasIMPDEF number of measurement slots. The measurement storage follows extendsemantics. This means that measurements are not stored directly (as it wastaken) instead they contribute to the current value of the measurement slot.The extension implements this logic, where|| stands for concatenation:
new_value_of_measurement_slot=Hash(old_value_of_measurement_slot||measurement)
Supported hash algorithms: sha-256, sha-512
10.5.3.1.Measured Boot API
Defined here:
include/lib/psa/measured_boot.h
psa_status_trse_measured_boot_extend_measurement(uint8_tindex,constuint8_t*signer_id,size_tsigner_id_size,constuint8_t*version,size_tversion_size,uint32_tmeasurement_algo,constuint8_t*sw_type,size_tsw_type_size,constuint8_t*measurement_value,size_tmeasurement_value_size,boollock_measurement);
10.5.3.2.Measured Boot Metadata
The following metadata can be stored alongside the measurement:
Signer-id: Mandatory. The hash of the firmware image signing public key.Measurementalgorithm: Optional. The hash algorithm which was used tocompute the measurement (e.g.: sha-256, etc.).Versioninfo: Optional. The firmware version info (e.g.: 2.7).SWtype: Optional. Short text description (e.g.: BL1, BL2, BL31, etc.)
Note
Version info is not implemented in TF-A yet.
The caller must specify in which measurement slot to extend a certainmeasurement and metadata. A measurement slot can be extended by multiplemeasurements. The default value is IMPDEF. All measurement slot is cleared atreset, there is no other way to clear them. In the reference implementation,the measurement slots are initialized to 0. At the first call to extend themeasurement in a slot, the extend operation uses the default value of themeasurement slot. All upcoming extend operation on the same slot contributesto the previous value of that measurement slot.
The following rules are kept when a slot is extended multiple times:
Signer-idmust be the same as the previous call(s), otherwise aPSA_ERROR_NOT_PERMITTED error code is returned.Measurementalgorithm: must be the same as the previous call(s),otherwise, a PSA_ERROR_NOT_PERMITTED error code is returned.
In case of error no further action is taken (slot is not locked). If there isa valid data in a sub-sequent call then measurement slot will be extended. Therest of the metadata is handled as follows when a measurement slot is extendedmultiple times:
SWtype: Cleared.Versioninfo: Cleared.
Note
Extending multiple measurements in the same slot leads to some metadatainformation loss. Since RSE is not constrained on special HW resources tostore the measurements and metadata, therefore it is worth considering tostore all of them one by one in distinct slots. However, they are one-by-oneincluded in the platform attestation token. So, the number of distinctfirmware image measurements has an impact on the size of the attestationtoken.
The allocation of the measurement slot among RSE, Root and Realm worlds isplatform dependent. The platform must provide an allocation of the measurementslot at build time. An example can be found intf-a/plat/arm/board/tc/tc_bl1_measured_boot.cFurthermore, the memory, which holds the metadata is also statically allocatedin RSE memory. Some of the fields have a static value (measurement algorithm),and some of the values have a dynamic value (measurement value) which is updatedby the bootloaders when the firmware image is loaded and measured. The metadatastructure is defined ininclude/drivers/measured_boot/rse/rse_measured_boot.h.
structrse_mboot_metadata{unsignedintid;uint8_tslot;uint8_tsigner_id[SIGNER_ID_MAX_SIZE];size_tsigner_id_size;uint8_tversion[VERSION_MAX_SIZE];size_tversion_size;uint8_tsw_type[SW_TYPE_MAX_SIZE];size_tsw_type_size;void*pk_oid;boollock_measurement;};
10.5.3.3.Signer-ID API
This function calculates the hash of a public key (signer-ID) using theMeasurementalgorithm and stores it in therse_mboot_metadata fieldnamedsigner_id.Prior to calling this function, the caller must ensure that thesigner_idfield points to the zero-filled buffer.
Defined here:
include/drivers/measured_boot/rse/rse_measured_boot.h
intrse_mboot_set_signer_id(structrse_mboot_metadata*metadata_ptr,constvoid*pk_oid,constvoid*pk_ptr,size_tpk_len)
First parameter is the pointer to the
rse_mboot_metadatastructure.Second parameter is the pointer to the key-OID of the public key.
Third parameter is the pointer to the public key buffer.
Fourth parameter is the size of public key buffer.
This function returns 0 on success, a signed integer error codeotherwise.
10.5.3.4.Build time config options
MEASURED_BOOT: Enable measured boot.MBOOT_RSE_HASH_ALG: Determine the hash algorithm to measure the images.The default value is sha-256.
10.5.3.5.Measured boot flow
10.5.3.6.Sample console log
INFO:Measuredbootextendmeasurement:INFO:-slot:6INFO:-signer_id:00000000000000000000000000000000INFO::00000000000000000000000000000000INFO:-version:INFO:-version_size:0INFO:-sw_type:FW_CONFIGINFO:-sw_type_size:10INFO:-algorithm:2000009INFO:-measurement:aaead3a7a8e2ab7d13a6cb349910b9a1INFO::1b9fa052c5a8b1d776f2c1c1efca1adfINFO:-locking:trueINFO:FCONF:ConfigfilewithimageID:31loadedataddress=0x4001010INFO:Loadingimageid=24ataddress0x4001300INFO:Imageid=24loaded:0x4001300-0x400153aINFO:Measuredbootextendmeasurement:INFO:-slot:7INFO:-signer_id:b0f382091297d83a377a72471bec3273INFO::e99232e24959f65e8b4a4a46d8229adaINFO:-version:INFO:-version_size:0INFO:-sw_type:TB_FW_CONFIGINFO:-sw_type_size:13INFO:-algorithm:2000009INFO:-measurement:05b9dc986226a71c2de5bbaff0905228INFO::f224158a3a566095d6513a7a1a509bb7INFO:-locking:trueINFO:FCONF:ConfigfilewithimageID:24loadedataddress=0x4001300INFO:BL1:LoadingBL2INFO:Loadingimageid=1ataddress0x404d000INFO:Imageid=1loaded:0x404d000-0x406412aINFO:Measuredbootextendmeasurement:INFO:-slot:8INFO:-signer_id:b0f382091297d83a377a72471bec3273INFO::e99232e24959f65e8b4a4a46d8229adaINFO:-version:INFO:-version_size:0INFO:-sw_type:BL_2INFO:-sw_type_size:5INFO:-algorithm:2000009INFO:-measurement:53a151752590fba1d9b8c834323a0116INFO::c99e74917d2802563f5c409437585068INFO:-locking:true
10.5.4.Delegated Attestation
Delegated Attestation Service was mainly developed to support the attestationflow on theARMConfidentialComputeArchitecture (ARM CCA)[7].The detailed description of the delegated attestation service can be found intheDelegatedAttestationServiceIntegrationGuide[4] document.
In the CCA use case, the Realm Management Monitor (RMM) relies on the delegatedattestation service of the RSE to get a realm attestation key and the CCAplatform token. BL31 does not use the service for its own purpose, only callsit on behalf of RMM. The access to MHU interface and thereby to RSE isrestricted to BL31 only. Therefore, RMM does not have direct access, all callsneed to go through BL31. The RMM dispatcher module of the BL31 is responsiblefor delivering the calls between the two parties.
10.5.4.1.Delegated Attestation API
Defined here:
include/lib/psa/delegated_attestation.h
psa_status_trse_delegated_attest_get_delegated_key(uint8_tecc_curve,uint32_tkey_bits,uint8_t*key_buf,size_tkey_buf_size,size_t*key_size,uint32_thash_algo);psa_status_trse_delegated_attest_get_token(constuint8_t*dak_pub_hash,size_tdak_pub_hash_size,uint8_t*token_buf,size_ttoken_buf_size,size_t*token_size);
10.5.4.2.Attestation flow
10.5.4.3.Sample attestation token
Binary format:
INFO:DELEGATEDATTESTTESTSTARTINFO:GetdelegatedattestationkeystartINFO:Getdelegatedattestkeysucceeds,len:48INFO:Delegatedattestkey:INFO:0d2a6661d48917e170c67356dff411fdINFO:7d1f3b8aa3303d704cd906c3c7ef2943INFO:0feeb5e756e071741bc43939fd85f67bINFO:GetplatformtokenstartINFO:Getplatformtokensucceeds,len:1086INFO:Platformattestationtoken:INFO:d28444a1013822a0590581a919010978INFO:237461673a61726d2e636f6d2c323032INFO:333a6363615f706c6174666f726d2331INFO:2e302e300a58200d22e08a9846905848INFO:6318283489bdb36f09dbefeb1864df43INFO:3fa6e54ea2d71119095c58207f454c46INFO:02010100000000000000000003003e00INFO:01000000505800000000000019010058INFO:210107060504030201000f0e0d0c0b0aINFO:090817161514131211101f1e1d1c1b1aINFO:191819096144cfcfcfcf19095b193003INFO:190962677368612d323536190960783aINFO:68747470733a2f2f7665726169736f6eINFO:2e6578616d706c652f2e77656c6c2d6bINFO:6e6f776e2f7665726169736f6e2f7665INFO:72696669636174696f6e19095f8da401INFO:695253455f424c315f32055820537879INFO:6307535df3ec8d8b15a2e2dc5641419cINFO:3d3060cfe32238c0fa973f7aa3025820INFO:9a271f2a916b0b6ee6cecb2426f0b320INFO:6ef074578be55d9bc94f6f3fe3ab86aaINFO:06677368612d323536a401675253455fINFO:424c320558205378796307535df3ec8dINFO:8b15a2e2dc5641419c3d3060cfe32238INFO:c0fa973f7aa302582053c234e5e8472bINFO:6ac51c1ae1cab3fe06fad053beb8ebfdINFO:8977b010655bfdd3c306677368612d32INFO:3536a401655253455f53055820537879INFO:6307535df3ec8d8b15a2e2dc5641419cINFO:3d3060cfe32238c0fa973f7aa3025820INFO:1121cfccd5913f0a63fec40a6ffd44eaINFO:64f9dc135c66634ba001d10bcf4302a2INFO:06677368612d323536a4016641505f42INFO:4c310558205378796307535df3ec8d8bINFO:15a2e2dc5641419c3d3060cfe32238c0INFO:fa973f7aa30258201571b5ec78bd6851INFO:2bf7830bb6a2a44b2047c7df57bce79eINFO:b8a1c0e5bea0a50106677368612d3235INFO:36a4016641505f424c32055820537879INFO:6307535df3ec8d8b15a2e2dc5641419cINFO:3d3060cfe32238c0fa973f7aa3025820INFO:10159baf262b43a92d95db59dae1f72cINFO:645127301661e0a3ce4e38b295a97c58INFO:06677368612d323536a401675343505fINFO:424c310558205378796307535df3ec8dINFO:8b15a2e2dc5641419c3d3060cfe32238INFO:c0fa973f7aa302582010122e856b3fcdINFO:49f063636317476149cb730a1aa1cfaaINFO:d818552b72f56d6f6806677368612d32INFO:3536a401675343505f424c32055820f1INFO:4b4987904bcb5814e4459a057ed4d20fINFO:58a633152288a761214dcd28780b5602INFO:5820aa67a169b0bba217aa0aa88a6534INFO:6920c84c42447c36ba5f7ea65f422c1fINFO:e5d806677368612d323536a401674150INFO:5f424c33310558205378796307535df3INFO:ec8d8b15a2e2dc5641419c3d3060cfe3INFO:2238c0fa973f7aa30258202e6d31a598INFO:3a91251bfae5aefa1c0a19d8ba3cf601INFO:d0e8a706b4cfa9661a6b8a0667736861INFO:2d323536a40163524d4d055820537879INFO:6307535df3ec8d8b15a2e2dc5641419cINFO:3d3060cfe32238c0fa973f7aa3025820INFO:a1fb50e6c86fae1679ef3351296fd671INFO:3411a08cf8dd1790a4fd05fae8688164INFO:06677368612d323536a4016948575f43INFO:4f4e4649470558205378796307535df3INFO:ec8d8b15a2e2dc5641419c3d3060cfe3INFO:2238c0fa973f7aa30258201a25240297INFO:2f6057fa53cc172b52b9ffca698e1831INFO:1facd0f3b06ecaaef79e170667736861INFO:2d323536a4016946575f434f4e464947INFO:0558205378796307535df3ec8d8b15a2INFO:e2dc5641419c3d3060cfe32238c0fa97INFO:3f7aa30258209a92adbc0cee38ef658cINFO:71ce1b1bf8c65668f166bfb213644c89INFO:5ccb1ad07a2506677368612d323536a4INFO:016c54425f46575f434f4e4649470558INFO:205378796307535df3ec8d8b15a2e2dcINFO:5641419c3d3060cfe32238c0fa973f7aINFO:a3025820238903180cc104ec2c5d8b3fINFO:20c5bc61b389ec0a967df8cc208cdc7cINFO:d454174f06677368612d323536a4016dINFO:534f435f46575f434f4e464947055820INFO:5378796307535df3ec8d8b15a2e2dc56INFO:41419c3d3060cfe32238c0fa973f7aa3INFO:025820e6c21e8d260fe71882debdb339INFO:d2402a2ca7648529bc2303f48649bce0INFO:38001706677368612d323536586031d0INFO:4d52ccde952c1e32cba181885a40b8ccINFO:38e0528c1e89589807642aa5e3f2bc37INFO:f95374506bff4d2e4be7063c4d724192INFO:70c722e8d4d93ee8b6c9face3b43c976INFO:1a49941ab6f38ffdff496ad463b4cbfaINFO:11d83e23e31f7f62329de30c1cc8INFO:DELEGATEDATTESTTESTEND
JSON format:
{"CCA_ATTESTATION_PROFILE":"tag:arm.com,2023:cca_platform#1.0.0","CCA_PLATFORM_CHALLENGE":"b'0D22E08A98469058486318283489BDB36F09DBEFEB1864DF433FA6E54EA2D711'","CCA_PLATFORM_IMPLEMENTATION_ID":"b'7F454C4602010100000000000000000003003E00010000005058000000000000'","CCA_PLATFORM_INSTANCE_ID":"b'0107060504030201000F0E0D0C0B0A090817161514131211101F1E1D1C1B1A1918'","CCA_PLATFORM_CONFIG":"b'CFCFCFCF'","CCA_PLATFORM_LIFECYCLE":"secured_3003","CCA_PLATFORM_HASH_ALGO_ID":"sha-256","CCA_PLATFORM_VERIFICATION_SERVICE":"https://veraison.example/.well-known/veraison/verification","CCA_PLATFORM_SW_COMPONENTS":[{"SW_COMPONENT_TYPE":"RSE_BL1_2","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'9A271F2A916B0B6EE6CECB2426F0B3206EF074578BE55D9BC94F6F3FE3AB86AA'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"RSE_BL2","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'53C234E5E8472B6AC51C1AE1CAB3FE06FAD053BEB8EBFD8977B010655BFDD3C3'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"RSE_S","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'1121CFCCD5913F0A63FEC40A6FFD44EA64F9DC135C66634BA001D10BCF4302A2'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"AP_BL1","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'1571B5EC78BD68512BF7830BB6A2A44B2047C7DF57BCE79EB8A1C0E5BEA0A501'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"AP_BL2","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'10159BAF262B43A92D95DB59DAE1F72C645127301661E0A3CE4E38B295A97C58'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"SCP_BL1","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'10122E856B3FCD49F063636317476149CB730A1AA1CFAAD818552B72F56D6F68'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"SCP_BL2","SIGNER_ID":"b'F14B4987904BCB5814E4459A057ED4D20F58A633152288A761214DCD28780B56'","MEASUREMENT_VALUE":"b'AA67A169B0BBA217AA0AA88A65346920C84C42447C36BA5F7EA65F422C1FE5D8'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"AP_BL31","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'2E6D31A5983A91251BFAE5AEFA1C0A19D8BA3CF601D0E8A706B4CFA9661A6B8A'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"RMM","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'A1FB50E6C86FAE1679EF3351296FD6713411A08CF8DD1790A4FD05FAE8688164'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"HW_CONFIG","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'1A252402972F6057FA53CC172B52B9FFCA698E18311FACD0F3B06ECAAEF79E17'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"FW_CONFIG","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'9A92ADBC0CEE38EF658C71CE1B1BF8C65668F166BFB213644C895CCB1AD07A25'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"TB_FW_CONFIG","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'238903180CC104EC2C5D8B3F20C5BC61B389EC0A967DF8CC208CDC7CD454174F'","CCA_SW_COMPONENT_HASH_ID":"sha-256"},{"SW_COMPONENT_TYPE":"SOC_FW_CONFIG","SIGNER_ID":"b'5378796307535DF3EC8D8B15A2E2DC5641419C3D3060CFE32238C0FA973F7AA3'","MEASUREMENT_VALUE":"b'E6C21E8D260FE71882DEBDB339D2402A2CA7648529BC2303F48649BCE0380017'","CCA_SW_COMPONENT_HASH_ID":"sha-256"}]}
10.5.5.RSE based DICE Protection Environment
TheDICEProtectionEnvironment(DPE)[8] service makes it possible toexecuteDICE commands within an isolated execution environment. It providesclients with an interface to send DICE commands, encoded as CBOR objects,that act on opaque context handles. TheDPE service performsDICEderivations and certification on its internal contexts, without exposing theDICE secrets (private keys and CDIs) outside of the isolated executionenvironment.
10.5.5.1.DPE API
Defined here:
include/lib/psa/dice_protection_environment.h
dpe_error_tdpe_derive_context(intcontext_handle,uint32_tcert_id,boolretain_parent_context,boolallow_new_context_to_derive,boolcreate_certificate,constDiceInputValues*dice_inputs,int32_ttarget_locality,boolreturn_certificate,boolallow_new_context_to_export,boolexport_cdi,int*new_context_handle,int*new_parent_context_handle,uint8_t*new_certificate_buf,size_tnew_certificate_buf_size,size_t*new_certificate_actual_size,uint8_t*exported_cdi_buf,size_texported_cdi_buf_size,size_t*exported_cdi_actual_size);
10.5.5.2.Build time config options
MEASURED_BOOT: Enable measured boot.DICE_PROTECTION_ENVIRONMENT: Boolean flag to specify the measured bootbackend whenRSE basedMEASURED_BOOTis enabled. The default value is0. When set to1then measurements and additional metadata collectedduring the measured boot process are sent to theDPE for storage andprocessing.DPE_ALG_ID: Determine the hash algorithm to measure the images. Thedefault value is sha-256.
10.5.5.3.Example certificate chain
plat/arm/board/tc/tc_dpe.h
10.5.6.RSE OTP Assets Management
RSE provides access for AP to assets in OTP, which include keys for imagesignature verification and non-volatile counters for anti-rollback protection.
10.5.6.1.Non-Volatile Counter API
AP/RSE interface for retrieving and incrementing non-volatile counters API isas follows.
Defined here:
include/lib/psa/rse_platform_api.h
psa_status_trse_platform_nv_counter_increment(uint32_tcounter_id)psa_status_trse_platform_nv_counter_read(uint32_tcounter_id,uint32_tsize,uint8_t*val)
Through this service, we can read/increment any of the 3 non-volatilecounters used on an Arm CCA platform:
Non-volatilecounterforCCAfirmware(BL2,BL31,RMM).Non-volatilecounterforsecurefirmware.Non-volatilecounterfornon-securefirmware.
10.5.6.2.Public Key API
AP/RSE interface for reading the ROTPK is as follows.
Defined here:
include/lib/psa/rse_platform_api.h
psa_status_trse_platform_key_read(enumrse_key_id_builtin_tkey,uint8_t*data,size_tdata_size,size_t*data_length)
Through this service, we can read any of the 3 ROTPKs used on anArm CCA platform:
ROTPKforCCAfirmware(BL2,BL31,RMM).ROTPKforsecurefirmware.ROTPKfornon-securefirmware.
10.5.6.3.Get entropy API
AP/RSE interface for reading the entropy is as follows.
Defined here:
include/lib/psa/rse_platform_api.h
psa_status_trse_platform_get_entropy(uint8_t*data,size_tdata_size)
Through this service, we can read an entropy generated from RSE.
10.5.7.References
[1]https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/index.html
[2]https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_comms.html
[3][4](1,2)[5]https://trustedfirmware-m.readthedocs.io/en/latest/platform/arm/rse/rse_key_management.html
[6][7]https://developer.arm.com/documentation/DEN0096/A_a/?lang=en
[8](1,2)Copyright (c) 2023-2024, Arm Limited. All rights reserved.Copyright (c) 2024, Linaro Limited. All rights reserved.Copyright (c) 2025, STMicroelectronics - All Rights Reserved