search

mcci-catena / arduino-lmic

LoraWAN-MAC-in-C library, adapted to run under the Arduino environment
https://forum.mcci.io/c/device-software/arduino-lmic/
MIT License
636 stars 208 forks source link

lmic_aes_decrypt() #656

Closed pomplesiegel closed 3 years ago

pomplesiegel commented 3 years ago

Would it be fairly simple to locate or provide the implementation for lmicaesdecrypt, either in the form of the "ORIGINAL_AES" or "IDEETRON_AES"?

I could not find a source for this online. It would be great to have this companion method on hand, so one could do both encryption and decryption for their application without bringing in other large libraries with their own look-up tables.

Any other ideas for how to solve this problem would be appreciated as well

Thank you!

cstratton commented 3 years ago

LoRaWAN is designed to dodge the need for an AES decryption algorithm in nodes, by doing things "backwards" in the downlink direction, such that the network actually "encrypts" by decrypting such that the node can decrypt by encrypting. As such, the omission of a decrypt() method is quite intentional and and an attempt to save code/table space.

Buried in LMiC sources you can find that the Ideetron version comes from https://github.com/Ideetron/RFM95W_Nexus/tree/master/LoRaWAN_V31 which it itself a LoRaWAN project, and as such does not appear to have ever had a decrypt() implementation.

Not yet entirely clear what the source of the other AES is, but it seems to also have been optimized for this usage.

If at all possible, you may want to do what LoRaWAN does and adapt your other encryption uses such that the node only ever performs the "encrypt" operation regardless of actual purpose.

Or you could explore changing out the AES encryption entirely for both LMiC and your other need. Worth noting that Semtech's stack at https://github.com/Lora-net/LoRaMac-node seems to try to make use of the hardware capability many more recent MCU's bring, so depending on your target that could be an option - there's also a pure software implementation that can be extracted for use; it's bigger than the Ideetron but I believe offers what you need, and under more permissive licensing.

But IMHO this is neither trivial nor within the scope of a LoRaWAN stack, so the issue should probably be closed.

pomplesiegel commented 3 years ago

Hello @cstratton, this is immensely helpful, thank you! I was totally unaware of the backwards usage of encryption for the downlink messages, but it makes total sense. Are there any added vulnerabilities of doing things backwards like this (decryption used as encryption), or is the chosen direction totally arbitrary?

terrillmoore commented 3 years ago

@pomplesiegel, my understanding is that they did it to avoid "full encryption" in devices, which helps with export controls.

By the way, if you check the branch devel-issue578, you'll find that as part of the secure-element refactor, I also refactored the crypto so there's an explicit driver API. This means that it would not be hard to replace the software crypto with a hardware version. Even if using a hardware secure element, you may need to use the CPU's crypto, because for Class B, the LoRaWAN device must use AES-decrypt to form a hash of the time etc. to figure out which slot the network will use for downlinks. Some secure elements (such as the one from Trusted Objects) don't expose AES primitives, and the LMIC has to deal with this situation. So there's an explicit crypto API that could be retargeted to hardware (or a different software library).

terrillmoore commented 3 years ago

This is not really a bug; moving to discussions. But to do that, I have to reopen the issue? So it seems.

terrillmoore commented 3 years ago

Hm, still can't turn into a discussion. Must be a different API. Closing again.