Separate Session Key Generation Approach for Network and Application flows in LoRaWAN

LoRaWAN prides itself in having security specified and implemented from the start. LoRaWAN also boasts end-to-end security between the device and the application server using an application session key, which protects in confidentiality the applicative payload, shielding it away from the prying eyes of the operator. Control messages exchanged between the end-device and the network server are also authenticated, with a different key, the network session key. However, with the current LoRaWAN 1.0 specification, both session keys (network and application) are generated by the same network server and they are derived from the same master key. Therefore, even though there are two different derived keys, there is no real isolation between network and application flows. As a result, this does not achieve good separation between network security and application security. Besides, it makes it complex to define the liability chain in case of key compromise. Moreover, with LoRaWAN 1.0, an end-device can only be connected to one application server. This connection is established as the end-device joins the network and is fixed as long as the end-device is connected to the network. The device cannot later send data to another application server, unless it de-associates with the network and re-associates, which is cumbersome and costly in terms of control messages. To overcome these limitations, we propose an architecture and a set of protocols by which two different master keys are used to derive network session keys and application session keys, respectively, and by which the network master key stays with the network server and the application master key stays with the application server. Thus, we provide end-to-end security between end-device and network server, and end-to-end security between end-device and application server. Having this clear role separation allows for better security and trust among entities. We also allow an end-device to join multiple application servers. Our solution makes roaming clearer since only the new network needs to be joined, without having to join the application servers again. We will show how this all works together, including in the case of passive roaming and handover roaming. Using the ProVerif tool, we formally proved that our protocols meet the secrecy and authentication properties.