ARM-software
Requirement for Key Attestation
Arm, is part of a Coalition of Content Provenance And Authenticity - C2PA Working group. C2PA establishes Content provenance standards to address the issue of Fake Media, Digital Abuse etc.
A requirement originating from C2PA is about "Secure Key Storage" for Claim Signing Key and Providing Proof about the Key Security, via means of Remote Attestation!
An Endpoint like a Smart Camera, or a Mobile Device, should be able to provide a Key Attestation Result (Verdict) to a Relying Party (example a Certification Authority) at the time of obtaining a Certificate, that the Signing Key :
-
Is Operating in a Secure Environment like HES
-
It is not exportable
PSA Platform is a fundamental platform on many IoT Endpoints, generating content.
As a result, in order to be compliant with the platform security requirement in C2PA, this issue tracks this requirement on PSA.
More details can be located at : https://confluence.arm.com/display/ATG/Content+Provenance+and+its+relevance+to+Arm (Note: private link)
The current Attestation specification for C2PA is here: https://c2pa.org/specifications/specifications/1.4/attestations/attestation.html.
This specifies the attestation of C2PA signing-keys, to also provided confidence in the platform and system in which the C2PA application is running when signing content manifests.
It seems, from reading the documentation, that the majority of systems that will be implementing C2PA are higher-end devices, which typically do not provide PSA Crypto and PSA Attestation APIs at the application level. For example, Android phones have the StrongBox key store, which already provides the necessary key attestation capabilities. It is not clear to me that microcontroller-based IoT systems will want to devote the power and footprint to implement C2PA on-device, rather than having a more powerful component in the IoT network provide that service for media generated by the network end points?
I would like to have a concrete use case/demand for systems that require this facility from the PSA root-of-trust services, in order to justify defining a PSA API for this.
My view is that even though the concept is at least 20 years old - there is not enough standardization in attestation formats for us to put this in the core API.
However, if you have a service - like content protection - that needs key attestation, then you can write a ARoT application that offers the service, and it can issue attestation on the keys it uses, in whichever format it wants to use. The ARoT service can also deal with the provisioning of the Attestation key and any required certificate chain.
You can then decide whether in any build, this is placed in the PRoT partition along with the PSA Crypto implementation, or in its own ARoT partition. Potentially with other services in different partitions - which may he different attestation formats and keys.
But - without specific user demand, I cannot see us allocating the resource to write this any time soon.
