Bluetooth Mesh CCM Hardware Acceleration

[AJGherardi]

Is your feature request related to a problem? Please describe.
Bluetooth mesh uses CCM heavily for encryption which is current done in software while using zephyr. Bluetooth mesh networks can have 1000's of nodes leading to a very large amount of messages needing to be decoded. Doing CCM in hardware when possible can improve efficiency, latency, and throughput.

Describe the solution you'd like
Create a driver for Nordic Semiconductors CCM hardware using their HAL. Consume this CCM driver in subsys/bluetooth/host/aes_ccm.c

[trond-snekvik]

Hi, unfortunately, Nordic's HW CCM module is not able to support the Bluetooth Mesh packet format, as it's made specifically for the Bluetooth LE encryption scheme. In particular, the length field, the flags field and the additional data field is not configurable.

It would be possible to use the cryptocell for this on some Nordic chips, but we haven't benchmarked it or looked into the architecture changes needed for this yet.

[AJGherardi]

That is unfortunate does the cryptocell have a driver for zephyr because I have not seen any.

[trond-snekvik]

It does not, at least not at the moment. You'd have to use Nordic's nRF Connect SDK redistribution for it.

[alxelax]

Isn't this case for integration Trusted Firmware-M that supports Nordic's cryptocell?

[AJGherardi]

TF-M is a separate execution environment it would require that part of the Zephyr code base would be built into a different image, signed, (and the most problematic bit) loaded onto the Arm TEE. What happens if the user needs to load their own image onto the TEE.

I think it would be a case for integration only if it protected the keys. Bluetooth mesh does take measures to help stop the trash can attack but they can still be read right off the device with some effort. Keep the keys in TF-M and only allow them to be used from within TF-M.