- 최신
- 최다 투표
- 가장 많은 댓글
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.
답변함 3년 전
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.