Encrypting/decrypting packets on-the-fly

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Fri, 11 Feb 2022 13:34:07 GMT

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).

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Fri, 11 Feb 2022 09:12:18 GMT

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

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Fri, 11 Feb 2022 08:29:59 GMT

Hi Eugene,

[quote user="Hiihtaja"]It is not so clear if after decryption on fly, if original encrypted frame is also stored in scratchpad or any other memory area. [/quote]

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.

[quote user="Hiihtaja"]What about encryption on fly ? Does encrypted packet stored in some place after it transferred to air ?[/quote]

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

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Fri, 11 Feb 2022 07:48:14 GMT

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

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Thu, 10 Feb 2022 13:31:22 GMT

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.

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Thu, 10 Feb 2022 12:48:20 GMT

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

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Thu, 10 Feb 2022 12:36:40 GMT

Hi Eugene,

The length is not encrypted (I included that conceptually as part of he header, so I was not clear enough). You will see this clearly from figure 2, though:

You can see how the RADIO must be configured in the CCM documentation under the section AES CCM and RADIO concurrent operation.

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Thu, 10 Feb 2022 12:30:16 GMT

Hi Einar !

If I see packet structure in PS 6.20.1 Packet configuration

LENGTH is located after S0 and going to be encrypted as well.

How other side is able to know what amount of bytes need to be received if byte is encrypted ?

Or it somehow decrypt first block and immediately know what is amount of bytes are expected ?

In our case

#define NRF_LFLEN_BITS (8)

#define NRF_S0LEN (1)

#define NRF_S1LEN_BITS (0)

#define NRF_CILEN_BITS (2)

#define NRF_STATLEN (0)

as result length of the packet in the position where the LENGTH field in the packet.

In case if TX operation, MAXLEN can be set to 250 and LENGTH is set to exact value what need to be send.

In case of RX, MAXLEN is set to 64 or to 250 for limit MAX size of received packet.

So I can change MAXLEN and LENGTH only if I would like to limit RX/TX transfers.

Is this radio configuration is fully compatible with on-fly encryption ( MIC space available for sure )

Or using on fly encryption nees some specific radio configuration ?

Regards,

Eugene

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Thu, 10 Feb 2022 08:29:26 GMT

Hi Eugene,

[quote user="Hiihtaja"]

Do I understand right and AES-128-CCM scheme is only add 4 byte MAC (MIC) at the end of packet ?

It is no any other overhead and to user available 255-4=251 byte payload.

[/quote]

The 4 byte MIC follows immediately after, there is no other overhead.

[quote user="Hiihtaja"]Can packet contains some non-encrypted header or tail ? Or entire packet are encrypted ?[/quote]

The entire packet except the header is encrypted. See Figure 2 in the CCM chapter.

[quote user="Hiihtaja"]Bit 0: Direction bit Bit 7 – Bit 1: Zero padded[/quote]

This s byte 24 in the CCM data structure. The point here is that Bit 0 can be 1 or 0 depending on direction, and the other 7 bits shall always be 0.

Einar

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Wed, 09 Feb 2022 19:13:34 GMT

Hi Einar !

Do I understand right and AES-128-CCM scheme is only add 4 byte MAC (MIC) at the end of packet ?

It is no any other overhead and to user available 255-4=251 byte payload.

Can packet contains some non-encrypted header or tail ? Or entire packet are encrypted ?

Key and other IV information should be specified in 6.4.7 CCM data structure and must be equal on RX and TX side ( in some instant moment , one time e.g nonce) ?

But what means "

24	Bit 0: Direction bit Bit 7 – Bit 1: Zero padded

" ?

Regards,

Eugene

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Tue, 01 Feb 2022 13:16:10 GMT

Hi Eugene,

There are no other references in official code that I am aware of. You may be able to find some old threads on DevZone or open source third party projects that could be useful though, but I have no particular in mind. Update: nrf-esb-ccm-example is a simpler example demonstrating this.

We do not have performance numbers for CryptoCell. However, you can run crypto examples from the SDKs with different configurations to compare CryptoCell with other software backends.

Einar

RE: Encrypting/decrypting packets on-the-fly

Hiihtaja — Tue, 01 Feb 2022 13:10:23 GMT

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

RE: Encrypting/decrypting packets on-the-fly

Einar Thorsrud — Tue, 01 Feb 2022 12:29:59 GMT

Hi Eugene,

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

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.

[quote user=""]2. What about examples for usage of CryptoCell 310 in similar way ? I mean transparently wit some shortcuts from radio to it ?[/quote]

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.