LoRa Basics Modem and LoRa Edge documentation

Cryptographic Engine


The Cryptographic Engine provides a dedicated hardware accelerator for AES-128 based algorithm computations and dedicated RAM and flash memory to handle sensitive parameters such as encryption keys, with no read access possible.

The Cryptographic Engine offers several features:

  • Improved power efficiency, thanks to its hardware accelerator

  • Reduced memory footprint, thanks to its comprehensive APIs

  • Improved security, thanks to its dedicated flash and RAM combination

  • Simplified LoRaWAN® standard implementation, thanks to primitives that are directly applicable on LoRaWAN messages


LoRa Edge™ LR1110 transceiver

Step-by-Step Procedure

Context Management

The cryptographic context describes the set of data that can be saved in flash by the Cryptographic Engine (keys and parameters).

To make sure all data are ready to use, the best practice is to restore the cryptographic context after a power-on or when leaving sleep mode without retention.

  1. If necessary, restore the cryptographic context. This will load context from flash to RAM, via the CryptoRestoreFromFlash() command.

  2. Implement your application-related actions (e.g., Encrypt data, Compute AES-CMAC, etc.).

  3. Save the cryptographic context if it was modified. This will save the context from RAM to flash, via the CryptoStoreToFlash() command.

Set and Use a Key

  1. Restore the cryptographic context.

  2. Set a key with CryptoSetKey().

  3. Save the cryptographic context. This can be done any time before going into sleep mode without retention or before resetting the chip.

  4. Perform a cryptographic operation (e.g., CryptoAesEncrypt()) with the correct Key ID.


Not all keys can be set by the user.

Set and Use a Parameter

  1. Restore the cryptographic context.

  2. Set a parameter with CryptoSetParam().

  3. Save the cryptographic context. This can be done anytime before going into sleep mode without retention, or before resetting the chip.

  4. When needed, the parameter can be read with CryptoGetParam().

In-depth Behavior

Cryptographic Operations

The Cryptographic Engine implements an AES-128 encryption as defined in FIPS PUB 197 and ISO/IEC 18033-3.

Memory Management

The Cryptographic Engine has its own RAM and flash memory area.

The dedicated RAM is split into three address spaces:

  • A protected (write only) address space to store keys

  • A protected (read / write) address space used by the cryptographic core

  • An unprotected address space to store device parameters (such as EUIs)

The dedicated flash is under direct access of the cryptographic engine. (There is no direct access from the CPU.) It is used to store both protected and unprotected RAM address spaces. The purpose of this dedicated flash memory area is to enable the circuit to restore its state from low power modes.

To reduce the power consumption and optimize the processing time, all operations are performed in RAM. A context is saved in flash memory upon user request.

The RAM of the Cryptographic Engine is preserved when the chip goes into sleep mode with retention.

Key Management

The keys are arranged into several groups, according to the functionality they serve.

This arrangement determines:

  • Which cryptographic functions can be used with a group.

  • Which other group(s) of keys a Key ID can be derived from.


The Cryptographic Engine offers several useful functions in a LoRaWAN context:

  • CryptoProcessJoinAccept(): decrypts and verifies the MIC of a join accept message. Decrypted data are returned only if the verification succeeds.

  • CryptoAesEncrypt01(): encrypts data with an AES-128 algorithm (the first data byte is forced to 0x01, see §4.3.3 LoRaWAN specification 1.0.3).

  • CryptoDeriveKey(): can be used to derive AppSKey and NwkSKey.

  • CryptoComputeAesCmac(): generates an AES-CMAC based MIC.

  • CryptoVerifyAesCmac(): verifies an AES-CMAC based MIC.


  • Despite their names, the functions CryptoComputeAesCmac() and CryptoVerifyAesCmac() neither compute nor verify a complete AES-CMAC value. These two functions actually use an MIC, which corresponds to the first four bytes of the AES-CMAC value. The truncation is done as described in RFC 4493.