Hi,

On Thu, 17 Jun 2021 at 16:49, David Hu via TF-M <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