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
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
Hi,
I asked around within ARM and the general consensus is that the CCA SM is out-of-data from this feature point of view. An update of the SM is ongoing,
Answer from Gareth Stockwell: " A Realm may need access to keys in order to support use cases such as: - Persist data over Realm restart on the same platform instance. - Persist data over Realm migration to a different platform instance. - Share data between Realms with the same owner, or within the same owner-defined security domain.
Derivation of such a key must be performed by a component which is isolated from the guest OS, but in which the Realm owner can establish trust. The RMM satisfies both of those properties; however, an alternative approach is to introduce additional isolation boundaries within a Realm. This would allow key derivation to be performed by a component (such as a vTPM) which is packaged and deployed together with the guest OS. Arm is investigating additional RMM features which would support this approach, and is also working on updating the CCA-SM in this area among others. "
BR, Tamas
-----Original Message----- From: Raef Coles via TF-M tf-m@lists.trustedfirmware.org Sent: Wednesday, March 8, 2023 3:31 PM To: tf-m@lists.trustedfirmware.org; Peter Sawicki algorytmy.almanach@gmail.com Subject: [TF-M] Re: Sealing key - RSS
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 -- TF-M mailing list -- tf-m@lists.trustedfirmware.org To unsubscribe send an email to tf-m-leave@lists.trustedfirmware.org
Hi,
I have one more question. Do you know when the new version of CCA Security Model is going to be released?
Kind regards, Peter Sawicki
tf-m@lists.trustedfirmware.org
-
Peter Sawicki -
Raef Coles -
Tamas Ban