Starter kit

IoT Security-as-a-Service is available on LARA-R6, SARA-R4 and SARA-R5 series modules. Several evaluation kits are available:

• EVK-R500S -  Evaluation Kit for SARA-R500S

• EVK-R510S -   Evaluation Kit for SARA-R510S

• EVK-R510M8S -  Evaluation Kit for SARA-R510M8S

• EVK-R6 -  Evaluation Kit for LARA-R6

• EVK-R422M8S -  Evaluation Kit for SARA-R422M8S

• EVK-R410-8-00 -  Evaluation  kit including LTE module for multi-regional use; Cat M1, NB1 bands: 3, 5, 8, 20, 28 

• EVK-R410-7-00 -  Evaluation  kit including LTE module for Korea; Cat M1 deployed bands 3,5,26

• EVK-R410-6-00 -  Evaluation  kit including LTE module for Japan; Cat M1 deployed bands 1, 8, 19 

• A complete application board that let you to easily start testing u-blox services

Please contact us to review your needs and to request a kit. 

u-blox service platform sign-up

u-blox Thingstream service delivery platform provides a management console that you can use to enable and manage the entire suite of u-blox services and the Security Thing, which is the logical representation of your module in the Thingstream platform.

Sign-up is free, quick and easy.  Just go to the management console and register with your company information. If you already have a Thingstream domain for Communication-as-a-Service (MQTT Anywhere, MQTT Here or MQTT Now), you do not need to register again, security services are already available.

The management console lets you create the credentials (access key and secret pair) required to manage and use IoT security services through REST APIs.

The API documentation and swagger (YAML) specification download are available here. 

Create a device profile

The next step is to create a device profile to claim the ownership of the devices and identify a group of devices that will share the same feature set.

To create the device profile unique identifier, and get the DeviceProfileUID required for device provisioning, access to the management console, and then select ‘Device Profile’ under the ‘Security Services’ panel on the left side.

A wizard will guide you through the steps to select the features and services linked to the profile. You can always change these at a later stage.

We recommend you to keep secure the DeviceProfileUID and do not share it

In the wizard you have to select a price plan to be used by devices that are provisioned using the profile. To get started, you can use the free Developer plan which allows you to manage up to 10 active devices. Find out more about the available price plans here .

Once you have created the device profile unique identifier, you need to seal the DeviceProfileUID in the device using AT commands. This is a simple procedure explained in the next Claim of ownership section.

Once completed the Claim of ownership and the bootstrap steps, the device will automatically appear in your account in the ‘Things’ section of the management console with the selected service and features enabled. You can use the same device profile for all the devices that need the same set of features and services and you can make changes for individual devices via the management console.

Claim of ownership

Automatic enrollment

Ownership can only be achieved by sealing a valid DeviceProfileUID into the devices. 

Secrets are provisioned into each module during the production process (the secrets are unique to each module and are identified by the RoT public unique identifier - RoTPublicUID).

The device profile unique identifier – DeviceProfileUID is equivalent to a model number and can be used to identify a group of similar devices that need to have the same set of Security features enabled at bootstrap.

You must seal the DeviceProfileUID into each device within the same group (normally this is all the devices with the same type number). This is completed (either in their host firmware, e.g. on device startup, or on their production line) by using the AT+USECDEVINFO AT command, along with their own device serial number (this unique number for the device will be defined by the customer). The device serial number is a custom field, defined by you, that shall be different for each device.

With the AT command you seal the DeviceProfileUID and the device serial number  into the RoT; they cannot be changed once they have been set – any subsequent calls to this AT command are ignored. Please be careful on sealing the correct DeviceProfileUID generated through the u-blox Thingstream platform.

Please note you can just do sealing procedure (via AT+USECDEVINFO) once and any future retry will be ignored by the device.

Once a device bootstraps, the system recognize the DeviceProfileUID and assign the ownership of the device to the correct customer account (the company). It is then possible to configure the device further using the functionality available in the u‑blox services APIs or the user Interface.

Note: to complete the bootstrap process you need to include the RoTPublicUID in the Whitelist as explained in the Device Whitelist guide. 

The basic process for the customer to claim ownership of a device is:

1.  Create the Device Profile UID.

2.  Seal the DeviceProfileUID into the correct device(s).

3. Connect each device to the Internet.

4.  Wait for each device to register to security services (monitor the status via AT+USECDEVINFO? query)

5. The device should now be assigned into customer’s account and the device registration date should be set.

The benefit of sealing the device profile during device production is that the desired set of security services and features will be immediately available after the bootstrap removing the need to create a campaign at a later stage when the device is in the field 

