LoRaWAN security: Can the Network Server generate the AppSKey?

TTN Network and Services
1

Hello,

I am a little bit confused about the LoRaWAN security mechanism.

The NwkSKey is used by both the network server and the end-device to calculate and verify the MIC (message integrity code) of all data messages to ensure data integrity.

The AppSKey is an application session key specific for the end-device. It is used by both the application server and the end-device to encrypt and decrypt the payload field of application-specific data messages.

So technically the Network server does not know the AppSKey. What I dont understand is that in the OTAA procedure, the network server responds with a Join-accept that is encrypted using the AppKey. So if the network server has already the AppKey, it can generate the AppSKey using this formula:

AppSKey = aes128_encrypt(AppKey, 0x02 | AppNonce | NetID | DevNonce | pad16)

In that case the network server if he would like to it can decrypt the message destinated to the application.
Is my analysis correct or I am missing something?

Thanks and best regards!

1 Like
2

hi sabrina, i saw your question on stack-overflow but i have no account.

yes, you are right, the Network server can derive the AppSKey, and the two layer encryption is broken.

this will be fixed in LoRaWan 1.1 (to be released in Sep-2017):

the AppKey will be raplaced by two keys: AppKey & NwkKey.

the NwkSKey will be replaced by 5 keys: NwkSEncKey, SNwkSIntKey, FNwkSIntKey (to encode and integrity check isolately) + JSEncKey and JSIntKey (for joining).

the AppKey will be used to derive AppSKey only

the NwkKey will be used to derive NwkSEncKey, SNwkSIntKey, FNwkSIntKey, JSEncKey and JSIntKey

2 Likes
3

In the architecture of The Things Network, this is not necessarily true. The JoinAccept message is encrypted by the Handler component (which you can run on your own servers), keeping the AppSKey safe, while giving the network server only the NwkSKey.

1 Like
4

But this violates the fact that NwkSKey is only between the network server and the end device cause in this case the handler has both keys. Right?

5

That is correct and it will be different for LoRaWAN 1.1 implementations

1 Like
6

@htdvisser I am reading the LoRaWAN1.1 Backend Interface Specification.

In this specification it appears that the AppSKey is shared from the ApplicationServer to the JoinServer. Does this also violate the same issue that @sabrina mentioned above?

7

In LoRaWAN 1.1 the join server is a trusted (third) party. The join server knows the root keys of a device and will know the session keys when the device joins. The join server then makes sure that the network server receives only the network session keys and the application server receives only the application session keys.

Our current v2 backend indeed violates the LoRaWAN 1.1 key separation by giving network session keys to the application server (handler). This is simply a consequence of the key derivation in LoRaWAN 1.0. Behind the scenes we have started working on version 3 of our backend, which will have a slightly different architecture to accommodate for these changes and will be LoRaWAN 1.1 compliant (though backwards compatible with 1.0.2).

I recommend you to join our LoRaWAN 1.1 webinar next week to learn more about the changes and our plans: https://youtu.be/ewsXKc3bk1U

2 Likes