As I understand it, those would be handled by the Realm Management firmware (since that still falls under the "CCA platform" heading as per SM1.0 Section 3.2), probably derived from the `Derivation root keys for Realm Management security domain` (SM1.0 section 5.2), which in turn is probably derived from the Monitor security domain root derivation key(s), which likely _are_ supplied by the RSS. The RSS is supplying that key(s) via the PSA crypto key export API, which is partially implemented on the RSS side but IIRC not currently supported by the Monitor firmware.
I wouldn't expect the realm binding keys to be handled via RSS directly for a variety of reasons, of which the most compelling is probably creating a security boundary between Realm code and the RSS (as required by R0008 SM1.0 Section 3.4).
Let me know if you have further questions, Raef
________________________________________ From: Peter Sawicki via TF-M tf-m@lists.trustedfirmware.org Sent: 08 March 2023 11:27 To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Sealing key - RSS
As far as ARM CCA is concerned, currently RSS supports only measured boot and delegated attestation (fetching DAK and CCA platform attestation token) interfaces. The Arm CCA Security Model 1.0 mentions that if a Realm wants to implement a persistent secure storage, the platform should deliver binding keys for local protection of persistent Realm assets.
Is there any ARM CCA specification that explains how this key should be derived? Are there any plans to implement such functionality in RSS?
Kind regards, Peter -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org