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.org Sent: Thursday, June 17, 2021 11:23 PM To: David Hu David.Hu@arm.com Cc: tf-m@lists.trustedfirmware.org; nd 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