Access crypto_core (ECC) from PSoC Creator

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
TiDo_3898341
Level 2
Level 2
10 sign-ins 5 replies posted 5 questions asked

I am working on a PSoC Creator and Keil MDK project that accesses the crypto block via the client-server model.  I would like to use the ECC functions that are available via direct crypto_core API, but I do not see any cy_crypto_core headers in the PDL 1.3.2 installed by PSoC Creator.  I see that they are available in the Modus Toolbox.  I thought possibly I could compile crypto library source code in Keil project, but am missing the cy_device.h.  So, what is the best approach?  Should I build crypto_core library for my device in Modus Toolbox, and then use in PSoC Creator/Keil project?

0 Likes
1 Solution

Thanks, I included Cy_PDL_Init(CY_DEVICE_CFG) in the library I exported from MTB, to initialize the cy_device structure. The functions I have tested (AES, SHA, and HMAC) all seem to be working correctly on the real device.  ECDSA is working correctly, but it does not seem to be much faster than the software-only ecc-micro code I had been using.  Is that to be expected on CY8C6247FTI-D52?

View solution in original post

0 Likes
7 Replies
TiDo_3898341
Level 2
Level 2
10 sign-ins 5 replies posted 5 questions asked

To answer my own question, I am able to access the cy_crypto_core functions in a PSoC Creator-based Keil project by compiling the cy_crypto_core_* sources in Modus Toolbox.  I have not done extensive testing yet, but it seems to work.

I was also able to compile the cy_crypto_core_* sources in PSoC Creator with PDL 3.1.2.  However, I couldn't use this approach because our project is based on PDL 3.0.x, which does not have the cy_device.h which the crypto_core compile needs.

0 Likes

Although, the crypto driver may work correctly inside MTB or PSoC Creator PDLs, the driver has some critical dependencies to cy_device.* files because it uses hardware abstraction layer macros and definitions from cy_device. We haven't tested the driver for this particular use case so I cannot guarantee the working.

I have passed the query to the internal software team to make the Crypto Core APIs available as part of the PSoC Creator PDL releases. Thank you for your interest in Cypress Products.


Regards,

Dheeraj

0 Likes

Thanks, I included Cy_PDL_Init(CY_DEVICE_CFG) in the library I exported from MTB, to initialize the cy_device structure. The functions I have tested (AES, SHA, and HMAC) all seem to be working correctly on the real device.  ECDSA is working correctly, but it does not seem to be much faster than the software-only ecc-micro code I had been using.  Is that to be expected on CY8C6247FTI-D52?

0 Likes

Can you please give more details on why you believe it is slower?

Also, please answer these questions so that we can get more insights into your issue:

  • What execution time was measured?
  • What was the curve selected?
  • What was the message digest used?

Looking forward to your reply.

Regards,

Dheeraj

0 Likes

Thanks for following up.  My time measurement was based on a watchdog counter:

Cy_MCWDT_GetCount(MCWDT_STRUCT1,CY_MCWDT_COUNTER2)

that I believe is running at 32768 Hz.  About 6200 ticks elapsed doing the crypto_core signature on the CY8C6247FTI-D52, compared to ~6300 using software only (based on GitHub - kmackay/micro-ecc: ECDH and ECDSA for 8-bit, 32-bit, and 64-bit processors.).  Is that a valid way to compare execution times?  Or, more to the point, is it a rough measure of power consumption?

The code whose time I computed was:

const cy_stc_crypto_ecc_key private_key = {

  .type = PK_PRIVATE,

  .curveID = CY_CRYPTO_ECC_ECP_SECP256R1,

  .k = (void *)privateBytes

};

Cy_Crypto_Core_Hmac(CRYPTO, hmac, msg, 32, privateBytes, 32, CY_CRYPTO_MODE_SHA256);

Cy_Crypto_Core_ECC_SignHash(CRYPTO, msg, 32, sig, private_key, hmac);

Separately, I measured ticks elapses for SHA, HMAC, and AES (1 block).  All of these completed in just a few ticks, so it seems like my interface to Crypto HW is generally working.  Cy_Crypto_Core_ECC_VerifyHash() indicated the signature was correct.

I wonder if part of the Crypto HW needed by ECC does not get enabled because this is built on PDL 3.0.4.  Maybe there is a software fallback path, which would explain why times are so similar.  We are generally using crypto server running on CM0+, but I disabled that for these crypto_core tests.

0 Likes

Could you please provide your measurement Creator project archived with the modified PDL?

Regards,
Dheeraj

0 Likes

Thanks for following up.  These tests were embedded in a larger project that will be difficult to isolate, and I don't want to use any more of your time for this unsupported configuration.

FWIW, I'm not sure it is right to say I modified the PDL.  All I did was create a Modus project where I wrapped the cy_core_crypto_ interfaces in my own function calls, and then exported a static library.  I then included that library in a Keil project, built on a PDL 3.0.1 Pack exported from Creator.  Really, I was surprised that it worked at all!  I am not sure if a proper configuration would lead to different performance results.  Looking at the ECC source code, there is still a lot happening on the main processor, a lot of calls to VU to implement the ECC algorithms.

0 Likes