SPC58EC CRYPTO SW Crypto Libs for ECC signature, sign verify

[jschoi0126]

I am currently developing with SPC5STUDIO and want to verify a signed message using ECDSA.

To do this, I am studying the example in ecc.h.

When I ran the example code:

retval = ECCinitEC(&ECparams, &mb);
retval = ECCinitPoint(&G, &ECparams, &mb);
retval = ECCsetPointGenerator(G, &ECparams);
retval = ECCinitPoint(&PubKey, &ECparams, &mb);
retval = ECCinitPrivKey(&privkey, &ECparams, &mb);
retval = ECCsetPrivKeyValue(privkey, ecc_160_privkey, sizeof(ecc_160_privkey));

These functions executed without any issues, and I confirmed that the keys and parameters were correctly set in each variable.

However, when I call the function retval = ECCscalarMul(G, privkey, PubKey, &ECparams, &mb);, the system stops working and crashes.

If you have any insights or comments on this issue, I would greatly appreciate it.

Thank you.

best regrds.

[Erwan YVIN]

Hello ,

i recommend to check the PC, R14, R13 with your debugger

Maybe it is a stack pointer overflow 

     Best regards

                 Erwan

[jschoi0126]

Thank you for your response. Are PC, R13, and R14 referring to core registers? If so, what are these registers specifically, and what should I be checking in each of them? If it turns out that stack pointer overflow is indeed the issue, how can I resolve the problem? Thank you.

[jschoi0126]

I already set the __process_stack_size__ = 40960; for stack memory.

Then what can I do to solve this problem?

[Erwan YVIN]

Yes ,

PC Program Counter Contains the address of the next instruction to be executed.

R13 Stack Pointer Points to the top of the stack, managing function parameters and local data.

R14 Link Register Holds the return address for functions or subroutines.

You can determine the exact location  of your crash with PC and R14

          Best Regards

                     Erwan

[jschoi0126]

Thank you very much for your response. Following your advice, I used a debugger tool to check the R13, R14, and PC registers. The strange thing is that even though function calls are continuously made, the value of the R13 register remains fixed at "0x400B0198" and the value of the R14 register is fixed at "0x00000000," without any change. Additionally, this picture is a core register capture taken when a system crash occurred. What should I analyze in this situation? And if this is indeed a stack buffer overflow, what methods can be used to resolve it?

[jschoi0126]

If it turns out to be a stack memory overflow, would it be necessary to replace the current chip, which is the SPC58EC80E1, with a different one? Could you recommend any alternative chips?

[Erwan YVIN]

Hello ,

R14 is the link to your RAM 

you can branch into the LR .. you should arrive in the part of the code where the crash happened 

                Best regards

                              Erwan

[jschoi0126]

Thank you for your response. I have identified the exact point in the code where the crash occurs. The crash happens when the code at address "0x00FC7902" within the "MontyJacProjAddPoints" function is executed. At that moment, I have captured the core register values, which are attached in the photo.

Based on this information, can you analyze the cause of the crash? Is it possible that this is due to a stack overflow? This is a critical issue, and a thorough analysis is necessary. Thank you for your assistance.

[jschoi0126]

Based on my analysis, it seems that data should be loaded from the memory space at R27 + 0xC, but since R27 contains "0x00000008" it results in accessing an invalid memory location, causing a crash. I suspect that this issue might be due to a stack overflow. Is this correct? Additionally, if it is indeed a stack overflow and we can no longer increase the stack space, what should we do?

Thank you.