This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Encrypting/decrypting packets on-the-fly

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

  • 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

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

  • 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

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

  • 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

Related