ThingPark Activation Service Overview

ThingPark Activation is a platform that allows you to simplify and secure Device onboarding on your Internet of Things (IoT) platform.

ThingPark Activation consists of the following offers:

• Device activation without any security provisioning on your network.
• Simple security workflows for Device manufacturers producing devices for your home platform.
• Resolution of unknown AppEUI/JoinEUI for Device using activation away from home.
• Security for Device root keys using certified hardware appliances.
• Secure and confidential delivery of Device session keys to Application Servers connected to your platform.

ThingPark Activation Solution Architecture Description

The ThingPark Activation solution is composed of the following components:

• A LoRaWAN™ 1.0/1.1 and LoRa® Backend Interface 1.0 compliant Join Server.
• A LoRaWAN™ 1.0/1.1 compliant Hardware Security Module.
• A Device manufacturer pre-commissioning API.
• An Operator/Subscriber commissioning API.
• A User Interface for Subscriber commissioning.

The ThingPark Activation solution is illustrated in the following figure.

The above figure illustrates how LoRaWAN™ servers are interconnected to ThingPark Activation, and how the different parties are using the service.

The Device commissioning has been split into two steps that can be performed by two different parties:

• Pre-commissioning: Device root keys (AppKey for LoRaWAN™ 1.0 Devices, AppKey and NwkKey for LoRaWAN™ 1.1 devices) are imported into ThingPark Activation. This is done using a manufacturer account and can be performed by the following:
  • Secure Element manufacturer: ThingPark Activation Secure Element partners are sharing secrets with Actility directly, so the other parties do not need to get access to the secret keys.
  • Module manufacturer: when a module is not equipped with Secure Element, the Module manufacturer can ship to Devices manufacturers personalized modules, in which case keys are shared directly with Actility without Device manufacturer involvement.
  • Device manufacturers: for un-personalized modules, Device manufacturer can generate or import keys from key holder, and pre-commission theses keys independently of the network on which the Device will be provisioned.
• Commissioning: when a pre-commissioning has been performed before this stage, the Network Server commissioning only requires non-secure information such as Device Profile, Routing Profile and Service Profile (aka. Connectivity Plan). This is done using a Subscriber account and can be performed by the following:
  • Network Operator: most often, Mobile Operators present a customer-facing branded GUI to their subscribers and integrate through ThingPark provisioning APIs.
  • System Integrator: when the installation is performed by integrators, they are most often using APIs for mass provisioning.
  • End User: for B2C market, products are often sold directly to end users, who are provisioning their devices through the Actility GUI.

The ThingPark Activation Join Server (JS) is connected to the LoRaWAN™ operator home Network Server through the standardized LoRa® Backend Interface 1.0. It uses AppEUI/JoinEUI (same field, new name defined in LoRaWAN™ 1.1 specification) values from Actility IEEE block:

• Default ThingPark Activation JoinEUI: F0-3D-29-AC-71-01-00-01
• Dedicated JoinEUI: can be provided on-demand.

Network Servers must be configured to forward homeNSRequest, JoinRequest and ReJoinRequest messages containing this JoinEUI to ThingPark Activation see Connect Your Network Server to ThingPark Activation.

ThingPark Activation handles the homeNS, JOIN and REJOIN procedure securely, and derive session keys. They are encrypted using a transport key defined with the Network Server (see Connect Your Network Server to ThingPark Activation) and the Application Server. They are then sent to the hNS. The hNS is then responsible for decrypting Network Session Key(s), NwkSKey for LoRaWAN™ 1.0 devices and NwkSEncKey/FNwkSIntKey/SNwkSIntKey for LoRaWAN™ 1.1 devices and forwarding Application Session Key (AppSKey) to the Application Server.

ThingPark Activation Pre-commissioning Overview

The pre-commissioning procedure consists in AppKey sharing for LoRaWAN™ 1.0 devices, or AppKey and NwkKey sharing for LoRaWAN™ 1.1 devices with the ThingPark Activation platform.

This is performed using a Manufacturer account that contains the following information about all devices manufactured by this entity:

