6
$\begingroup$

I'm reading about LoRaWAN (specification). This network protocol has a particular way to encrypt data, detailed in the part 4.3.3.1. Here is a recap of how the encryption work, as I understood it.

First, a sequence A with blocks with a size of 16 bytes each A1..An is created. The length of A depends of the length of the payload so that len(payload) <= 16*n = len(A) < len(payload) + 16. Here are the values used for the block Ai:

0x01 | 0x00 | 0x00 | 0x00 | 0x00 | Dir | DevAddr | Counter | 0x00 | i

One block is 16-bytes long. The Counter is incremented for each payload; i is incremented for each block created (1 <= i <= n). Dir is 0 or 1 depending if it's upward or downward, and the DevAddr is fixed with the address of the end-device.

Now that the blocks are created, they are encrypted to get a sequence S of blocks Si:

Si = aes128_encrypt(K, Ai) for i = 1..n
S = S1 | S2 | .. | Sn

And finally the payload is encrypted:

(pld | pad16) xor S
truncation of the first len(payload) bytes

The message sent is created by concatenating a header (containing among other things the values of DevAddr and Counter), the encrypted payload and a MIC (Message Integrity Check) generated with another AES key. The receiving device knows the key, so it can:

  • check the MIC
  • create the blocks A1..An by using the values indicated in the header
  • encrypt them to get the sequence S
  • decipher the payload

Here are my questions

I find this implementation basic. More specifically, I'm under the impression that a specific bit of the payload is in the same position after the encryption. But I don't know if an attacker can use that to gain information?

Also, an attacker can know pretty much everything by intercepting messages, so he can probably know the sequence A. Is there a way he can decrypt the payload or gain information about the key?

$\endgroup$
8
$\begingroup$

This is identical with CTR mode encryption with a MAC. That's known to be secure.

It doesn't say in your question if:

  1. the Ai blocks are completely unique;
  2. the header is included in the MIC calculation.

If those preconditions are met then I don't see any issue with the protocol.

The first one I cannot verify but seems likely, the second one is certainly true (when I look at the linked document).

Note that the MIC is somewhat short, only 32 bits. For this protocol it could be enough. On the other hand, the AES-128 based CMAC calculation is fine for a MIC.


Disclaimer: this should not be seen as a full review of the protocol, just a direct answer to the question.

$\endgroup$
  • $\begingroup$ The Ai blocks are (normally) unique given that the Counter is not repeated. Though, the block is constructed using known data + counter, whereas I thought it was better to use nonce + counter . Is that bad? Another thing is that the MAC (it's the same thing that the MIC, right?) is calculated with another key and is verificated by a third party (another server on the network). So I guess this is a security flaw, as you have to trust this server. $\endgroup$ – Shan-x Jun 21 '16 at 7:56
  • $\begingroup$ @Shan-x The idea of the nonce is to make the block unique for subsequent encryptions. If the key isn't reused or if the blocks never repeat for any other reasons then it's fine. Yes, MAC seems to be a MIC, maybe they changed the name because of verification by a 3rd party. If something like that is a security flaw depends on the threat model. If you are currently reading this using HTTPS then you're trusting a third party as well (the CA). $\endgroup$ – Maarten Bodewes Jun 21 '16 at 8:07

protected by e-sushi Nov 17 '16 at 17:05

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.