Is the use of AES in LoRaWAN correct? 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) &lt;= 16*n = len(A) &lt; 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 &lt;= i &lt;= 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?
This is identical with CTR mode encryption with a MAC. That's known to be secure.

It doesn't say in your question if:


the Ai blocks are completely unique;
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.