Field	Description
Device name	Freeform text for Device set identification
Administrative info	Freeform text for Device set management
Secure Element	Indicates if Device is fit with Secure Element from a ThingPark Activation partner
LoRaWAN™ Version	1.0.x or 1.1
DevEUI	Device IEEE 8B EUI
AppEUI	Join Server route EUI
AppKey	If no Secure Element is fitted, secret Application root key
NwkKey	If no Secure Element is fitted and for LoRaWAN™ 1.1 Device only, secret Network root key
TKM info	If Secure Element is fitted, Trusted Key Manager information. 10 bytes (2 bytes SE_INFO, 8 bytes SE_ID). SE_INFO: SE_MANUF_ID, SE_PROD_ID, LMK_ID, DERIVE_ALGO_ID. - SE_MANUF_ID is a 4b field identifying the SE Manufacturer. 0b0001 = STMicroelectronics. Other values will be used to identify Idemia, Microchip. - SE_PROD_ID is a 4b field identifying the SE part number. 0b0001 = STSAFE-A100, 0b0010 = STSAFE-A110. - LMK_ID is a 4b field identifying the SEK. DERIVE_ALGO_ID is a 4b field identifying the STM algorithm used to derive AppKey/NwkKey. 0b0001 = algo currently used.
HSM group	identifier of HSM group used for key encryption

When pre-commissioning the module / Device, the Manufacturer receives back an ownership token:

• ownerToken: hexadecimal string granting ownership to the Device from the Manufacturer account. OwnerToken is unique per device.

  In case of device with secure element integration, ownerToken is the TKM info (20 hex characters, 80 bits).

  Otherwise, ownerToken is generated by ThingPark Activation (32 hex characters, 128 bits).

OwnerToken should be provided to the Subscriber out-of-band for the commissioning step.

A simple mechanism for transporting this token is to include it in a barcode or a QR-code that is marking the Device or box transporting the Device. An example is provided inEmbed Token in QR-code.

ThingPark Activation Commissioning Overview

The commissioning procedure consists in claiming ownership for the Device in a Subscriber account, then filling up the information about the Device that was possibly not known at time of pre-commissioning.

The device claim is performed using a Subscriber account with the following information:

• DevEUI: Device IEEE 8B EUI
• ownerToken: hexadecimal string provided out-of-band by the Manufacturer

This operation transfers the Device from the Manufacturer account to the Subscriber account and can only be performed once. Once the claim is complete, the ownerToken is obsolete and can never be re-used for claiming this Device again, or another Device.

The subscriber must then add the following information to the Device provisioning:

• Home NS NetID: Once a connectivity plan has been subscribed for this Device with a give Network Server, the hNS NetID must be provided so that ThingPark Activation can answer homeNSRequest messages.
• ASTK: Once an Application Server has been selected, a security transport key must be generated and selected for this Device. This key encrypts AppSKey over the AS interface. For more information about this key, see Application Server requirements for details about this key.

For more information about these procedures, see Activating Subscriber on ThingPark Activation.

ThingPark Activation Join Procedure Overview

The Network Server must be configured to route the homeNS, Join and ReJoin procedures to and from ThingPark Activation. The configuration is detailed in Network Server configuration.

ThingPark Activation process these requests based on its commissioning information in a fully secured manner as it is installed with the HSM option.

For Join and ReJoin procedures, Session keys are derived and encrypted by HSM.

• NwkSKey(s) are sent encrypted to the Join Server in the message standardized by LoRaWAN™ Backend Interface 1.0. The Key Encryption Key label is preconfigured and the Join Server will decrypt the key(s) accordingly in order to use it. It is referred in this document as HLRCK.
• AppSKey is sent encrypted to the Network Server but using a KEK label that is only shared with the Application Server. It is referred in this document as ASTK. This is Network Server responsibility to forward this encrypted AppSKey to the Application Server so that it is decrypted by the AS only.

For full details on how ASTK is provisioned, please refer to Activating Subscriber on ThingPark Activation.