A Closer Look at the SARA-R5’s End-to-End Security

u-blox’s recently introduced SARA-R5 series of LTE-M and NB-IoT modules for low power wide area (LPWA) IoT applications is its most advanced, secure and highly integrated cellular product. The module offers end-to-end security and is ideal for IoT applications with long term device deployments.

End-to-end security has become more important with the advent of the IoT, which has many input/output points and include many devices that are deployed in the field. With connected sensors exchanging data with servers across many layers of networks (e.g., local area networks, cellular networks and Internet service providers), there are numerous entry points through which a “bad actor” might gain access to the entire system.

To prevent the theft of personal data, hijacking of a connected device, and other security hazards, solutions need to authenticate the user, securely store personal data, validate transactions and guarantee that user safety is not compromised.

At a minimum end-to-end IoT security involves:
•    Device integrity. Mutual authentication between devices and servers.
•    Message integrity. Messages sent between devices and servers are sent safely so that they can’t be altered or changed.
•    Message confidentiality. Messages should be coded so only parties authorized to receive them can read them.

As stated by Andreas Thiel, Head of Product Centers at u-blox, “By integrating a hardware-based Root of Trust in a discrete secure element within the UBX-R5 chipset, we are paving the way for robust secure communication from the chip all the way to the cloud. The secure element is compliant with EAL5+ High common criteria certification, which makes SARA-R5 ideally suited to protect sensitive assets and communications.”

Andreas Thiel’s comments include  phrases in bold (that I emphasized) that may seem straightforward and yet are more profound than most lay people not involved in IoT security suspect. Let me take a few minutes, now and try to more precisely define these terms.
 
Root of Trust (RoT) is a kept secret that will not compromise the security of the overall system. It includes a safe place for system-critical secrets, secure processes and extended trust to internal and external entities. Roots of Trust are functions that must operate as expected, irrespective of any other process because without them there is no way to believe (or trust) anything reported by a platform.

The building blocks of a Root of Trust have general requirements. A lot of them:
•    It must perform one or more proven cryptographic functions.
•    It must have a form of tamper protection.
•    Its secure CPU must run secure software/firmware. Code from the outside needs to be validated prior to running it on the secure CPU. This can be implemented for example, by using a dedicated ROM that can only be accessed by the Root of Trust.
•    Includes a secure clock for applications that require a reliable time measurement.
•    Its storage must be secure.
•    Secure communication becomes available after successfully completing an authentication and key exchange protocol.
•    Secure monitoring is available during power up and runtime operation of the SoC to ensure that the components as well as the interactions of the components are functioning properly. Any attempt to insert malicious instruction should result in a notification from the Root of Trust back to the host.  
•    A Root of Trust must work properly no matter what software is executing, in order to be immune to software attacks.

Secure elements can be viewed as the physical embodiment of the RoT. A secure element is able to perform crypto-functions such as encryption, decryption, true random number generation and verification. It must be very robust against physical attacks and can be neither read nor counterfeited. It comes programmed and personalized with unique IDs and secret keys so it can interface with its host MCU. The most secure way to embed a RoT within a device is to place it within a hardware-based secure element, as is the case with the SARA-R5.

SARA-R5 modules also offer a pre-shared key (PSK) management system. In cryptography, a PSK is shared between two parties using some secure channel before it needs to be used. The characteristics of this key are determined by the system which uses it. PSKs must also be long and random to be secure. Short or predictable pre-shared keys can be easily broken in brute-force attacks. Administrators must also remember to renew the PSK periodically to maintain a high level of security.

Key management keeps the secret key material inside the hardware Root of Trust. The Key management system keeps the secret key material inside the Root of Trust and is also able to derive the same PSK on the server side when required. Only indirect access to these keys is allowed and is managed by permissions and policies on the application layer.

Common Criteria. A chip’s unique serial number, MAC address, device address, private and public key pair create its “identity,” which is assembled into one identity document, the device’s “certificate,” which is signed by a trusted certification authority such as meeting the Common Criteria for Information Technology Security Evaluation (CC), a driving force for mutual recognition of secure IT products. CC and the companion Common Methodology for Information Technology Security Evaluation (CEM) are the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA).

SARA-R5 modules are well-suited for devices that transmit critical and confidential information. Thanks to a discrete, hardware-based secure element and a lightweight pre-shared key management system, u-blox offers state-of-the-art security that is ideal for IoT applications and includes data encryption and decryption, anti-cloning, and secure chip-to-chip communication.

Learn more about security at u-blox.