Embedded Files
Introduction
For today’s cloud-based information technology environment, it is vital to secure all data from unauthorized or fraudulent access. For IoT devices the security of data is vital to protect both businesses and the individual user / person.
For example:
In connected retail a POS terminal must protect revenue flow from fraud by:
Securely controlling access to the payment terminal.
By providing payment data to authorized parties only.
In asset tracking the data must be authenticated to the correct device to ensure the integrity of the business process and its control.
In order to protect recurring service revenues, smart devices in buildings must ensure that only authorized technicians can remotely access and troubleshoot building management functions.
IoT devices connect physical objects to provide data traffic and access to networks – however the physical objects (i.e. medical devices, controls, utility meters, vehicles, etc.) and the network of things must also be secured. A weak element in IoT security (also known as a defect or vulnerability) may ultimately also become a safety issue.
The u-blox device security implementation is designed to entirely remove these weak elements and prevent the unauthorized or fraudulent access to the underlying data.
The following definitions will help in understanding the fundamentals of security:
Integrity ensures that pieces of data have not been altered from a reference or controlled version.
Authentication ensures that a given entity (with which the user is interacting) is the expected one.
Authenticity is a special type of integrity, where the reference or controlled version is defined as exactly the state of the data when it was under the control of a specific entity.
Confidentiality means that no unauthorized access to the data is allowed (that is, encryption or cryptography will be used).
This section
Related Information
Security Services API documentation
Still need help?
If you need more help or have any questions, please send an email to services-support@u-blox.com.
Foundations of u-blox security
The strengths of the u-blox security service include the following:
Unique device identity: An immutable chip ID together with a robust root of trust provide the foundational security.
Secure boot sequence and update processes: Only authenticated and authorized firmware and updates can run on the device.
Hardware-backed crypto functions: A secure client library generates the keys and cryptographic functions to securely connect to the cloud.
Root of trust-based authentication: Using the protected root of trust and unique session keys ensures the integrity and confidentiality of both the communications and the data-at-rest (i.e. inactive data that is stored physically in any digital form).
The following features maintain the integrity of the device over its entire lifecycle.
Secure boot
Secure boot maintains the integrity of the code running on the module to ensure the device only runs trusted software issued by an authorized manufacturer.
Because the authenticity and integrity of the software is secured, the module is suitable to be used in mission critical solutions and enables highly secured devices.
Secure updates
Secure updates performed via FOTA or uFOTA (see the FW update application note [5]) allow the customer’s chosen FOTA platform to remotely and securely update the module’s firmware. Updates are signed by u-blox and verified before being applied. The resulting updated firmware is then authenticated in the module via the secure boot process.
uFOTA is a comprehensive end-to‑end u-blox FOTA service that allows customers control of the process for remotely updating the module’s firmware “over‑the-air”. This process utilizes the additional security provided between the module and the service via PSK provisioning.
uFOTA enables the updating of the module firmware at no extra data overhead and cost of implementing such services and processes, since they are implemented by u-blox.
Secure production
Secure production is undertaken with a significant emphasis on security, using well designed processes and methods. The root of trust (RoT) is securely provisioned with personalization data (using several keys). The personalization data is delivered using multiple layers of encryption to protect it during the end-to-end process. Each layer of encryption is only retrieved at the correct stage in the process, with the final layer only being retrieved within the module RoT itself.
As mentioned, the benefit for customers is that the module can be used in mission critical solutions and enables highly secured devices.
Root of trust
The root of trust (RoT) can always be trusted within a cryptographic system by providing a comprehensive set of advanced security tools including:
The secure execution of user applications.
Tamper detection and protection.
Secure storage and handling of keys and security assets.
Resistance to side-channel attacks.
In SARA-R4 and LARA-R6 products the RoT is implemented in a trusted execution environment (TEE) and is a critical component of the system.
A TEE is a secure area inside the main processor (trusted OS area), which is physically separated from the rich OS (rich execution environment, REE) where applications are running. It protects the confidentiality and integrity of the code and the data loaded into the TEE. It provides an excellent level of robustness that is sufficient for the majority of IoT applications. A RoT implemented in the TEE provides a better level of robustness compared to classic systems, which only implement security in the REE.
In SARA-R5 products the RoT is integrated in a secure element (SE).
A secure element is a dedicated microprocessor chip which stores sensitive data and runs secure applications. It acts as a vault, protecting what’s inside the SE (applications and data) from malware attacks that are typical in the host (i.e., the device operating system). This secure element is Common Criteria certified EAL5+ and it allows to have eUICC on SARA-R5 since the GSMA and mobile network operators require at least EAL4 to host an eSIM.
LARA-R6, SARA-R4 "63B", “73B”,”83B” product versions implement the RoT in the TEE.
SARA-R5 products implement the RoT in the Secure Element.
The IoT device is secured using the following steps:
Provision trust – insert the root of trust at production: An immutable chip ID and the hardware‑based root of trust inserted during the production process provide the foundational security and a unique device identity.
Leverage trust – derive the trusted keys: Secure libraries and hardware-supported crypto functions allow the generation of keys that securely connect the device to the cloud.
Guarantee trust – use secure keys to secure any function: Secure keys ensure the authenticity, integrity, and confidentiality to maintain control of the device and the data.
Next topic: Getting started guide
Report abuse