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?

[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

[BoscoJacinto]

Hi Vidar,

1. For the authentication of central device (mobile app) I plan to create a secure partition (eg. Auth Service in SPE) it would use the built in Crypto Service provided by the PSA framework (in SPE). The Auth Service API's would be exposed to the BLE Pairing Service (GATT) in the BLE Host.

2. The main motivation is to keep the BLE Pairing Service (LESC pairing without MITM protection) code separate from the business logic using NSPE and SPE boundary with Secure Partition, this is to avoid any flash/ram access to business logic code/keys/logs etc.

3. Yes would go for Zephyr OS on the application core as well.

The original goal was to use BLE LESC with MITM protection i.e OOB (NFC, PIN pairing are not in line with the business use case as far as usability is concerned) and rely on BLE link layer security. And User access control could have been done by role type based access to one/two/three BLE Services. But with no MITM protection this doesn't service the purpose.

Currently we have B2B sales, additionally we might have a B2C sales program. In this case whitehat/blackhat hackers are a potential threat agent so wanted root of trust in design.

Am not sure If you have come across this template
https://armkeil.blob.core.windows.net/developer/Files/pdf/white-paper/smart-door-lock-application-guide.pdf

Its a pretty good read.

Regards,

Bosco Jacinto

[Vidar Berg]

Hi Bosco,

Thanks for the link to the app note, it's definetly something I will take a look at. I'm a bit suprised I have seen before when I have searched for PSA materials earlier.

Regards,

Vidar

[BoscoJacinto]

Hi Vidar,

After some amount of study we are inclined on using PSA with TF-M to have Trusted execution.

My team's and my understandings on these things are daily increasing, the architecture of the lock firmware is accordingly being conceived at this stage. We have a lot to cover and there are a still a many open questions, I will post them in separate threads on this forum.

For now its appropirate to close this thread, thanks so much for your help.

Regards,

Bosco Jacinto