May 23, 2019
Qualcomm products mentioned within this post are offered by Qualcomm Technologies, Inc. and/or its subsidiaries.
Building the Foundation
With billions of "things" becoming connected in the era of IoT, security is a significant issue and remains a top concern for many customers. This in turn becomes a tough challenge for developers to overcome within their own solutions; therefore, IoT security should strive to fulfill the following requirements:
Provide user authentication
Ensure the integrity of software
Protect data both on storage and during transit
Protect lifecycle management functions, and
Perform device-cloud attestation
In a recent QTI blog Why Qualcomm is uniquely positioned to be a leader in IoT security, we identified four common security threats to IoT devices that can undermine these requirements:
Today, thanks to the efforts of platform and device manufacturers, such threats can be combated with built-in hardware-based security mechanisms that work behind the scenes to augment the efforts of developers. Such mechanisms can be found on our IoT solutions like the Qualcomm® Snapdragon™ Mobile Platform, and form a hardware security foundation as seen in the image below:
The key aspects of these foundations are as follows:
Trusted Execution Environment: Supports secure execution of sensitive code including trusted application support. This trusted environment also supports digital rights management (DRM), trusted peripherals, biometrics, trusted storage, and more.
Wireless Protocol Security: Various wireless protocols are supported to help secure data in transit through communications channels such as Wi-Fi and Bluetooth.
Secure Boot: Provides authentication and integrity checking of code running on a device to prevent unauthorized code execution. A root of trust is established in hardware features including ROM and e-fuses.
Storage Security and Key Provisioning: Provides hardware acceleration for encryption of data stored on the device and the ability to provision keys with a hardware root of trust.
Debug Security: Provides debug functionality that can be disabled by OEMs once the product is shipped, while allowing OEMs to re-enable security functionality for RMAs.
Hardware Crypto: Provides FIPS certifiable hardware-based cryptography and support for encryption methods such as SHA1, SHA2, RSA, and ECC.
Collectively, these foundations can help thwart a wide range threats and attacks, and developers should look for evidence of these types of foundations when evaluating IoT hardware.
But just as important, developers should have a clear understanding of the type of threats that pose a risk to IoT devices and applications, so let's take a closer look at those four common security threats.
1. Code Modification
Code modification involves installing or "injecting" unauthorized software onto a device, and when this happens, that software can wreak havoc. Code modification is a particularly inherent threat to the software integrity and lifecycle management of an IoT device.
Two traditional strategies for dealing with code modification are:
Signature-based Detection: Looking for the known identity or signature of unauthorized software, often with the ability to stop it pre-emptively; and
Behavior-based Detection: Operations are monitored for abnormal behavior. In this case, developers and/or the hardware can alert the user and/or remove the malicious process that is causing the abnormal behavior.
One tactic that is often effective is to authenticate firmware images. This can be done during boot image loading using a multi-stage boot process, that begins with an immutable primary bootloader in ROM. With such a mechanism, developers can enforce the cryptographic authentication of all code images, validate the integrity of the code against load-time attacks, and optionally validate the integrity of OEM code against load-time attacks. The purpose is to ensure that only the developer's image(s) run on the device. This can also provide the option for anti-rollback and anti-replay protection.
2. Key Compromise
Encryption is commonly used to secure data for both communications and storage, but developers should think about securing the very thing that makes encryption secure: the encryption key itself. When a key for an IoT device becomes compromised, this can open up access to stored and transmitted data, and affect lifecycle management.
Generally, keys should be stored in a secure storage environment. Developers may also want to employ one-time-passwords, and use secure filesystems when possible.
3. Password Compromise
When it comes to gaining unauthorized access to a system, compromising a password by guessing or stealing it, or through the use of brute force methods, are arguably some of the oldest tricks in the attacker's handbook. It goes without saying that password compromise on IoT devices can have devasting effects.
Developers have long dealt with password compromise through methods like strong password enforcement, secure communications channels, multi-factor authentication, temporary password vaults/one-time passwords, and limiting password attempts. These approaches can be further augmented by encrypting passwords using a hardware root of trust, taking advantage of secure storage, and employing new types of authentication methods such as fingerprint detection, voice activation, facial recognition, and eye scanning.
4. Man-in-the-Middle Attack (MITM)
Any time there is a communications channel, there is the potential for unauthorized entities to insert themselves in the middle to intercept communications. Under this type of attack, the legitimate parties think they are communicating with each other, when in fact the attacker has secretly made independent connections with both parties, and relays the messages between them.
One of the most important aspects of thwarting MITM attacks is to somehow guarantee that both parties are in fact talking to each other, and not through a middle man. This can be done through a variety of methods, but the goal is to ensure that the endpoints are who they say they are.
One approach is through authentication and attestation both at the hardware and software level. For starters, Wi-Fi networks should be secured during provisioning to prevent network-level eavesdropping. In addition, the communication protocols employed, should support endpoint authentication at various levels in the stack.
For devices, on-demand hardware-based security tokens can be used. These tokens are analyzed by online risk engines which send the device's hardware attestation to backend services to validate system integrity, physical location, and the device's health state. This secure reporting can include dozens of differentiable, hard-to-get device parameters.
A similar approach can be used for user authentication, such as in IoT devices that require some type of user access. Here, a user could authenticate to the device and then the device authenticates and attests itself to the backend as illustrated here:
These approaches can be augmented with secure private networks, employing authorization technologies such as OAuth, encrypting data, and integrating with trusted cloud providers. In addition, device SDKs often support, and ideally include, implementations of secure communication protocol stacks such as SSL.
Another Surface to Attack
Each type of threat deserves careful consideration when designing or choosing IoT devices and software, and when utilizing third-party components like gateways, cloud-services and even the Internet itself.
Collectively, these components, vulnerabilities, and threats form an attack surface which becomes magnified by billions of connected things. Thankfully there are numerous approaches in thwarting them. So, whether the mechanism to combat a threat happens automatically in hardware or is implemented by a developer, it's important to know what threats exist and what approaches are at your disposal.
Now that you know about more about the types of threats and strategies for thwarting them, let us know which hardware-level security features you would use to protect your both your IoT devices and users.
ALL QUALCOMM TECHNOLOGIES, INC. PRODUCT INFORMATION, DESIGN SPECIFICATIONS, FILES, DRAWINGS, AND OTHER DOCUMENTS (TOGETHER AND SEPARATELY, "MATERIALS") ARE BEING PROVIDED "AS IS." QUALCOMM TECHNOLOGIES, INC. MAKES NO WARRANTIES, EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE WITH RESPECT TO THE MATERIALS, AND ALL EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OR CONDITION OF TITLE, MERCHANTABILITY, SATISFACTORY QUALITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT, ARE HEREBY EXCLUDED TO THE MAXIMUM EXTENT PERMITTED BY LAW.