nRF5340 CryptoCell-312 access for Network Processor

[BoscoJacinto]

Hi,

I am evaluating nRF5340 for using it in a smart lock product with high security. I had evaluated nRF52840 before this

and was impressed with the integration that the crypto apis have the cryptocell-310 for BLE related link layer security

like LESC in 4.2.

In 5340 I believe the cryptocell-312 resides only the application domain, which is mentioned in the link below

https://blog.nordicsemi.com/getconnected/why-does-the-nrf5340-have-two-cores

Although a reply to a comment mentions that the network processor has its own hardware for over the air encryption

is this the hardware AES block or is this some how connected to the cryptocell-312 through the AHB bus like shown below?

Also for LESC pairing where the stack needs to perform ECDH key exchange is this done in the cryptocell-312 or done via

software crypto backend?

In case the application need to do peer authorization, verification or nounce hashing etc using the cryptocell-312 ECDSA, SHA256

or any of the crptocell-312 algorithms can this code reside in the network processor and still use the cryptocell across the AHB bus?

This is so that the custom application handshake can reside close to the BLE stack (for e.g if OOB pairing needs the secret to be fetched

from the KMU). IPC between the two cores would make this possible I believe but its still an overhead in design and complexity.

What I envision is that all application validation and authorization, session keys etc be handled as a small and simple application in

the network processor with access to the cryptocell-312 and all business logic reside in the application processor.

So is the crypto hardware (CC312 ) backend apis available to the network processor via AHB?

[BoscoJacinto]

Hi Vidar,

Thanks once again for your support on this.

I will give this approach some more thought for a couple of days and will come back to you.

Regards,

Bosco Jacinto

[Vidar Berg]

Hi Bosco,

Happy to help. Yes, please do.

I hope you noticed my edit in my previous reply where I clarified that the MITM protection applies to the pairing procedure itself.

Regards,

Vidar

[BoscoJacinto]

Hi Vidar,

Yes, I saw your edit. Thanks for clarifying.

Regards,

Bosco Jacinto

[BoscoJacinto]

Hi Vidar,

I gave some thought on the possibility of using PSA framework and its API's to work with Trusted-Fimrware-M in the Secure Application Processor. One of the driving factors being access privileges across users of the lock and the custom handshake designed as one of the secure service.

I tried to research as much as possible but am stuck with a half answered queries

1. On nRF5340 If I dont use the Nordic SPM instead use Arm Trusted Firmware-M will it work across the core, will I be able to make calls from the network core (NSPE) to non-secure callable services in the application core (SPE) via OpenAMP, will nRF RPC work along with PSA Client/Server API's

2. I guess I will need the complete Zephyr BLE stack (Host + Controller) and the OS on the network core is this right?

3. Can the application core work without an OS or is Zephyr OS needed for TF-M + PSA framework?

Would appreciate your suggestions on the unknown unknowns in this directions as this is very new to me, Thanks.

Regards,

Bosco Jacinto

[Vidar Berg]

Hi Bosco,

1. It should not be a problem to use the nRF RPC to make calls to non-secure API on the application core. What type of PSA API's do you envision using on the net core in this case? 

2. I would recommend having the host on the application core as that is the architecture we currently support (link). I'm not sure I see any big advantage with having the full stack residing in the network core. Is the main motivation to get more separation between the application logic and BLE?

3. There is not technical reason for why you can't integrate TM-F with a bare metal application. Though I expect that it will increase your overall developments efforts as you will have to do more of the integration work yourself instead of benefiting from our ongoing work to integrate TF-M with the SDK. 

What's your thoughts around having the lock security features implemented at the application layer (administration of users, encryption, authentication,) and not rely on the security built into the BLE protocol?

Regards,

Vidar