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

[Einar Thorsrud]

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

[Hiihtaja]

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

[Einar Thorsrud]

Hi Eugene,

Hiihtaja said:

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.

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

Hiihtaja said:

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

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

Hiihtaja said:

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

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

[Hiihtaja]

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

[Einar Thorsrud]

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.

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