Encrypting/decrypting packets on-the-fly

[Hiihtaja]

Hello !

1. Do you have examples for nRF52840 what is demonstrate encryption/decryption packets on the fly as it explained in PS chapter 6.4 ?

2. What about examples for usage of CryptoCell 310 in similar way ? I mean transparently wit some shortcuts from radio to it ?

   It might need if other than default cryptography in use.

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

1. Do you have examples for nRF52840 what is demonstrate encryption/decryption packets on the fly as it explained in PS chapter 6.4 ?

The CCM peripheral is used to encrypt packets on the fly in for instance Bluetooth. This is part of the stack implementations. The SoftDevice stack (used in the nRF5 SDK) and the SoftDevice controller (link layer) used in the nRF Connect SDK are closed source so you cannot refer to those, but you can see how this is used in the Zephyr LL by looking at zephyr\subsys\bluetooth\controller\ll_sw\nordic\hal\nrf5\radio\radio.c.

2. What about examples for usage of CryptoCell 310 in similar way ? I mean transparently wit some shortcuts from radio to it ?

No, there is no HW support for using CryptoCell on the fly together with the radio. You will need to first receive the data in a RAM buffer, then use CPU to start the crypto operation.

[Hiihtaja]

Hi Einar !

I think in SoftDevice you have everything ( Endeverything work fine !) but I need to implement something like this for proprietary radio and according to PS it does not look so simple. If you have some other references always welcome !

2. Do you have any performance digits for CryptoCell ? Just for understand how long similar crypto operation can take ?.

 Maybe it so long time and in this case, encrypt/decrypt can be done as pre/post-operation even in a tight loop.

Regards,

Eugene

[Hiihtaja]

Hi Einar !

Thank you !

I close and close to start coding this topic.

But about what direction this bit "Bit 0: Direction bit" in CCM structure are responsible ?

I can see encrypt/decrypt are specified in own register or it should be set here as well or this is some other meaning ?

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

The direction bit comes from the Bluetooth specification (which the CCM peripheral is specially designed for):

The directionBit shall be set to 1 for Data Channel PDUs sent by the master and set to 0 for Data Channel PDUs sent by the slave.

[Hiihtaja]

Hi Einar !

It is not so clear if after decryption on fly, if original encrypted frame is also stored in scratchpad or any other memory area. Does it available at some location ? It can be used for debug purposed and may be need to be wiped for minimize risks.

What about encryption on fly ? Does encrypted packet stored in some place after it transferred to air ?

Regards,

Eugene

[Einar Thorsrud]

Hi Eugene,

Hiihtaja said:

It is not so clear if after decryption on fly, if original encrypted frame is also stored in scratchpad or any other memory area.

It is available in the OUTPTR location, but no where else. The CCM peripheral does not use RAM for context memory or similar, so there is no other parts of the RAM that holds any data.

Hiihtaja said:

What about encryption on fly ? Does encrypted packet stored in some place after it transferred to air ?

It is also stored in the memory pointed to by OUTPTR.

[Hiihtaja]

Hi Einar !

What about MODE.DATARATE register values. Are all of them are specified ?

Co-processor should perform AES-CCM faster than radio and may be this asynchronous value is not specified.

Looks like co-processor can be used synchronously with Nordic's proprietary and Bluetooth® low energy modes only.

But no any way to attach it to IEEE 802.15.4 radio, at list in some partial way to use it on fly ?

Regards,

Eugene

[Einar Thorsrud]

The CCM peripheral is designed specifically for use with BLE, and only supports data rates relevant for that. So for the nRF52840 you have 1Mbps, 2Mbps, 125 kbps and 500 kbps. No other data rates are possible (so no 250 kbps for 802.15.4).