• State Verified Answer
  • Replies 3 replies
  • Subscribers 86 subscribers
  • Views 2467 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 262378
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ECDSA signing crashes when implemented with bluetooth

sethu

Hello, 

I have been trying to implement the tinycrypt ECDSA algorithm for our product. I had sampled the implementation in a sample project with ECDSA being the only implementation and everything works perfectly. But, after I tried implementing ECDSA within a Bluetooth application, the signing and verification fails (it causes the system to just crash without any indication of what went wrong). I have attached a sample project I used for your reference, it is the central_hr example with the implementation added, the program called the ecdsa_Sign function when the device received a notification from a peripheral device, at this point the function crashes the whole system. One thing to note is that if the function is called from main itself, it works without any problem. I have been trying to figure out the problem using print statement and came to the conclusion that it crashes in the EccPoint_mult function in ecc.c file, to be more specific, it crashes in the first for loop in that function. The sample crashes even when the project is implemented in peripheral mode. Hope you guys will be able to help me with this as I have already spent a fair amount of time trying to figure it out without much luck. I'm using nRF Connect SDK v1.4.0 with the latest nRF connect command-line tool.

Regards, 

Sethu.

 2500.central_hr_help.zip

Parents
  • +1

    Forget my last comment, that assert triggered because I stopped the program using a breakpoint, before continuing.

    However, I was able to get rid of the memfault by setting these in prj.conf:

    CONFIG_BT_TINYCRYPT_ECC=n
CONFIG_BT_RX_STACK_SIZE=4096

    The top config was enabled by default, and would cause zephyr\subsys\bluetooth\host\hci_ecc.c-->ecc_thread()--> emulate_le_p256_public_key_cmd() to run, and a stack overrflow-->memfault would happen.

    When I disabled it, I still got a memfault, which I think is due to stack overflow because the rx stack was too small. As you can see in the call stack below, the functions notify_func()-->ecdsa_sign() are called within the rx thread(), and the call stack is quite large:

    One quick fix is to simply increase the BT RX stack size. A better solution is probably to create an own thread that runs ecdsa_sign() and just use k_sem_take/k_sem_give to signal the thread.

    Best regards,

    Simon

Reply
  • +1

    Forget my last comment, that assert triggered because I stopped the program using a breakpoint, before continuing.

    However, I was able to get rid of the memfault by setting these in prj.conf:

    CONFIG_BT_TINYCRYPT_ECC=n
CONFIG_BT_RX_STACK_SIZE=4096

    The top config was enabled by default, and would cause zephyr\subsys\bluetooth\host\hci_ecc.c-->ecc_thread()--> emulate_le_p256_public_key_cmd() to run, and a stack overrflow-->memfault would happen.

    When I disabled it, I still got a memfault, which I think is due to stack overflow because the rx stack was too small. As you can see in the call stack below, the functions notify_func()-->ecdsa_sign() are called within the rx thread(), and the call stack is quite large:

    One quick fix is to simply increase the BT RX stack size. A better solution is probably to create an own thread that runs ecdsa_sign() and just use k_sem_take/k_sem_give to signal the thread.

    Best regards,

    Simon

Children
Related
Terms of service