How u-blox SARA-R5 advanced security makes a difference

IoT is a promising business enabler for the industry, and consumer IoT applications like home automation or the “quantified-self” movement (e.g., fitness tracker) are generating a lot of positive public attention.

But IoT also has a big social impact as IoT is replacing human labor by automated machine-to-machine processes; this evolution is eyed suspiciously by parts of the society. In addition, adoption of IoT approaches raises privacy concerns about a potential disclosure of private information. A data leakage would allow unknown parties to misuse this sensitive data and to elaborate user profiles containing individual preferences, movement habits, etc. These risks are asking for governmental action, leading to enforced privacy protection laws all over the world. According to European GDPR (“General Data Protection Regulation”) and others, IoT solution providers will have to protect user data accordingly, otherwise they will be in trouble.

Besides citizen rights, also risks of financial loss caused by cybercrime is addressed by national governments, e.g., by recent Cybersecurity Acts in the US and in the EU which are accompanied by requirement specs for IoT devices (e.g., NISTIR 8259A) asking for implementation of strong authentication, data encryption, secure firmware update, etc. For governmental business and for supervised projects (e.g., for smart meters in Germany), strict security requirements are already in place. As evidence for proper implementation, each product as well as manufacturing processes will have to undergo a security evaluation by an accredited lab, typically according to Common Criteria (CC) rules.

Consequences of a successful cyberattack are not always obvious. For example, a tampered smart meter would report wrong consumption data or confuse allocation of bills, so the fraud potential and financial damage is clear in this case. But for many other IoT applications, a decent risk analysis would be required to determine, which threads potentially apply, who are potential attackers and which kind of damage might occur. What would it mean if somebody is able to clone a device or modify IoT data on its way to the cloud? What would be the cost of failure, e.g., if somebody can take an IoT device out of service? Even if a successful attack would not cause immediate financial damage, it might decrease the company’s reputation or users might just step away and avoid using this IoT application.

In fact, IoT customers and user are expecting stable and trustworthy IoT systems. The magic word is “Trust”. Trust means user confidence that an IoT application works reliably and handles personal and confidential data responsibly. Solution providers can use IoT security techniques to build this kind of user confidence. For this purpose, a IoT provider must provide evidence about his dedication and expertise in this particular field.

For IoT solution designers who understand the value of strong IoT security, the u-blox SARA-R5 is a good choice. The extra strength is based on the fact, that the SARA-R5 utilizes an additional hardware component for secure storage and as a secure processing environment. This chip is a so-called secure element (SE) which is derived from smartcard technology and certified with CC EAL5+. The SE works as a security companion for the SARA-R5 MCU respectively its integrated software stack for secure end-to-end communication through the internet.

Root-of-Trust, SE secure processing environment and u-blox cloud support

The idea is to use the u-blox SARA-R5 module as a Root-of-Trust (RoT) of the IoT device. The SARA-R5 RoT contains an immutable device identity including associated cryptographic keys which are allowing for strong authentication of the device within the IoT communication network. But it is also used as a trust anchor for secure boot and secure device management like secure firmware updates or re-provisioning via cloud-based IoT-Security-as-a-Service. Although the device identity is assigned only once and remains unchanged during its lifetime, public-key certificates – issued by a trusted authority (CA) and managed within a dedicated public-key infrastructure (PKI) – are required to ensure device recognition within the IoT network. Continuous management of these certificates during the device lifecycle (add, revoke, renew, change CA) including automatic device update (provisioning) is necessary and offered by u-blox as an extra cloud-based PKI service for SARA-R5 and other secure network interface modules. The Same Certificate Lifecycle Control service is also used to prepare a device for onboarding to popular IoT clouds like AWS or Azure.

PKI-based device authentication is a scalable and well-recognized approach, but for establishing a secure internet connection between two parties within a large IoT network, mutual agreement of a data encryption key might be a major concern - especially for battery-driven devices or in case that a low-bandwidth IoT network is being used. As an alternative, u-blox is offering an efficient approach which is based on a symmetric pre-shared key (PSK) and does not require any public-key computations on constrained IoT devices when using the common TLS protocol. Instead, the PSK is derived from the unique RoT of the IoT device and securely provided to the customer IoT cloud by a service option called End-to-End Symmetric KMS.

