• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 167 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288989
Options

Help implementing ECDSA Verify using TinyCrypt

user116076

Hello,

I am developing FW for a BLE Peripheral on NRF52840_DK using nRF Connect SDK v1.9.1 on VScode.

So far, Peripheral and Client are able to connect and exhange data.

When Client is sending a data with a digital signature (raw 65 bytes) and its public key (raw, 65 bytes), In the Peripheral Code,

I am trying to verify that digital signature using TinyCrypt library

result = uECC_verify(&public_key[1], Hash, HASH_SHA256_BYTES_LEN, digital_signature, uECC_secp256r1());
But on running while performing this function, application crashes with this message : 

0[00:00:12.548,278] <dbg> service.read_characteristic: Attribute read, handle: 0, conn: 0x200017f8
[00:00:12.639,862] <dbg> service.write_characteristic: Attribute write, handle: 0, conn: 0x200017f8
[00:00:20.614,257] <err> mpsl_init: MPSL ASSERT: 112, 2165
[00:00:20.614,257] <err> os: ***** HARD FAULT *****
[00:00:20.614,257] <err> os: Fault escalation (see below)
[00:00:20.614,257] <err> os: ARCH_EXCEPT with reason 3

[00:00:20.614,288] <err> os: r0/a1: 0x00000003 r1/a2: 0x00000003 r2/a3: 0x00000002
[00:00:20.614,288] <err> os: r3/a4: 0x200015d0 r12/ip: 0x4000b000 r14/lr: 0x00013467
[00:00:20.614,288] <err> os: xpsr: 0x41000018
[00:00:20.614,288] <err> os: Faulting instruction address (r15/pc): 0x0001cb1e
[00:00:20.614,288] <err> os: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
[00:00:20.614,318] <err> os: Fault during interrupt handling

[00:00:20.614,318] <err> os: Current thread: 0x20001d90 (main)
[00:00:22.092,163] <err> fatal_error: Resetting system

Any help in fixing this ?

Parents
  • 0

    Hi,

    You are getting the same MPSL assert as in this thread. As you see this, I assume you are calling uECC_verify() from an interrupt or a high priority thread? If so, this can cause problems just like this, as the MPSL has strict timing requirements. What you typically want to do is to ensure that you do this with low priority, so that time critical tasks are not delayed because of the time consuming crypto operations.

Reply
  • 0

    Hi,

    You are getting the same MPSL assert as in this thread. As you see this, I assume you are calling uECC_verify() from an interrupt or a high priority thread? If so, this can cause problems just like this, as the MPSL has strict timing requirements. What you typically want to do is to ensure that you do this with low priority, so that time critical tasks are not delayed because of the time consuming crypto operations.

Children
Related
Terms of service