Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

IOT LoRaWAN device doesn't decrypt below 10 bytes payload

0

We are using LoRaWAN OTAA v1.1 and are noticing that if we send uplink data with a payload below 10 bytes that it doesn't get decrypted. What is shown in network analyzer and the associated MQTT topic is the encrypted payload. If we send 10 bytes or more it is properly decrypted and shown in both network analyzer and MQTT decrypted.

Topics
Internet of Things (IoT)
Tags
AWS IoT Core
Language
English
asked 3 years ago369 views
1 Answer
0

LoRaWAN payload encryption is typically done through the AES-128 algorithm, which operates on 16-byte (128-bit) blocks of data. If the payload is less than 16 bytes, it's supposed to be padded to make it up to 16 bytes before it's encrypted. The decryption process should then be able to handle this padding correctly and reveal the original data.

The problem you're experiencing might be due to one of the following reasons:

  • Padding Issue: The encryption or decryption process might not be handling padding correctly. Ensure that your devices and network server are using the same padding and unpadding techniques.

  • Firmware/Software Issue: Check whether the firmware/software on your device and network server is up-to-date. If not, consider updating it. It's possible that this could be a bug that has been fixed in a later version.

  • Incorrect Key: For OTAA, the Network Session Key (NwkSKey) and the App Session Key (AppSKey) are generated during the join procedure. If these keys are not configured correctly on both the device and network server, decryption can fail.

  • Configuration Error: Make sure that the AWS IoT Core for LoRaWAN setup, such as AWS IoT rules for decrypting the data, is correctly configured.

answered 3 years ago
  • Dan
    3 years ago

    Thanks for your answer. We are using a port of LoRaMac-node on the device. According to LoRaWAN spec: Encryption and decryption of the payload is done by truncating (pld | pad16) xor S to the first len(pld) octets

    PayloadEncrypt doesn't pad but the above truncation looks like it should yield same results anyway without padding. I am wondering though if this could be an issue with the MIC value which gets computed from message (I assume it's supposed to be before truncating)?

    It's odd that it works with 10 bytes (i.e. doesn't require 16) but not less.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content