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.

[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