Security

The LoRaWAN protocol offers two layers of security implemented using the AES128 algorithm. On the network layer, the integrity of a message is enforced by the Message Integrity Code (MIC) and on the application layer the payload is encrypted. This means it is possible to have end-to-end encryption of the LoRa data. For LoRaWAN the used network keys are in the KPN domain and the application keys are in the customer domain and must comply to usage policies to prevent easy to guess variables. In the case of over the air activation (OTAA) the used NwkSKey and AppSKey are managed from the KPN domain (Join service) and can be periodically refreshed. Figure 4 shows the domain of the NwkSKey and the AppSKey.

Figure 4 NwkSKey and AppSKey domain

KPN not only depends on the included security mechanisms such as Over-The-Air Activation (OTAA) and AES128 in the LoRaWAN protocol specification, but it also applies KPN security mechanisms.The complete solution is hosted in KPN owned datacentre premises on which the Corporate Security Policy Framework (CSPF) is applicable. The KPN CSPF consists of a set of policies, standards and guidelines and is derived from high level KPN Group Corporate Security Policy. The CSPF is based on the international standard for information security (ISO27001 ) and the international standard for business continuity (BS25999).

The connection towards the customer Application Server is using the HTTPS protocol with TLS v1.2 signed certificate requirements. Within this tunnel the application data is authenticated by using bi-directional SHA-256 token calculation.

Added security by using the HSM

To make the LoRa network carrier grade, KPN uses a Hardware Security Module (HSM). Using the HSM will ensure that the payload of each message is encrypted end-to-end, from device to application server. The KPN network will not be able to decrypt or read the encrypted payload and will deliver the payload to the application server in its encrypted state, allowing the user to decrypt the message. To make end-to-end encryption possible, users are required to generate a RSA public and private key set. In addition to the end-to-end encryption, keys will be stored in encrypted state on the LRC to ensure the highest level of security of sensitive data.

Replay attack prevention mechanism

The network owns a mechanism that prevents replay attacks from having any effect. The replay attack prevention mechanism uses the frame counter (FCntUp) to determine whether an incoming message is valid. If a new message with the same counter as the previous message is sent, this message is ignored. As a result of this mechanism, it is not possible to turn devices off after every message without storing the counter-value. Since switching the device off resets the counter value, the device will only send messages with FCntUp=1. This means that all messages will be ignored by the network; consequently, the device will no longer send messages to the Application Server. It is not in accordance with the LoRa specifications to constantly reset the counter of a device, and thus the Replay Prevention Mechanism was implemented to increase the safety of our network and its growing user group.