Hello Cedric and Michael,

Thank you for the question, and interest in key attestation APIs. The short answer is:

1. We do not have plans to introduce a key attestation API at the moment
2. We would like to properly understand your use cases, so that we can review our plans in this area, and possibly decide that it is time to progress this
3. In the short term, you should consider implementing platform-specific APIs for this kind of service

This is an API area that has been discussed several times within Arm, and there are some particular challenges when trying to define a standard API.

# Format

As with the Initial Attestation, the output of a key attestation is a signed token or ‘certificate of origin’. To be useful to a third party that wants answers to the questions “is this the right kind of key?”, and “do I trust that it has not been compromised?”, the token/certificate has to be provided to the verification service, and so the verifier needs to understand the format of the token. It is possible to wrap the token within an additional attestation protocol, or embed other data within the token via the auth_challenge, but not rewrite the token into a different format that is understood by the verifier.

As a result, a standard PSA API will either need to use a standard format:

• We aren’t aware of a standard format at the moment. Some applications/ecosystems use X509v3 with proprietary extensions for key properties/policies – but X509 is problematic for use within the RoT of small embedded systems.
• Create a new standard or work with others on an emerging one, as we did with IAT and the IETF Entity Attestation Token.
• Define another proprietary format for PSA and hope that the verification services will implement verifiers.

Or the API will have to provide the option of different output formats. It is hard to imagine that small systems will want to support more than one format, so this still requires alignment of the attestation implementation in the device with the ecosystem (verifiers), to ensure that there is a common token format.

# Certificate authority/chain of trust

For simple systems with a single physical key store, there is probably just one key attestation key, so a simple API is fine. If the system has more than one location for storing keys, for example a Secure Element as well as a secure key store in NVM for keys that are not managed by the SE, then how is the request mapped to an attestation key? – in some use cases, the 3^rd party might require that the key is inside the SE and that this is proved by an attestation from within the SE – a claim from the PSA Crypto implementation outside of the SE that the key is inside the SE is not equivalent. Does it use the key location, or is this being implementation-defined acceptable?

How are the attestation keys authorized? – via an attestation by the device attestation key, or one by the key-store-device manufacturer (e.g. the SE vendor for keys attested by the SE), or some other certificate authority?

A standard API might not need to specify this completely, but it requires making some decisions and documenting clearly how to use and build this service.

# Time/scope of attestation service

Some key attestation services must be requested at the time of key generation. Some can attest any key that was previously generated within the key store, and others can verify any key that is within the key store (and provide information in the report regarding the key provenance – which enables determining whether the key is a secret within keystore). Does attestation only apply to some key types?

# Where does the API belong

A key attestation service needs privileged access to the key store – it needs information about a key that the current PSA Crypto API does not provide, and it needs access to a key attestation key that is not accessible to any other PSA Crypto client. If attestation of keys within an SE must be provided by the SE itself, then the key attestation API needs special access to the SE as well.

However, key attestation is not a fundamental Platform RoT service – compromise of this service does not necessarily compromise the device PRoT.

As a result, there is a trade-off between different security risks and architectural principles when deciding if this should be an extension of the PSA Crypto API or a separate RoT service.

# Use cases

At our last review we only had a single concrete use case, which at the time was best served via specific APIs in that application and framework.

It is possible that you (Cedric and Michael, and perhaps others) have additional use cases that would help to understand how to make some of the decisions relating to this API. It would be helpful for us if you could provide more details on those use cases.

Kind regards,

Andrew Thoelke

From: psa-crypto <psa-crypto-bounces@lists.trustedfirmware.org> On Behalf Of Cedric Neveux via psa-crypto
Sent: 21 October 2021 14:59
To: psa-crypto@lists.trustedfirmware.org
Subject: [psa-crypto] PSA Key Attestation APIs

Hello,

Working on a Secure SW architecture requiring to support key attestation, I would like to know if there is a plan to add APIs to do Asymmetric key attestation in the same manner there are API to attest a token?

We would like to propose the following APIs:

Calculate the size of a Key Attestation buffer.

psa_status_t psa_attest_key_get_size(psa_key_id_t key,

        size_t auth_challenge_size,

        size_t *cert_size)

Retrieve the Key Attestation buffer.

psa_status_t psa_attest_key(psa_key_id_t key,

        const uint8_t *auth_challenge,

        size_t auth_challenge_size,

        uint8_t *cert_buf,

        size_t cert_buf_size,

        size_t *cert_size)

Concerning the certificate buffer, we are thinking about a TLV format containing metadata + public key buffer + signature but in order to standardize these APIs like the PSA initial attestation token, we are open to any advice.

Do you think that adding it in the Attestation API standard is possible or do we have to add it as custom API?

Thanks and Regards,

Cedric Neveux