ThingPark Activation Service Overview
ThingPark is a platform that allows you to simplify and secure your device onboarding on various Internet of Things (IoT) platforms.
ThingPark Activation consists of the following offers:
- Device secret key sharing with a centralized platform to remove any need for security provisioning on different IoT networks.
- Generic device personalization with a single AppEUI/JoinEUI for all IoT networks, simplifying device manufacturing floor for multi-operator devices.
- Native support of activation away from home for onboarded IoT networks.
- Security for device root keys using certified hardware appliances, including Device secret key generation (exposing HSM true random number generator).
- Secure and confidential delivery of device network session key(s) to Network Server of Connectivity Providers.
- Secure and confidential delivery of device application session key to Application Servers used on the IoT platforms.
- Secure and confidential delivery of data payload to Application Servers.
Device Activation stakeholders
LoRaWAN™ IoT devices are produced by Device Manufacturers. Device Manufacturers are responsible for the personalization and security of their devices. Device personalization consists of the following steps:
- Root keys generation
- Root keys injection in device
- Root keys storage or
- Sharing up to the Join Server supplier.
The root keys are either AppKey for LoRaWAN™ 1.0 devices or AppKey and NwkKey for LoRaWAN™ 1.1 devices.
Performing the Key sharing step directly with the Join Server supplier before the device is sold is called Pre-commissioning.
For a device using Secure Element or modules, some of these steps may have already been performed by the suppliers, so the device Manufacturer simply needs to pre-commission generic device information without sharing root keys.
When devices are sold to End Subscribers, directly or indirectly, additional information needs to be provisioned in the network side: Service Provider account and connectivity plan, data routing to Application Servers, Device Profile.
This step is called Provisioning and is illustrated in the following graphic.
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 with the 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 figure above 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 distinct parties:
- Pre-commissioning: Device root keys (AppKey for LoRaWAN™ 1.0 device, 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
- 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 the module is not equipped with the Secure Element, the module manufacturer can ship personalized modules to device manufacturers, in which case, keys are shared directly with Actility without any device manufacturer involvement.
- Device manufacturers: for un-personalized modules, the device manufacturer can generate or import keys from the key holder, and pre-commission these keys independently from the network on which the device will be provisioned.
- Commissioning: when the pre-commissioning has been performed before this stage,
the Network Server commissioning only requires non-secure information such as
the 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, Service Providers present a customer-facing branded GUI to their subscribers and integrate it 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 the B2C market, products are often sold directly to end users, who are provisioning their devices through the Actility GUI.
The ThingPark Activation JS is connected to the LoRaWAN™ operator home Network Server through the standardized LoRa® Backend Interface 1.0. It uses AppEUI/JoinEUI (same field, the 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
ThingPark Activation handles the homeNS, JOIN and REJOIN procedures securely, and derive session keys. They are encrypted using a transport key defined with the Network Server (see Connect your device factory to ThingPark Activation) and the Application Server and send 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 for forwarding Application Session Key (AppSKey) to the Application Server.
ThingPark Activation pre-commissioning overview
The purpose of the pre-commissioning is to share a root key between a key holder (Secure Element, Module or Device manufacturer) and Join Server on the LoRaWAN™ network. It consists in AppKey sharing for LoRaWAN™ 1.0 devices, and 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, the secret Application root key applies. |
| NwkKey | If no Secure Element is fitted and for LoRaWAN 1.1 device only, the secret Network root key applies. |
| 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 the HSM group used for key encryption. |
When pre-commissioning the module or the 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 TWA (32 hex characters, 128 bits).
The OwnerToken should be provided to the Subscriber out-of-band for the commissioning step on the hNS.
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.
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 the time of pre-commissioning. Thanks to the pre-commissioning step, no keys are exchanged during this step.
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 reused 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.
ASTK should be provisioned by the Subscriber on the Application Server using AS proprietary provisioning API (it is out-o-band from ThingPark point of view).
ThingPark Activation Join procedure overview
Network Server must be configured to route the homeNS, Join and ReJoin procedures to and from ThingPark Activation.
ThingPark Activation processes 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 the HSM.
- NwkSKey(s) are sent encrypted to the Network Server in the message standardized by LoRaWAN™ Backend Interface 1.0. The Key Encryption Key label is preconfigured and the Network 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 the Network Server responsibility to forward this encrypted AppSKey to the Application Server so that it is decrypted by the AS only.