In general, the u-blox RoT approach relies on a secure area within the IoT device where critical parts of the operating system and security functions including all secret keys and other security assets are stored and executed. This trusted execution environment (TEE) is strictly isolated from the rich execution environment (REE) where embedded applications are running. Security operations include symmetric and public-key encryption/decryption, hash calculations, generation of random numbers and derivation of session keys whereas all used secrets are kept exclusively within this protected area. This approach is implemented also in other u-blox products, but only for SARA-R5 products the RoT resides in an extra SE component. Compared with other “trusted execution environments (TEE)” the SE is offering excellent crypto performance, high-quality random numbers and an extra level of hardware-backed tamper detection and protection, e.g., sensors or physical measures against invasive attacks like micro-probing. On top of this, only SEs offer ultimate resistance against non-invasive physical tamper attempts like side-channel attacks or malicious fault-injections.

Resistance against SCA and FI attacks

SCA and FI attacks are mainly used to exploit vulnerabilities of an IoT device, rather than for operational attacks. These insights will be used by the attacker, e.g., to clone a device.

Physical fault-injection (FI) means to expose device components to extreme conditions beyond its specified limits, e.g., ambient temperature or power supply voltage. Intention is to change system behavior and/or output by a carefully targeted fault injection. A successful attack can modify the program behavior in different ways such as corrupting program state, corrupting memory content, stopping process execution (“stuck-at fault”), skipping instruction, modifying conditional jump, or providing unauthorized access. Typical threats involve tampering with clock (freezing or glitch) and supply power (under/over voltage or glitch). For example, a precisely timed clock glitch can be used to skip execution of a specific CPU instruction, e.g., a password verification.

Side-channel attacks (SCA) exploit information leakages of the system. Even if the system implementation allows authorized access only, a “side channel” might offer valuable insights to internal processes and used data. The leakages can be related to timing, power, electromagnetic signals, sound, light, etc. SCA is a non-invasive and passive attack. For cryptographic IoT devices, SCA is a popular approach to retrieve keys which are stored and executed internally. For this purpose, power analysis attacks can be used which are based on the fact that CPU power consumption depends on instructions and data being processed. Fundamentally, this is due to physical effects of how digital devices are built, i.e., changing the state of an internal digital line requires energy, i.e., power consumption slightly increases.

These variations can be observed where power is being applied to the device, i.e., its power supply pin. A standard oscilloscope can be used to measure power consumption of the device. On the other hand, it is public information how standard cryptographic algorithms like AES work. Although SCA attacks require some engineering background and equipment, commercial tools for “educational purposes” are available for support, e.g., how to retrieve an AES key from inside a hardware component, for example: https://www.newae.com/chipwhisperer.

Only secure elements can offer reliable protection against SCA and FI attacks, software countermeasures may help to some extent, but certainly cannot change semiconductor fundamentals. During a Common Criteria security evaluation of a secure element – at least for a level EAL5+ certification - an accredited test lab will verify effectiveness and strength of implemented SI and FI countermeasures using state-of-the-art lab equipment and skilled staff. For a CC EAL5+ evaluation, lab experts will perform a hands-on vulnerability analysis with highest attack potential.

Secure AT Command Channel

For operational protection of IoT data, another advanced SARA-R5 security feature is available: chip-to-chip pairing with the device MCU. Chip-to-chip is a mechanism to establish a secure communication channel between the MCU of the hosting IoT device and the module (SARA-R5) in an effort to protect AT commands and included data. Based on a shared pairing key, both parties are mutually authenticating each other and all AT commands, parameters and command outputs as well as all data are encrypted using symmetric AES cypher (128-bit key length).

 
Involved crypto keys are generated by the RoT (i.e., inside the SE) and shared with the host MCU. For key and session management, SARA-R5 offers a dedicated AT command +USECC2C. The initial pairing must be done once during device production, and the host MCU has to keep the pairing key internally in a safe place (i.e., hidden, and immutable). Later, a re-pairing process can be initiated by the host MCU at any time during a secure session, i.e., an existing pairing key can be securely replaced by a new one.

Learn more about the u-blox SARA-R5 by visiting our product page.