Activation modes

Overview

Depending on the level of security that you want to allocate to your IoT network , you can choose among three types of device activation. The security level is defined by how the root and MAC session keys are generated, exchanged and stored for your end-devices.

The activation modes are listed below from most secure to less secure:

1. Over-the-Air Activation (OTAA) with external Join Server: the most secured activation mode.

   • The device's root keys are securely pre-commissioned by the manufacturer in an external Join Server, without being directly communicated to the device owner. In ThingPark Activation (TPA), the root keys are securely stored in a Hardware Security Module (HSM), they cannot be compromised by adversaries.
     To learn more, see Seamless integration with ThingPark Activation.
   • The Join procedure generates session keys that are renewed during each Join cycle, so the end-device does not use the same session keys during its whole lifetime.

2. Over-the-Air Activation (OTAA) with local Join Server:

   • The device's root keys are directly provided to the device owner. This activation is less secure than using an external Join Server, since the root keys can be exposed to third-parties or may be lost by the device owner.
   • The Join procedure generates session keys that are renewed during each Join cycle, so the end-device does not use the same session keys during its whole lifetime.

3. Activation By Personalization:

   • The device does not include root keys and only includes permanent session keys that cannot be renewed.
   • This is the least-secure activate mode.

tip

For already-provisioned devices, the activation mode is displayed in the device detail page from ThingPark's user interface. To learn more, see Viewing/editing device details.

Seamless integration with ThingPark Activation

ThingPark Activation (TPA) is Actility's managed service offering secure activation to LoRaWAN® OTA devices through a secure Join Server (JS). All the LoRaWAN® keys are secured by a Hardware Security Module (HSM) embedded in TPA service.

A typical process of OTA device activation consists of the following steps:

Stage	Description
#1 - Pre-commissioning	The Device Manufacturer imports the device information (DevEUI, JoinEUI, AppKey, NwkKey (for LoRaWAN® 1.1 devices)) into TPA. Upon successful pre-commissioning, the Device Manufacturer gets an Owner-token from TPA to act as a proof of ownership for this DevEUI. The device manufacturer should communicate this Owner-token to the device buyer/owner; for instance, by including it in the standard QR code specified by LoRa Alliance. At this stage, the device is said to be “generic”, meaning it is not yet personalized for (nor associated with) any LoRaWAN® Network Server (NS).
#2 - Commissioning	When a ThingPark Enterprise Subscriber buys this generic device buys this generic device, they should simply provision the device on their ThingPark subscription, by providing the DevEUI, JoinEUI, Owner-token and selecting the option “External Join Server”. This way, the claim procedure is automatically managed by ThingPark towards ThingPark Activation’s Key Manager application without having the end-user to connect to TPA and manually claim the device. At the end of the commissioning stage, TPA's Join Server is ready to handle Join Requests forwarded by the home Network Server (NS) for this device.
#3 - Activation	When a commissioned OTA device is powered-on, it sends a Join Request message that is routed to the competent Join Server (JS), identified by its JoinEUI. JS processes the request and generates a Join Answer. At the end of this over-the-air activation step, the device shall generate its MAC session keys and hold a secure LoRaWAN® session with the network.

This three-step process is illustrated by the following diagram:

The following diagram shows the different states of OTA device during its life cycle, as specified by LoRaWAN® Backend Interfaces:

On ThingPark Enterprise UI, the device manager needs to provision the device with the option Activation mode = "Over-the-Air Activation (OTAA) with external Join Server" and sets the Owner-token, as per this example:

Once the device is provisioned, the claim procedure is automatically triggered by ThingPark Enterprise towards TPA, based on the Owner-token provided by the end-user.

If the claim procedure fails for any reason (for instance, the device has not been pre-commissioned on TPA, the device is already claimed, Owner-token is invalid...), the device creation shall fail with the following error:

This automatic claim procedure applies to both unitary device creation and mass import use cases.

When the device is deleted from ThingPark Enterprise, an unclaim request is automatically triggered towards TPA Key Manager if the device was already commissioned on TPA.

Activation QR codes

For a LoRaWAN® end-device to be activated on a given network, several device-specific attributes need to be provisioned on the Network Server.

These attributes include mandatory ones, such as the device identifier (DevEUI), Join Server identifier (JoinEUI), and device profile, and the optional ones, such as serial number, owner token, and vendor-specific attributes.
Historically, such attributes have been either (partially) printed on the end-device for the user to read them and manually enter them, or passed to the user in an email for him/her to copy-and-paste. In either case, the procedure has been laborious and prone to errors.

For confidentiality reasons, the device's root key (AppKey) must never be included in the QR code. Therefore, to maximize the efficiency of using QR codes and prevent out-of-band exchanges between the manufacturer and the device owner (yielding unsecure delivery of the AppKey), it is highly recommended to rely on the external Join Server mode to activate OTAA devices. With this activation mode, the Owner Token can be safely present in the QR code.

In order to facilitate end-device provisioning for zero-touch user experience (without human intervention), LoRa Alliance has defined a standard QR encoding for end-device attributes. QR codes that are generated in accordance with the standard can embed all of the aforementioned info in a way that they can be placed on the end-device casing and read using a QR reader app. Streamlined and reliable end-device provisioning is the benefit of using this new standard.

The following image shows an example of a standard QR code, together with the format of the underlying onboarding tag:

For detailed information about the LoRa-Alliance technical specification, see TR005-LoRaWAN-Device-Identification-QR-codes.