Cy_Crypto_Disable( ) seemingly not turning off crypto HW

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

cross mob
BrVa_4472456
Level 2
Level 2
10 replies posted 5 replies posted 5 questions asked

I'm trying to run a low power application that goes into deep sleep when idle, and whenever I enable the crypto HW and then disable before entering deep sleep the current draw when in deep sleep is significantly higher (~1mA) than if I just skip the Cy_Crypto_Enable/Cy_Crypto_Disable operation all together. For this simple experiment, I am  just doing an enable and then disable during initialization before allowing the system to go into deep sleep. I'm fairly confident that the crypto server operations are completing before going into deep sleep. I'm just wondering if I'm missing anything (disabling clocks, etc) that would actually power down the crypto block to achieve the power consumption I'm expecting?

0 Likes
1 Solution

Having the crypto client and server on the same core is not a good practice, unless you use something like arm trustzone, with which you are able to create separate memory spaces. It is very likely that in your approach the (supposedly secret) encryption credentials share at some moment in time the memory space of your application, which means that a malicious program (running in the same application space) just can steal them...

Therefore you should follow the example to put client and server on different cores, which have separate memory spaces) to ensure a separation between a secure environment (CM0) and a application environment (CM4).

My guess is that the crypto API just assumes that people would use the CM0 as secure core, (at least that would confirm your observations).

If you are serious about security (and you should be), you should follow the separate core approach. Yes I do realize it will cost you a bit more power, to have that other core (temporarily) running as well.

Not doing so will probably result in a system that you think is secure, but actually isn’t.

View solution in original post

0 Likes
6 Replies
SampathS_11
Moderator
Moderator
Moderator
250 sign-ins 250 solutions authored 5 questions asked

Since the crypto server operations finish before entering deep sleep, can you kindly try by stop the crypto server by means of Cy_Crypto_Server_Stop(), and check if the current drops down to acceptable levels?

0 Likes

Thanks for the quick reply! Tried calling Cy_Crypto_Server_Stop( ) and didn't seem to have any effect on the consumption =/

0 Likes

Is it possible it's only getting to sleep instead of deep sleep? I think (?) what it's pulling is around what that state is expected to pull (~1.6mA)...

0 Likes

When you call the API Cy_Crypto_Disable, it returns cy_en_crypto_status_t​ that you can use to check if disabling the Crypto H/W was successful or not i.e it should return CY_CRYPTO_SUCCESS.

Please refer to this application note to understand more on the PSoC6 Power Modes: https://www.cypress.com/file/385936/download

It has a couple of Code Examples listed in the Appendix that you can refer to, to understand where your application might be going wrong and what the right way is to go into DeepSleep. Feel free to attach your project if you want us to have a look at it, happy to help

Regards,

Dheeraj

0 Likes

Yeah, I'm seeing CY_CRYPTO_SUCCESS. For further reference, I'm running my application with the crypto client and server on the M4 (with the M0+ just in deep sleep). And one interesting finding is that when I enable the crypto, the CM0_STATUS register in CPUSS go from 0'b11 --> 0'b00 (deep sleep to active mode). I'm thinking that is where the current draw is actually coming from and was curious if this sounds right and how that could happen?

I'm currently working with a cmake style project, so I can work to get what I have built in PSoC creator and will attach the project shortly. Thanks!

-Bryan

0 Likes

Having the crypto client and server on the same core is not a good practice, unless you use something like arm trustzone, with which you are able to create separate memory spaces. It is very likely that in your approach the (supposedly secret) encryption credentials share at some moment in time the memory space of your application, which means that a malicious program (running in the same application space) just can steal them...

Therefore you should follow the example to put client and server on different cores, which have separate memory spaces) to ensure a separation between a secure environment (CM0) and a application environment (CM4).

My guess is that the crypto API just assumes that people would use the CM0 as secure core, (at least that would confirm your observations).

If you are serious about security (and you should be), you should follow the separate core approach. Yes I do realize it will cost you a bit more power, to have that other core (temporarily) running as well.

Not doing so will probably result in a system that you think is secure, but actually isn’t.

0 Likes