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?

[Vidar Berg]

Hello,

The Bluetooth controller on the network core does not utilize the cc312 for link security, but the following dedicated crypto HW modules: CCM , RNG, and the AAR. Same as what the Softdevice uses on the nRF52 series.

ECDH  can be done with the cc312 (Nordic security module), but this peripheral is only directly accessible within the trust zone secure domain on the application core. The non-secure domain can use it, but it has to go through secure service calls into the secure domain. Like how PSA APIs are intended to be used with the Trusted Firwmare-M implementation. Also, I believe we are still using tinycrypt (SW) for the LESC pairing procedure in our current implementation.

I can see the motivation for wanting to separate the BLE part from the application core (nRF RPC may be used for controlling the BLE operation). But do you plan to have an additional layer of authentication above the protocol layer any? To me, it seems like it could be a good idea to have the lock mechanism implementation reside inside the secure domain on the application core. 

Best regards,

Vidar

 

[BoscoJacinto]

Hi Vidar,

Thanks for you thoughts and suggestions.

We wanted to do a custom handshake protocol to authenticate and validate a peer before it could attempt pairing with our lock. Since the peer is just an intermediary between the lock and our server, its authentication and validation is important. And since the peer is not part of the root of trust initially, this handshake is a three way handshake between the lock, mobile (peer) and server with auth and validation from both server and lock point of view.  Its basically a challenge response protocol and we wanted to do this in an open BLE service that the lock exposes. The OOB secret obtained in the process would then be used to pair the peer with the lock using B:E 4.2 LESC.

CryptoCell-310 of nRf52840 was considered earlier which would do all key/secret storage in a sandbox'd way via key indexes with all CC310 crypto modules (ECDH, ECDSA, HMAC, HKDF) using this index in the secure RAM/Flash. But we found the strong need of a KMU in a SoC which 52840 doesnt have. Hence 5340.

Your right that the custom authentication layer be implemented in the secure domain which was possible according to me in 52840 with the SoftDevice just needing the OOB in a secure way. The nRF SDK 17.2 with its peer manager and crypto front end was studied for the feasibility of this.

So for 5340 I need to implement this handshake along with its associated BLE service in the application core and would have to pass BLE events, peer events/data via nRF RPC if I could use the SoftDevice in the network core, but his would soon make it very complex considering the request/response state machines/waittime/timeouts etc. I wanted a more programmatic API style interfacing for this critical handshake.

Also I see that the primary preferred BLE stack for 5340 is the Zephyr OS which is ported to the application core (correct me if am wrong), if this is the case can I do all this with the Zephyr OS in the application core avoiding the overheads of RPC style architecture?

[Vidar Berg]

Hi,

Thanks for the additional details. Maybe you have considered this already, but I'm not sure if you will be able support the OOB pairing approach you outlined if the central is an Android or iOS device. Particularly iOS is known for giving the user little control over the pairing procedure (is handled internally in corebluetooth framework). Maybe an alternative could be to secure the link with LESC just works first, then once the link is encrypted, initiate the custom handshaking procedure to authenticate the user in your application? This way you don't have to rely on specific BLE implementation behaviors on the central side.

BoscoJacinto said:

Also I see that the primary preferred BLE stack for 5340 is the Zephyr OS which is ported to the application core (correct me if am wrong), if this is the case can I do all this with the Zephyr OS in the application core avoiding the overheads of RPC style architecture?

Yes, as you can see here (link), this is the architecture we currently support. That is, Zephyr BT host running on the application core, and the Softdevice/Zephyr controller running on the network core. Communication between the cores (sending of HCI commands) is done through the OpenAMP library. This architecture offloads most of the timing critical protocol procedures onto the network core. 

[BoscoJacinto]

Hi Vidar,

Thanks for your extended feedback on this. If i go with LESC just works pairing (i.e w/o MITM protection) and then do the custom handshake and arrive at an Out of Band secret from the server I will eventually have to so an ECDH/ECDSA to generate a shared key (w/o sending the OOB over the LESC link), at this moment can I have the BLE stack switch to using this shared key for link layer encryption?  If not then then the link layer is still prone to MITM attacks even though I have another layer of encryption right? Also if i can switch link layer keys this would can two encryption cycles for sending data right?

Does the OpenAMP library use the shared cache between the two cores?

[Vidar Berg]

Hi,

Ideally I think you should try to find a way to decouple authentication from the BLE, or at least not rely on the link layer as the only source of authentication. The reason for this is the limited control you have over the BLE implementation on the mobile phone. It's for instance not possible to directly access and update the encryption key on the phone.

The CPU caches are not shared between the cores. OpenAMP uses the IPC and shared memory for the inter-core communication.

BoscoJacinto said:

If not then then the link layer is still prone to MITM attacks even though I have another layer of encryption right?

 Yes, it will be prone to MITM attacks during the pairing procedure.

As a side note, we have an early implementation of a doorlock sample for the Connected Home over IP project as described in this blog post here: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/connected-home-over-ip-sneak-peek-of-early-development-on-nrf52840. I have not evaluated this implementation myself, so not sure how relevant it is, but it might give some ideas on how to handle authentication at the application layer.

Edit: The device will be vulnerable against MITM attacks during BLE Just works pairing, but not on subsequent connections when the link is secured with stored keys. In the application, maybe you can mark the bonding for a particular peer device as valid after it has been authenticated by your handshake procedure. And if it's not validated, erase the bonding information.