nRF9160 - Using ECC accelerator from user application?

[Achim Kraus]

I want to use a nRF9160 to send data over UDP/NB-IoT.

For encryption I want to use eclipse/tinydtls in order to have support for RFC7250 and (upcoming) RFC9146. That works with software ecc (so far). However the software ecc-functions takes a couple of seconds (more or less expected). Therefore, I would like to try to use the ecc-hw-accelerator.

As far as i understand 1.6 Secure vs. nonsecure ,

"However, this feature is more critical when building applications for the nRF9160, since cellular IoT applications has to be build as non-secure in order to communicate with the modem."

it seems to be not possible to access the ecc-hw from such an cellular IoT application, because that must be on non-secure and there the hw-ecc is not available (right?).

It is somehow hard to understand, why cellular IoT applications has to be build as non-secure. Is there a more detailed explanation about that as "in order to communicate with the modem"?

I read also, that maybe mbedtls could use the ecc-hw for crypto functions. But it leaves it unclear to me, if this is then also limited to the "secure mode" and so also not usable in a iot-application itself.

[Einar Thorsrud]

Hi,

It is not possible to communicate with the modem from secure mode, so implementing the application (at least the parts of it that communicate with the modem) is a hard requirement. This cannot be changed. Also, as you noted, the CryptoCell (crypto accelerator) can only be used from secure mode. There has been support for using the RNG from CryptoCell from SPM, but support for other features including ECC is not implemented there. For that, you should look at TF-M, which is intended to replace SPM and also provide extended functionality. TF-M is currently experimental, but is the only solution Nordic provide for this. You can see how it is used by referring to the Crypto examples. If you build for non-secure, TF-M is automatically included.

[Achim Kraus]

Thanks.

I will try these crypto examples.

[Achim Kraus]

I tried "ncs-1.8.0/nrf/samples/crypto/ecdh". I get a build failure:

Building 'zephyr/zephyr_prebuilt.elf' from solution 'build' in configuration 'Common'
2> Compiling 'empty_file.c'
1> Linking 'zephyr_prebuilt.elf'
1> /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.bfd: modules/nrfxlib/nrfxlib/nrf_security/src/libmbedcrypto.a(bignum.c.obj): in function `mbedtls_mpi_read_binary_le':
1> /home/achim/repos/ncs-1.8.0/mbedtls/library/bignum.c:845: multiple definition of `mbedtls_mpi_read_binary_le'; modules/nrfxlib/nrfxlib/nrf_security/src/libmbedcrypto.a(ecp_oberon.c.obj):/home/achim/repos/ncs-1.8.0/nrfxlib/nrf_security/src/mbedtls/oberon/ecp_oberon.c:91: first defined here
1> /opt/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.bfd: modules/nrfxlib/nrfxlib/nrf_security/src/libmbedcrypto.a(bignum.c.obj): in function `mbedtls_mpi_write_binary_le':
1> /home/achim/repos/ncs-1.8.0/mbedtls/library/bignum.c:920: multiple definition of `mbedtls_mpi_write_binary_le'; modules/nrfxlib/nrfxlib/nrf_security/src/libmbedcrypto.a(ecp_oberon.c.obj):/home/achim/repos/ncs-1.8.0/nrfxlib/nrf_security/src/mbedtls/oberon/ecp_oberon.c:124: first defined here
1> collect2: error: ld returned 1 exit status
Build failed

Any ideas?

[Achim Kraus]

I also tried the tfm_hello_world.

That even doesn't pass the configuration ...

Merged configuration 'ncs-1.8.0/nrf/samples/tfm/tfm_hello_world/child_image/mcuboot.conf'
-- Configuring incomplete, errors occurred!
-- Configuring incomplete, errors occurred!
See also "ncs-1.8.0/nrf/samples/tfm/tfm_hello_world/build_thingy91_nrf9160_ns/CMakeFiles/CMakeOutput.log".
See also "ncs-1.8.0/nrf/samples/tfm/tfm_hello_world/build_thingy91_nrf9160_ns/CMakeFiles/CMakeError.log".
Including boilerplate (Zephyr base): /ncs-1.8.0/zephyr/cmake/app/boilerplate.cmake
thingy91_nrf9160_ns.dts.pre.tmp:367.32-371.5: Warning (simple_bus_reg): /soc/cryptocell-sw: missing or empty reg/ranges property
thingy91_nrf9160_ns.dts.pre.tmp:60.42-72.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@40000000/flash-controller@39000: duplicate unit-address (also used in node /soc/peripheral@40000000/kmu@39000)
thingy91_nrf9160_ns.dts.pre.tmp:312.19-318.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@40000000/clock@5000: duplicate unit-address (also used in node /soc/peripheral@40000000/power@5000)
Changed board to secure thingy91_nrf9160 (NOT NS)

=== child image mcuboot -  begin ===
Including boilerplate (Zephyr base): ncs-1.8.0/zephyr/cmake/app/boilerplate.cmake
thingy91_nrf9160.dts.pre.tmp:60.42-72.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/flash-controller@39000: duplicate unit-address (also used in node /soc/peripheral@50000000/kmu@39000)
thingy91_nrf9160.dts.pre.tmp:312.19-318.3: Warning (unique_unit_address_if_enabled): /soc/peripheral@50000000/clock@5000: duplicate unit-address (also used in node /soc/peripheral@50000000/power@5000)

ncs-1.8.0/nrf/samples/tfm/tfm_hello_world/child_image/mcuboot.conf:2: warning: attempt to assign the value '"UART_1"' to the undefined symbol UART_CONSOLE_ON_DEV_NAME

error: Aborting due to Kconfig warnings

[Einar Thorsrud]

Hi,

I am not able to reproduce this. Both nrf/samples/crypto/ecdh and nrf/samples/tfm/tfm_hello_world from 1.8 should build as expected with "west build -b nrf9160dk_nrf9160_ns --pristine".

Can you ensure that you have not done any changes in the nRF Connect SDK files, and also that you use the 1.8 toolchain from the toolchain manager?

[Achim Kraus]

Sorry, my browser (Firefox) sometimes doesn't show the reply. And sometimes it appears then suddenly (No, I don't have too much trouble with other sides ;-) ).