AES security

[PAk-CatchFire]

Hello again. I am extending my programs on this chips and I would like to add security. I would like to know if Hardware AES-128bit Accelerator is implemented, since Murata states that CMWX1ZZABZ-078 comes with it. Regards

[GrumpyOldPizza]

Yes, hardware AES-128 is used for LoRaWAN.

[PAk-CatchFire]

Thank you. Could it be used to provide encryption to a Lora point to point link? Where could I find some code of it?

[GrumpyOldPizza]

Are you suggesting to add some AES128 encryption the FskRadio/LoRaRadio class, similar to what SX1231 does in hardware ?

[PAk-CatchFire]

Yes, supposedly the Murata chip has support for AES-128 on hardware.

https://www.murata.com/en-eu/support/faqs/products/lpwa/lora/hardware/0003

[GrumpyOldPizza]

CMWX1ZZABZ has a STM32L082 build in, which has hardware AES-128.

The support for that is hardcoded for LoRaWAN. So again my question, do you envision this support being part of the FskRadio/LoRaRadio class (similar to the way SX1231 does that in hardware), or somehow else.

The somehow else is a problem, because Arduino locking issues.

If that should be integrated into FskRadio/LoRaRadio, I need to understand from you how the API should look like, and what the semantics are.

[PAk-CatchFire]

What do you mean by Arduino locking issues?

Can't be the hardware AES-128 used for secure communications on Lora links? I just want to encrypt/decrypt some messages to have a private channel (yes, using LoRaRadio).

[GrumpyOldPizza]

LoRaWAN / AES128 (and FskRadio/LoRaRadio) are implemented as layered drivers at the ISR level. You cannot use AES128 from your "loop()" code, because you cannot lock out LoRaWAN.

So all I can do is add some APIs perhaps to FskRadio/LoRaRadio that make use of AES128 at the interrupt level, which would avoid any need for locking.

Mind looking at the SX1231 datasheet what is available there in terms of AES. Perhaps this is good enough ... I could add code to FskRadio/LoRaRadio that mimics the concept of SX1231 if that is what's required.

Otherwise, I'd recommend using software AES.

[PAk-CatchFire]

Thank you again @GrumpyOldPizza I have read the SX1231 datasheeet and found that:

The AES encryption/decryption cannot be used on the fly i.e. while transmitting and receiving data. Thus when AES
encryption/decryption is enabled, the FIFO acts as a simple buffer. This buffer is filled before initiating any transmission.
The data in the buffer is then encrypted before the transmission can begin. On the receive side the decryption is initiated
only once the complete packet has been received in the buffer.
The encryption/decryption process takes approximately 7.0 us per 16-byte block. Thus for a maximum of 4 blocks (i.e. 64
bytes) it can take up to 28 us for completing the cryptographic operations.
The receive side sees the AES decryption time as a sequential delay before the PayloadReady interrupt is available.
The Tx side sees the AES encryption time as a sequential delay in the startup of the Tx chain, thus the startup time of the
Tx will increase according to the length of data.
In Fixed length mode the Message part of the payload that can be encrypted/decrypted can be 64 bytes long. If the
address filtering is enabled, the length of the payload should be at max 65 bytes in this case.
In Variable length mode the Max message size that can be encrypted/decrypted is also 64 bytes when address filtering is
disabled, else it is 48 bytes. Thus, including length byte, the length of the payload is max 65 or 50 bytes (the latter when
address filtering is enabled).
If the address filtering is expected then AddressFiltering must be enabled on the transmitter side as well to prevent address
byte to be encrypted.

That API at interrupt level would be fine, I see it easily at RX but, how would you call it at TX? Because the datasheet states that the FIFO must be filled with the AES encrypted data before starting any transmission.

Would you also implement address filtering?

Regards

[PAk-CatchFire]

Hi, I wonder if you had the time to check on this issue. Regards

[GrumpyOldPizza]

Sorry, I do not have time to work on this. IMHO it would be nice to add this, but you can just as well use software AES and do this at the application layer.

[PAk-CatchFire]

Thank you for your answer. Can I make a last question? How do you cypher your messages? I am concerned since STM32L0 ins't a very powerful chip. Regards

[GrumpyOldPizza]

STM32L0 is plenty powerful to do AES128 in software.

[PAk-CatchFire]

Thank you again!!!