Hi everyone,

Thank you for all your suggestions! Roman.

From: David Hu David.Hu@arm.com Sent: Thursday, October 14, 2021 12:59 To: Mazurak Roman (CSUKR CSS ICW SW FW) Roman.Mazurak@infineon.com; fabian.schmidt@nxp.com; Shebu Varghese Kuriakose Shebu.VargheseKuriakose@arm.com; tf-m@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: [TF-M] Adding platform specific functions to Crypto Service.

Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safehttps://intranet-content.infineon.com/explore/aboutinfineon/rules/informationsecurity/ug/SocialEngineering/Pages/SocialEngineeringElements_en.aspx.

Hi Roman,

Sorry I’m unable to propose a comprehensive solution. Just a few comments from my very own point of view.

* As Crypto service is a fundamental PSA RoT service, I’d suggest to not hack the Crypto service. Adding irrelevant functions may increase the attack surface and then may bring in potential security risk. * It is more natural to implement the additional feature in a dedicated Secure Partition. If both the additional feature and Crypto service don’t need interrupts, mutex can be unnecessary, as Ken described in the another thread. * Besides the mutex, it shall also be taken care of the static data in accelerator drivers and registers content in accelerator HW. If the additional feature and Crypto service are located in different security domain, it can be critical to clean up those sensitive content when switching between them. If the additional feature can be implemented as a PSA RoT service, then they are in the same security domain and perhaps you can ignore the problem. * If you are concerned that the additional feature might block Crypto request handling, probably you can try to raise the priority of Crypto service to be higher than that of additional feature service.

Best regards, Hu Ziji

From: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com> Sent: Tuesday, October 12, 2021 7:15 PM To: fabian.schmidt@nxp.commailto:fabian.schmidt@nxp.com; Shebu Varghese Kuriakose <Shebu.VargheseKuriakose@arm.commailto:Shebu.VargheseKuriakose@arm.com>; David Hu <David.Hu@arm.commailto:David.Hu@arm.com>; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: RE: [TF-M] Adding platform specific functions to Crypto Service.

Hi Fabian,

Yes, our team is thinking about adding feature to the Crypto service API, which are not cryptographic in nature. This is one of the possible solution in our design to avoid additional data processing layer between cryptographic clients and crypto accelerator.

Our crypto accelerator also provides additional features which will be used by other secure partitions in TF-M but it doesn’t support handling of crypto and non-crypto requests at the same time.

It’s not a problem for CC312 which is used for crypto services and OTP in the latest commit. As far as I understand CC312 allows to use crypto operations and OTP related functions at the same time without additional synchronization. So, the reference design is not very helpful in our situation.

So, implementation of additional service is not the best solution. It will extend processing time for each cryptographic requests.

The other option is to implement synchronization by using mutex. I think mutex is preferable approach, but this feature is also not support by TF-M yet 😊 There is the discussion which I started for mutex : https://lists.trustedfirmware.org/pipermail/tf-m/2021-October/001914.html

Thanks, Roman.

From: Fabian Schmidt <fabian.schmidt@nxp.commailto:fabian.schmidt@nxp.com> Sent: Tuesday, October 12, 2021 13:47 To: Shebu.VargheseKuriakose@arm.commailto:Shebu.VargheseKuriakose@arm.com; David.Hu@arm.commailto:David.Hu@arm.com; Mazurak Roman (CSUKR CSS ICW SW FW) <Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com>; mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Cc: nd@arm.commailto:nd@arm.com Subject: RE: [TF-M] Adding platform specific functions to Crypto Service.

Hi Roman,

My understanding is that you would like to add features to the Crypto service API, but the features which you would like to add are not cryptographic in nature.

Have you considered creating your own service for those features, instead of modifying the Crypto service? Or is there anything makes this not a viable option?

If you are thinking about adding hardware acceleration for some Crypto features, that’s indeed covered in Shebu’s link.

Greetings, Fabian Schmidt

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: Dienstag, 12. Oktober 2021 11:46 To: David Hu <David.Hu@arm.commailto:David.Hu@arm.com>; Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org; mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: [EXT] Re: [TF-M] Adding platform specific functions to Crypto Service.

Caution: EXT Email Hi Roman,

I also might not have understood the question completely.

As you mention crypto HAL API, here is the specification which defines a standardized mechanism for PSA Crypto implementations to interface with Secure elements and crypto accelerators - https://github.com/ARMmbed/mbedtls/blob/development/docs/proposed/psa-driver...https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FARMmbed%2Fmbedtls%2Fblob%2Fdevelopment%2Fdocs%2Fproposed%2Fpsa-driver-interface.md&data=04%7C01%7Cfabian.schmidt%40nxp.com%7C17489158b6384ef5caa308d98d654ead%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637696288543072051%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=uKX4sUH37jNx1%2BvACuN8tBQl05OaXPPnMT9FqMwbhdU%3D&reserved=0

Also adding mbed-tls mailing list as the thread is crypto related..

Regards, Shebu

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, October 12, 2021 4:18 AM To: Roman.Mazurak@infineon.commailto:Roman.Mazurak@infineon.com; tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto:nd@arm.com> Subject: Re: [TF-M] Adding platform specific functions to Crypto Service.

Hi Roman,

Are you asking about adding platform specific HAL API to implement PSA Crypto API function? Please correct me if I misunderstand your question.

Best regards, Hu Ziji

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Roman Mazurak via TF-M Sent: Monday, October 11, 2021 9:45 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Adding platform specific functions to Crypto Service.

Hi all,

We would like to add a number of platform specific functions to Crypto Service API. Is it ok if such functions will not be related to cryptographic service, but such approach allows us to optimize platform design? Is there any initiative to create a Crypto Service HAL API to extend Crypto with custom functions?

Best regards, Roman.