Hi Raef,

Thank you for your quick response. Our reason for lagging behind from the latest PSA based architecture is partly due to our internal backward compatibility and dependency on MCU vendor code that provides hardware acceleration interface with the legacy ALT approach with MbedTLS. I’ll internally discuss the course of action based on your input first.

Masaki

From: Raef Coles Raef.Coles@arm.com Sent: Friday, October 31, 2025 4:46 AM To: tf-m@lists.trustedfirmware.org; Sato, Masaki Masaki.Sato@garmin.com Subject: Re: Question on pka_ec_wrst_smul_scap.c in CryptoCell3xx Runtime

Hey Masaki, thanks for the bug report, this is indeed the right place. The cryptocell 312 runtime driver isn't actively maintained any more - we inherited it from another team, and it's an extremely complex (and in places, obtuse) bit of code.

Hey Masaki, thanks for the bug report, this is indeed the right place.

The cryptocell 312 runtime driver isn't actively maintained any more - we inherited it from another team, and it's an extremely complex (and in places, obtuse) bit of code.

We've run it through our standard crypto regression tests and the PSA crypto api tests, and fixed any issues which that brought to light, but as you say the SCA weierstrass support isn't compiled by default so wouldn't have been tested in this way. We found similar issues to this when doing this initial testing.

We are currently recommanding that anyone using the cryptocell 300-series transitions to our newer `cc3xx` driver, which is actively developed and maintained. It is missing a few features that the older driver has, but side-channel protected weierstrass ECDSA is well-supported and fully tested.

If you can't transition to the newer driver, we'd be interested to know why so we can try and resolve those issues. If resolving them isn't possible, we'd be happy to review and merge a PR which fixed these issues and added an option to compile the SCA protected weierstrass support.

Raef

________________________________________

From: Sato, Masaki via TF-M <tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org>

Sent: 30 October 2025 20:23

To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org

Subject: [TF-M] Question on pka_ec_wrst_smul_scap.c in CryptoCell3xx Runtime

Hi TFM Developer Forum Organizer,

I'm currently integrating the CryptoCell3xx Runtime code for ECDSA hardware acceleration and have a question regarding the implementation.

I'm not entirely sure if this is the right list to post to — perhaps it belongs in mbed-tls or psa-crypto instead — so please forgive me and suggest the right list if this is not the appropriate forum.

I noticed that the repository contains two variants of pka_ec_wrst_smul: one under no_scap and another under scap, located in

/lib/ext/cryptocell-312-runtime/codesafe/src/crypto_api/pki/ec_wrst/.

From the filenames and comments, it appears that scap.c is the Side-Channel Attack (SCA)–resistant version, and would therefore be preferred for end-user products where stronger security is prioritized over performance.

However, in the current version of pka_ec_wrst_smul_scap.c from the main open-source branch, I found a couple of apparent typos/bugs that cause compilation errors:

Line 239: should probably be

PkaAddJcbJcb2Mdf(EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS, EC_SIGN_REG_TS,

EC_SIGN_REG_XS, EC_SIGN_REG_YS, EC_SIGN_REG_ZS,

EC_SIGN_REG_X2, EC_SIGN_REG_T2, EC_SIGN_REG_Z2);

(currently missing the leading “P”.)

Lines 389 and 391: the output parameters are declared as const, which seems incorrect. For example:

CCError_t PkaEcWrstScalarMult(const CCEcpkiDomain_t *pDomain, /*!< [in] Pointer to EC domain. */

const uint32_t *scalar, /*!< [in] Pointer to the scalar buffer. */

uint32_t scalSizeInWords, /*!< [in] Size of the scalar in 32-bit words. */

uint32_t *inPointX, /*!< [in] Pointer to input point X coordinate. */

const uint32_t *inPointY, /*!< [in] Pointer to input point Y coordinate. */

const uint32_t *outPointX, /*!< [out] Pointer to output point X coordinate. */

The const qualifier on the output parameters seems unintended and rather for inPointX.

Because of these issues, it seems this file might not have been recently reviewed or tested.

So, my questions are:

1. Is the CryptoCell312 Runtime actively maintained and tested in a specific branch where these typos/bugs are already fixed? If so, could you please share which branch that is?

2. If not, it seems that CMake currently only selects the no_scap variant. Does this mean the scap variant is not actively maintained or tested, and therefore not recommended for production use due to higher risk?

Thanks in advance for your help and clarification.

Best regards,

Masaki Sato

(P.S. I have sent this message from proofpoint TFM list by “Start a new thread” button. However, I don’t see a record on the “posting activity” under my account profile nor active discussion list. Pardon me, but I’m a newbie to this forum, so please forgive me to send the same message by email.

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.

________________________________

CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.