Recently launched by u-blox, the SARA-R5 series of LTE-M and NB-IoT modules for low power wide area (LPWA) IoT applications is their most advanced, secure and highly integrated mobile product. The module provides end-to-end security. This makes it ideal for IoT applications with long-term device implementations.
End-to-end security has gained in importance with the advent of IoT. It has numerous input and output points and includes many devices that are used in the field. By sharing data between networked sensors with servers across multiple network levels (eg, local area networks, mobile networks, and Internet service providers), there are numerous entry points that allow someone with bad intentions access to the overall system.
To prevent the theft of personal information, hijacking a networked device, and other security threats, solutions must authenticate users, securely store personal information, validate transactions, and ensure that user security is not compromised.
Minimum end-to-end IoT security includes:
• Device integrity Mutual authentication between devices and servers.
• Message Integrity Messages sent between devices and servers are securely transmitted so that they can not be modified or changed.
• Confidentiality of messages Messages should be coded so that only the persons authorized to receive them can read them.
Andreas Thiel, Head of Product Centers at u-blox, explains: "By integrating a hardware-based trust anchor into a discrete secure element within the UBX-R5 chipset, we pave the way for robust and secure communication from the chip to the core Cloud. The Secure Element complies with EAL5 + High Common Criteria certification , making SARA-R5 perfect for protecting sensitive goods and communications."
The comments by Andreas Thiel contain awards in bold (mine), which sound simple and yet have more profound effects than most people who are not familiar with IoT security would suspect. That's why I want to try to define these terms more precisely.
An anchor of trust(RoT, Root of Trust) consists of secret information that ensures that the security of the entire system is not compromised. This includes a secure location for system-critical secrets, secure processes and increased trust in internal and external units. Trust anchors are functions that must work as expected, independently of any other process, because without them there is no way to believe (or trust) what is reported by a platform.
There are general requirements for the building blocks of a trust anchor. For many of them:
• You must have at least one proven cryptographic feature.
• They must be protected against manipulation.
• Your secure CPU must be running secure software / firmware. External code must be validated before running on the secure CPU. This can be realized, for example, by using a special ROM that only the trust anchor can access.
• They include a secure clock for applications that require reliable timing.
• Your storage must be safe.
• Secure communication becomes possible upon successful completion of an authentication and key exchange protocol.
• Safe monitoring is available during startup and runtime operation of the SoC. This ensures that the components and the interactions between the components function properly. Any attempt to insert malicious statements should result in notification of the trust anchor back to the host.
• A trust anchor must function properly, regardless of the software running, to be immune to software attacks.
Secure Elements can be considered as a physical embodiment of the trust anchor. A secure element is capable of performing cryptographic functions such as encryption, decryption, true random number generation, and verification. It must be very robust against physical attacks and must be neither readable nor manipulatable. It is pre-programmed and pre-personalized with unique IDs and secret keys so that it can be connected to its host MCU. The safest way to integrate a trust anchor into a device is to place it in a hardware-based secure element, as is the case with SARA-R5.
SARA-R5 modules also provide a pre-shared key (PSK) management system. In cryptography, a PSK is shared by two parties over a secure channel, before it is to be used. The properties of this key are determined by the system that uses it. For PSKs to be secure, they must also be long and random. Short or predictable pre-shared keys can be easily determined during brute-force attacks. Administrators also need to remember to regularly renew the PSK to maintain a high level of security.
The key management retains the secret key data in the hardware trust anchor. The key management system stores the data of the secret key in the trust anchor and, if necessary, can also derive the same PSK on the server side. Only indirect access to these keys is allowed and managed by application-level permissions and policies.
Common Criteria - The unique serial number, MAC address, device address, private and public key of a chip form its "identity", which is summarized into an identity document, the "certificate" of the device. The certificate is signed by a trusted certification authority, such as the Common Criteria for Information Technology Security Evaluation (CC), a driving force for the mutual recognition of secure IT products. CC and the associated Common Methodology for Information Technology Security Evaluation (CEM) form the technical basis for an international agreement, the Common Criteria Recognition Arrangement (CCRA).
SARA-R5 modules are ideal for devices that transmit critical and confidential information. With a discrete, hardware-based secure element and a lightweight pre-shared key management system, u-blox offers state-of-the-art security ideal for IoT applications, data encryption and decryption, anti-cloning and secure chip-to-peer Chip communication includes.
Find out more about security at u-blox.
Guest blog written by Murray Slovick, Editorial Director and Principal of Intelligent TechContent.