Last update: October 7th, 2021
Device Whitelist configuration guide has been added
IoT Security-as-a-Service is a managed services solution that makes extremely simple to protect your data at rest and from silicon to cloud, ensuring that you can focus more on your business and enjoy faster time-to-market.
We implement a true end-to-end concept where data are protected from the device to the end user and are not visible by the intermediate nodes/platforms nor by the service provider.
Our approach ensures minimal code development and investment and provides the highest standards of security, leveraging the root of trust in u-blox LARA-R6, SARA-R4 and SARA-R5 module platforms to bring a unique and immutable identity for univocal identification and zero touch on-boarding in leading IoT cloud platforms.
The innovative symmetric Key Management System delivers an unprecedented level of security, giving the possibility to generate an infinite number of crypto keys on-the-fly, to be used for (D)TLS or for any other purpose.
All u-blox security solutions are designed for LPWA constrained devices, reducing the data usage and the number of handshakes, thus minimizing the power consumption that is a critical metric for most IoT devices.
You can find more information about IoT Security-as-a-Service here.
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.
Generate the access keys
In order to start using IoT Security-as-a-Service, you need to generate an access key and secret. You can do this by going to the Access Keys page under Security Services and clicking on the "Generate Keys" button.
In this section
Security Services API documentation
Still need help?
If you need more help or have any questions, please send an email to firstname.lastname@example.org.
Once you have generated your key and secret, make sure you save them somewhere safe as the secret cannot be recovered after you leave the page.
You can generate up to 5 access keys.
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
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:
Create the Device Profile UID.
Seal the DeviceProfileUID into the correct device(s).
Connect each device to the Internet.
Wait for each device to register to security services (monitor the status via AT+USECDEVINFO? query)
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 (email@example.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
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.
The process replaces the factory-provisioned secrets and adds the necessary keys to enable the relevant features/services.
During bootstrap the device becomes associated with its registered owner (via the DeviceProfileUID that was created) and any cloned devices are rejected.
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:
Whether “Feature authorizations” data must be sent.
Whether retransmissions must be done because an original attempt failed.
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.
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.
Feature and service provisioning
You can activate/deactivate a feature in two ways:
At device profile level: when the device profile is created using the u-blox Thingstream portal. In this case all devices that makes the bootstrap with that DeviceProfileUID, will get activated the selected features. Be aware that if you change the Device profile definition at a later stage (i.e. deactivating a feature previously enabled), this change will be applicable only to the devices that make bootstrap from that time.
Remind to add each device (RoTPublicUID) to the Whitelist to enable the automatic feature provisioning
At device level: on each active device you can activate/deactivate a feature at any time using the Thingstream portal or the APIs
Activation/deactivation on the device happens at the next Security Heartbeat event after that you have applied the new setting. You can monitor the status both from the API and the User Interface.
You can always trigger the Security Heartbeat as described in the previous section
Feature provisioning is applicable to:
Local Data Protection
Local Chip-to-Chip Security
Zero Touch Provisioning
Symmetric KMS (PSK provisioning) and E2E Data Protection services are automatically provisioned during the bootstrap process when the customer selects a price plan (in the device profile definition wizard )that includes also these services (Developer, Daily, Flex, Freedom); therefore the services can be used IMMEDIATELY after the bootstrap. In case the customer, during device profile creation, selects a price plan that does not include the above services, they can be anyway activated in a later stage by going in the Thingstream portal and associate a different price plan to the Security thing. In this case, as for feature activation, the services will be enabled at the next Security Heartbeat.
For a complete description on how to use feature and services, refer to the Application note document
Anti-cloning detection and rejection
The anti-cloning detection system detects devices that appear to be using the same RoT and will allow only the first device that communicates to bootstrap with the service. All subsequent calls from any other devices using the same RoT (cloned devices) are automatically blocked by the service.
You can refer to the following APIs or using the 'Event' section of the Thingstream portal to verify if any clone has been detected.
Tools and sample code
To test the APIs and the AT commands to interact with the module, visit the Tools and Software page.
You can also refer to the u-blox GitHub repository which is constantly updated with sample code to simplify the service implementation and reduce your time-to-market.
If you need more help or have any questions, please send an email to firstname.lastname@example.org .