Hi,

This secure test service, as I mentioned in the previous email, is for test purpose only. I’d like to recommend to implement a dedicated secure service to co-work with TF-M Initial Attestation service, to fulfil the specific use cases. This test service can be an example.

The factory NS app and the dedicated secure service may work in a special device lifecycle. It may require additional mechanism to protect it from accesses in improper lifecycle. It may not be reasonable to mix an API with special purpose with TF-M Initial Attestation service following PSA Attestation API.

Best regards, Hu Ziji

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Tamas Ban via TF-M Sent: Friday, June 18, 2021 3:05 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

Hi,

The API is not fully disappeared, it still supported by a secure test service which can be optionally enabled at build time: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/10226/ https://review.trustedfirmware.org/c/TF-M/tf-m-tests/+/10228

I think in this way a factory version of TF-M still can be used to export the public key, create a certificate for it (factory NS app) and pass on securely to the verification party to register the database.

Kevin: Would this solution still satisfy your use case in mind?

My thoughts regarding having the API part of the TF-M secure runtime (original solution): - I expect its usage is limited. Only at the beginning of device lifetime.

* Removal of the API can reduce code size. * I cannot see how the API can be abused. Its usage can be clarified in the documentation.

BR, Tamas

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: 2021. június 18., péntek 7:18 To: Kevin Townsend (kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org) <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

Hi Kevin,

In a simplified common attestation protocol, the attestation verifier/validation entity (VE) uses the attestation public key to verify the attestation token sent from the device. The attestation VE is unable to verify the token, if it is not provided with the public key in advance. The public key fetched in device runtime is untrustworthy. Please check the details in Initial Attestation section in PSA Platform Security Model spec.

On the other hand, usually clients on device don’t need attestation public key during attestation protocol execution. It is unnecessary to let Initial Attestation service to export IAK public key to other clients. Putting a dedicated API in attestation service to export public key can confuse developers.

Sorry I’m not familiar with other use cases in which the attestation public key might be required and fetched on device in runtime. Those, if exist, may not be the typical use cases of TF-M Initial Attestation service. I’d suggest to implement dedicated secure services, to fulfill your requirement and use cases, relying on TF-M Initial Attestation. It is more flexible and convenient than mixing the public key fetch with TF-M Initial Attestation service.

Best regards, Hu Ziji

From: Kevin Townsend <kevin.townsend@linaro.orgmailto:kevin.townsend@linaro.org> Sent: Thursday, June 17, 2021 11:23 PM To: David Hu <David.Hu@arm.commailto:David.Hu@arm.com> Cc: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] TF-M API tfm_initial_attest_get_public_key() has been removed

Hi,

On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org> wrote: Hi all,

Please note that API tfm_initial_attest_get_public_key() has been removed from TF-M Initial Attestation service.

tfm_initial_attest_get_public_key() was defined by TF-M to retrieve Initial Attestation Key (IAK) public key in runtime. It is not defined by PSA Attestation API spec. It was designed for test purpose only but was always enabled in Initial Attestation service.

TF-M regression tests called tfm_initial_attest_get_public_key() in runtime to retrieve IAK public key to verify the Initial Attestation Token (IAK) generated by Initial Attestation service. However, such a test implementation doesn’t fully align with common attestation protocols, in which the public key is usually distributed to the verifier when the device is deployed or registered. This API can be misleading and it concerned developers that it may be abused in actual production.

Can you detail the use case(s) where you feel deriving the public key inside TF-M or the NS firmware can be abused?

Personally, I find it quite useful to be able to generate the IAK randomly and retrieve the public key, which can safely be provided to the NS application to be passed on the end users.

Providing the IAK public-key during factory provisioning assumes a very specific workflow that I don't think every TF-M product is likely to adopt.

There are many other instances where we don't scrupulously follow the PSA APIs, so I'm not sure why this example should be highlighted, and what seems like a useful feature to me removed.

If you can help me better understand the security concerns here, though, I can of course be persuaded otherwise!

Best regards, Kevin