0

I was reading the the specification of LoRaWAN, a network for IoT which uses AES for the security, when I saw this:

Note: The network server uses an AES decrypt operation in ECB mode to encrypt the join-accept message so that the end-device can use an AES encrypt operation to decrypt the message. This way an end-device only has to implement AES encrypt but not AES decrypt.

This Q&A, along with several other sources*, indicates that ECB should not be used. The answer of the question linked add that "OFB/CFB is better because you only need encryption and not decryption, which can save code space". So why have the conceptors of LoRaWAN choosen to use ECB?

*: Wikipedia gives a striking example with a picture ciphered with AES-ECB.

Community
  • 1
  • 1
Shan-x
  • 1,146
  • 6
  • 19
  • 44
  • If they use a new key for each encryption, then this would be fine. Are they? (You read the specification after all) – Artjom B. Jun 14 '16 at 14:12
  • Nop, if I understood correctly keys are calculated once. – Shan-x Jun 14 '16 at 14:46
  • in the specifications, there is that: `An end-device has to go through a new join procedure every time it has lost the session context information.`. I don't know how the session context information can be lost. – Shan-x Jun 14 '16 at 15:00

1 Answers1

0

From my (quick) reading of the specification, the same device-specific key ("Appkey") is used to "decrypt" the plaintext message at the server. I put "decrypt" in quotes, because it's using AES decrypt to actually encrypt the message; the receiving device, which only needs to implement AES encrypt, can then decrypt the ciphertext. Remember that these are very resource-constrained, low-power devices.

Anyway, to answer your question -- I'm basing this off of section 6.2.5 of the specification -- it appears that many of the fields are somewhat predictable, and the key isn't changing, so they are relying on the uniqueness of the 24-bit nonce (nonce = number used once, ever). 2^24 is approximately 16 million. If the nonce is ever re-used (even accidentally, for example if it is randomly generated and there is a nonce collision (just google "Birthday Paradox") ) you have a real security problem.

I haven't spent enough time w/ the specification to further understand/criticize the security measures, but I'd be willing to bet there are some implementations using rand() for the nonce (sad face) or even worse, a hard-coded value (really sad face).

Dan
  • 10,303
  • 5
  • 36
  • 53