NRF52840 Cryptocell EC signature verify getting stuck in a loop

[Barry]

Using a NRF52840 running zephyr and mcuboot, the function nrf_cc310_bl_ecdsa_verify_secp256r1() is getting stuck in a loop.

I am using NRFXLIB v1.1.0

Looking at the disassembly window in my IDE

PkaEcdsaVerify is getting tuck in a loop and never returning.  

The loop assembly consists of the following

F8D83000    ldr.w r3, [r8, #0]

    931C        str r3, [sp, #0x70]

    9B1C        ldr r3, [sp, #0x70]

    07DB        lsls r3, r3, #31

    D5F9        bpl 0x000104E4

When i first get to these s lines of assembly,

r3 is 0x5002b080

r8 is 0x5002b0b4 (the value at #0 here is zero, so r3 becomes zero after the first line and never changes again.)

Any thoughts?

[Einar Thorsrud]

Hi,

I do think we have seen this issue before. One thought is that we do not know exactly what happens in the HW if the public key is invalid. Can you try to validate it and see if that could be the issue? Alternatively, could you provide us with the signature, hash and public key so that I can test on my side (it is typically not secret information, but you can open a private case for it if you do not want to share it publically).

[Barry]

I think these are my values

Signature
B4 D8 E8 F8 8B FA E9 88 C6 CE 06 B6 3C 62 30 39 E4 30 82 5F 8C D4 A5 2B D4 46 BD 2C 9C DA E1 F0 30 25 27 0A EA 6A 1A 5D F1 D0 60 F1 10 CF 4E CC 79 56 DD 09 3C C2 E7 85 8D 2E E7 CE 69 35 A3 9C

Hash
E5 26 87 64 4F D7 58 BD F4 F1 0E 2F C5 63 35 1C C4 6D 75 CF 91 62 49 EF BC 1C C0 18 66 CE 61 0A

Public key
2A CB 40 3C E8 FE ED 5B A4 49 95 A1 A9 1D AE E8 DB BE 19 37 CD 14 FB 2F 24 57 37 E5 95 39 88 D9 94 B9 D6 5A EB D7 CD D5 30 8A D6 FE 48 B2 4A 6A 81 0E E5 F0 7D 8B 68 34 CC 3A 6A FC 53 8E FA C1

Same data without spaces

Signature
B4D8E8F88BFAE988C6CE06B63C623039E430825F8CD4A52BD446BD2C9CDAE1F03025270AEA6A1A5DF1D060F110CF4ECC7956DD093CC2E7858D2EE7CE6935A39C

Hash
E52687644FD758BDF4F10E2FC563351CC46D75CF916249EFBC1CC01866CE610A

Public key
2ACB403CE8FEED5BA44995A1A91DAEE8DBBE1937CD14FB2F245737E5953988D994B9D65AEBD7CDD5308AD6FE48B24A6A810EE5F07D8B6834CC3A6AFC538EFAC1

Edit 1: I originally posted the wrong thing for the Public key but it was amended 3:21 PM eastern time 1/7/20202

[Einar Thorsrud]

Hi,

The public key is valid, and in fact, this runs correctly with nrf_cc310_bl in SDK 16.0.0. So it seems there may be an MCUboot/B0 configuration issue or bug, but I am not sure what is going on. We need to look a bit more into it.

[Barry]

What is B0?

I guess it could be a configuration issue. I am trying to do crypto operations beyond the the nrf_cc310_bl module in my bootloader. So I am enabling the nrf_cc310_platform and nrf_cc310_mbedcrypto libraries also. So maybe it is an initialization issue. 

I do see at the nrf_cc310_bl_init() function declaration it says "Running this initialization is intended for cases where there is no direct requirement for the RNG subsystem". But I have enabled entropy and the cc310 platform, so hw_cc310 is also in the build. It does do several initialization functions including 

nrf_cc310_platform_abort_init()

nrf_cc310_platform_mutex_init()

nrf_cc310_platform_init()

So maybe these initialization are messing with the nrf_cc310_bl_init() function.

If that is the case. Then what are my options? I guess I could just skip including the nrf_cc310_bl libary, since the things it can do can all be done in the nrf_cc310_mbedcrypto library. I need to do some AES operations in my bootloader, so I need the full crypto capabilities in the bootloader.

[Barry]

Never mind. I tried removing CONFIG_HW_CC310=y and CONFIG_ENTROPY_GENERATOR=y, and I still had the same issue. So even without those platform initializations I am still getting stuck in the same loop.

I noticed that MCUboot was passing a location is flash for the public key as opposed to a ram location. I thought that might be an issue. But I changed the implementation to copy the public key to RAM before providing it to the verify function. That did not impact the behavior either. Regardless of it not fixing this issue, is that something that should be done? If so I will recommend it to MCUboot.

So I am stuck as to what could be wrong. 

MCUboot makes the following function call

nrf_cc310_bl_ecdsa_verify_secp256r1(&ctx,
(nrf_cc310_bl_ecc_public_key_secp256r1_t *) public_key,
(nrf_cc310_bl_ecc_signature_secp256r1_t *) signature,
hash,
hash_len);

Where pblic_key, signature, and has have the values I provided before.

hash_len is 32.

ctx is decalred with nrf_cc310_bl_ecdsa_verify_context_secp256r1_t ctx;

Before the verify function is called the following things are done by MCUboot:

NRF_CRYPTOCELL->ENABLE=1;

nrf_cc310_bl_init();

NRF_CRYPTOCELL->ENABLE=0;

NRF_CRYPTOCELL->ENABLE=1;

does this make sense as an implementation?

[Barry]

I was able to get the signature checking to work by using 

mbedtls_ecdsa_verify()

instead of 

nrf_cc310_bl_ecdsa_verify_secp256r1()

Of course, using mbedtls_ecdsa_verify() took a whole lot of extra work to be able to transform the signature, and public key into the correct formats. It also increased the size of the bootloader significantly by requiring me to include a number of extra MBEDTLS code to do the setup and transformations necessary to get the inputs to this function.  And it forced me to hack some MCUboot code I would have rather left un-hacked up.

So I would still appreciate some resolution if possible, but I have a work around worst case scenario.

[Einar Thorsrud]

Hi,

I am glad you found a workaround. The R&D team is working on improving the crypto support in nRF Connect SDK, and they are aware of this specific issue, but I cannot say when we will have a better solution.

That said, I am a bit puzzled that how you import the signature and public key mattered since they are valid. Just a shot in the dark, but could it be that you just had the wrong endianness? Could you try to swap the endianness and see? (If so, remember to swap the two halfs of the public key separately).