Security vulnerability issues

[sean]

Hi，

Background Information:

1. Our product, BLE near-infrared device, is undergoing CRA (Cyber Resilience Act) compliance assessment—specifically for the EU RED Cybersecurity Standard.

2. OpenCVE is a platform providing CVE data, focusing on security vulnerabilities across vendors and products.

   • Relevant link: 

     https://app.opencve.io/cve/?vendor=nordicsemi

     

Question:
Regarding the following two vulnerabilities, have they been resolved? If yes, is there supporting evidence?

1. CVE-2021-29415

   The elliptic curve cryptography (ECC) hardware accelerator, part of the ARM TrustZone CryptoCell 310, contained in the Nordic Semiconductor nRF52840 through 2021-03-29 has a non-constant time ECDSA implementation. This allows an adversary to recover the private ECC key used during an ECDSA operation.

2. CVE-2020-27211

   Nordic Semiconductor nRF52840 devices through 2020-10-19 have improper protection against physical side channels. The flash read-out protection (APPROTECT) can be bypassed by injecting a fault during the boot phase.

[Einar Thorsrud]

Hi,

Regarding CVE-2021-29415, this is not fixed in the nRF52840 HW.  However, the risk is limited as this is mostly a theoretical attack, which may not be practical outside of a lab environment:

• No other code can execute on the device at the same time.
• Nordic acknowledges the weakness documented in CVE-2021-29415 about the Arm CryptoCell310 IP.
• The nRF52840 was designed back in 2015 and physical attacks were not part of the threat model for the device.

Regardign CVE-2020-27211, this has been fixed in revision 3 of the nRF52840. See IN141 Informational Notice v1.1.

Best regards,

Einar

[Emil Lenngren]

Regarding the first issue, I was pretty sure that issue was purely due to bad software and not the hardware itself? Note that the software feeds the hw a sequence of modular multiplications to perform, depending on the bits of the private key. The hw executes every individual modular multiplication in constant time, but the issue was that the software enqueues a different number of modular multiplications depending on the bit pattern of the private key. By changing the high level algorithm to one that always schedules the same number of modular multiplications, the result is that you get a constant time implementation, which resolves the issue, right?