4

My question is based on the specification of the protocol LoRaWAN and especially on the part 6.2.5 Join-accept message.

It is said that the join-accept message is encrypted using AES ECB. This is (normally) a single message created like that:

aes128_decrypt(AppKey, AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC)

Imagine that an attacker can listen the communications. He doesn't know AppKey (obviously), AppNonce and of course the MIC. If the attacker can make the end device send plenty join-request messages and if the server always responds with a corresponding join-accept message, can the attacker gain knowledge of the AppKey using the flaws in AES ECB?

Disclaimer: sorry if I'm not clear, cryptography is not my speciality.

Raoul722
  • 2,836
  • 2
  • 20
  • 39
Shan-x
  • 265
  • 2
  • 7

2 Answers2

5

If the attacker can make the end device send plenty join-request messages and if the server always responds with a corresponding join-accept message, can the attacker gain knowledge of the AppKey using the flaws in AES ECB?

No. ECB is flawed, but not that flawed.

At worst the attacker can know the encryption of a message if they have already seen the same message encrypted. (Or decrypted, as the case may be - LoRaWAN uses the decryption direction here to avoid having to implement both directions in the end-device.)

That can still lead to attacks, but key recovery is not possible.

otus
  • 32,132
  • 5
  • 70
  • 165
  • Do you have any idea about what could be theses attacks? – Shan-x Jul 06 '16 at 09:54
  • 1
    @Shan-x, I don't think there's any attack here, just in general ECB is not semantically secure and easy to e.g. replay. – otus Jul 06 '16 at 09:57
  • ECB is not flawed. You can't say that a brick is flawed because you can't live in it. ECB purpose is to build ciphers. It's operator flaw to use ECB in wrong way. – Agent_L Jul 06 '16 at 14:20
  • @Agent_L, ECB is a mode of operation, i.e. a way to use a cipher. I'm not aware of its use in building ciphers, what do you mean? While I grant that there are situations where using it is fine, as a general purpose mode for encrypting normal data it is very poor. – otus Jul 06 '16 at 14:37
  • @otus well, ECB is as direct exposure of underlying AES as you can often get. – Agent_L Jul 06 '16 at 14:52
4

ECB mode has several weaknesses as discussed in Why shouldn't I use ECB encryption? but in this specific case, it does not allow to gain information about the secret key AppKey involved.

Indeed, encrypting the same block with the same AppKey will returns the same ciphertext. But in the LoRaWAN join-accept message, it does not matter because the server encrypts only one 16-byte block which is AppNonce | NetID | DevAddr | RFU | RxDelay | CFList | MIC.

Plus, each such block should be different because as specified in the LoRaWAN specification :

  1. The AppNonce is a random value or some form of unique ID provided by the network server

  2. The DevAddr consists of 32 bits identifies the end-device within the current network

If the attacker can make the end device send plenty join-request messages and if the server always responds with a corresponding join-accept message, can the attacker gain knowledge of the AppKey using the flaws in AES ECB?

Note that a join-request has the following structure : AppEUI | DevEUI | DevNonce where AppEUI identifies the application and DevEUI identifies the end-device. So if an attacker make the end-device send plenty join-request messages, the server should remember that the device identified by DevEUI made a join-request a few time ago and should respond with the same DevAddr (or not respond at all) to avoid denial-of-services attacks. But I did not see anything about it in the specification.

Community
  • 1
Raoul722
  • 2,836
  • 2
  • 20
  • 39