Change the ownership

You have the possibility to change the ownership of a single device or a group of devices. There are procedures in the u-blox back-end to handle it for you. Just write to services support (services-support@u-blox.com) and please provide the following information:

• DeviceProfileUID of the device(s) that the ownership should be changed

• List of RoTPublicUID 

• Current owner thingstream domain name

• Future owner Thingstream domain name 

Device bootstrap

1. The module bootstraps to the u-blox security server (icpp.services.u-blox.com) when the device first connects to the internet. The bootstrap process happens only once; if subsequent power cycles occur, then the device is recognized as already being bootstrapped.

2. The process replaces the factory-provisioned secrets and adds the necessary keys to enable the relevant features/services.

3. During bootstrap the device becomes associated with its registered owner (via the DeviceProfileUID that was created) and any cloned devices are rejected.

4. The customer now has ownership of the device.

During the initial bootstrap it is recommended that the application does not try to reset or power cycle the module until the process is completed successfully. The time needed to conclude the process is strictly dependent on the RAT being used. If the bootstrap process is interrupted before completion, the process will re-start from the beginning.

The bootstrap process requires 4 individual communication phases over which at least 1048 bytes are transferred.  The maximum amount of data that can be transferred will vary and can depend on:

1.   Whether “Feature authorizations” data must be sent.

2. Whether retransmissions must be done because an original attempt failed.

3.  Whether Internet Protocol version 4 (IPv4) or version 6 (IPv6) is being used.

The +USECDEVINFO can be called to confirm that the bootstrap attempt has either not yet finished (that is, the current attempt was not successful, and another attempt will be tried) or the bootstrap process has been successful.

The response to the AT+USECDEVINFO? Query has the following meaning:

If the bootstrap process is still in progress (that is, it has not finished or been successful or an error condition has occurred), then the AT command will return an error.

In SARA-R4 products, if the bootstrap process is still in progress, AT+USECDEVINFO? Will block until the operation is complete.

Two stage bootstrap

In some circumstances the bootstrapping of one or more devices may need to be completed in two stages (two-stage bootstrap).

This is the scenario when the bootstrap happens when the DeviceProfileUID has not already been sealed in the device. The device is registered but cannot be assigned to the correct customer.

When, at a later stage, the DeviceProfileUID is  sealed in the device, it communicates with the u-blox server and it is therefore assigned to the correct customer. The customer can then manage the device using the u-blox Thingstream Management console or the APIs.

Security Heartbeat

Once a device has successfully bootstrapped, it will continue to call the u-blox security service on a regular basis: this is known as a “security heartbeat”.

By default, the security heartbeat occurs automatically once a week (7 days). It is possible, though,

• to change the default setting using the Thingstream platform when creating the DeviceProfileUID or later on each device

•  to trigger a security heartbeat from the module by using the AT+USECCONN command:

To prevent flooding the server with security heartbeat messages, if the command is issued within 5 minutes of the last sent security heartbeat, the request will be rejected, and an error result code will be returned.

Security heartbeat in SARA-R4

To prevent flooding the server with "security heartbeats", if the command is issued within 5 minutes of the last sent "security heartbeat", the request will be rejected, and an error result code will be returned. The system time is used for measuring elapsed time. When a "security heartbeat" is sent, the system time is stored in NVM, therefore the value is persistent to power cycles. When an attempt to send a "security heartbeat" occurs, the previous send time is checked against the current system time, to see if the elapsed time is valid.

Security heartbeat in SARA-R5

• The "security heartbeat" message operation is required to update the status of the security.

• The "security heartbeat" message operation is for security reasons required to be an atomic message operation using a blocking send/receive cycle.

• The blocking send/receive cycle can execute up to 5 minutes (before timeout and abort) in case of network issues.

• The blocking send/receive cycle can block (up to 5 minutes) the execution of the command (affected commands listed below) which triggered the "security heartbeat" message operation.

•  The "security heartbeat" message operation before executing the blocking send/receive cycle verifies if the "security heartbeat" message shall be sent immediately due to security reasons.

• The "security heartbeat" message operation before executing the blocking send/receive cycle verifies if the "security heartbeat" message shall be sent immediately due to server configured time period elapsed.

To prevent flooding the server with "security heartbeats", if the command is issued within 24 hours of the last sent "security heartbeat", the request will be rejected, and an error result code will be returned. The system time is used for measuring elapsed time. When a "security heartbeat" is sent, the system time is stored in NVM; therefore, the value is persistent to power cycles. When an attempt to send a "security heartbeat" occurs, the previous send time is checked against the current system time, to see if the elapsed time is valid.