Risk vs. Reward – a tradeoff that factors into every business decision. In November of 2016 the U.S. Department of Homeland Security issued “Strategic Principles for Securing the Internet of Things,” which commented on the risk-reward tradeoff wrought by the IoT. Specifically, the document set out to provide a set of principles and best practices for addressing the risks resulting from the widening gap between the IoT’s rapid expansion and its slower-growing security.
One element among the document’s recommendations is the use of hardware to incorporate security, recommending the use of computer chips that integrate security in the microprocessor to provide encryption and anonymity.
How best to accomplish this? Let’s look at a couple approaches and consider their advantages and disadvantages.
Secure Element
One approach is the use of a secure element, a standalone security chip with secret keys programmed on it. Typical applications of secure elements to secure IoT devices usually involve a microprocessor accompanied by a discrete secure element chip. In that context the addition of the chip would seem to solve most of the security problem.
While adding a secure element can do a reasonably good job of bringing pre-provisioned keys and protecting those keys, it leaves some complications unaddressed. In such a scenario we are still left with a CPU or MCU which talks to that secure element. So the rest of the system, to use the keys on the secure element, has to talk to that chip to do operations with the keys.
But now we’ve arrived at the problem: The channel to the secure SoC is not protected by the secure element.
Using a secure element does not address security for the connection between the microprocessor and the secure element. Despite the chip encrypting data, the actual connection between the chip and the source of that data is not protected – it’s electrically exposed. The extent to which the secure element is secure becomes irrelevant because the device is still vulnerable to physical and side-channel attacks on the device. It’s like putting a safe door on a tent – adversaries won’t bother trying to break open the door, they’ll just slice open the fabric wall.
Hardware-Based security Via Software
The thing is, you don’t need to add actual hardware to achieve hardware-based security, as long as a root of trust is established. For a root of trust to be trusted it must be secure by design and ideally implemented in hardware, or protected by hardware. It is relied up on to perform security-critical functions, such as protecting cryptographic keys or performing device authentication.
An alternative to the secure element approach is a root of trust achieved via software. This is can be accomplished through the use of an SRAM Physical Unclonable Function (SRAM PUF). Think of a PUF as a semiconductor’s fingerprint – powering up a chip yields an electrical pattern based on the unique physical properties inherent in every semiconductor. SRAM PUFs are used to create private-public key pairs specific to a single device; when queried with a challenge, the PUF generates a response dependent on the physical properties of the underlying PUF hardware.
Because SRAM PUF is rooted in hardware and is actually firmly attached to the SRAM of the device, it represents security rooted in hardware. Because it cannot simply be removed and used on another device, it utilizes unpredictability to provide hardware-specific security that an adversary cannot readily exploit.
The Use Case Prevails
As with most decisions, the choice isn’t always obvious. When weighing which approach to take in adding security to an IoT device, multiple considerations can come into play. For example, an application involving a retinal scanner requires the data about the fingerprint to be securely contained. A secure element could hold the private key and the sensor could encrypt the biometric data so only the secure element could read it and make the comparison inside. That way it can store, and be the only thing that understands, the data. But as soon as security decisions are distributed outside the secure element you end up with a situation that is not secure.
Economics and Flexibility
And in security, as in most business decisions, economics and flexibility come into play. For certain simpler applications – think of key fobs to open doors – secure elements can make good sense, at least in terms of up-front costs. But the full costs of implementation, such as software porting and board manufacturing, need to be considered to see how they change the total cost of a product’s bill of materials.
For instance, a device maker producing units in low volume might not care how much the secure element costs, and that approach indeed might be appropriate. But if that product becomes a big success and production has to scale all of a sudden, that bill of materials takes on a different – negative – complexion if it’s wedded to use of a secure element.
In the end, IoT security choices need to consider not just the cost of security but its value. No one wants to rely on that tent fabric to protect something that should have been stored in a safe.
About the author: Anton Sabev is Principal System Security Architect at Intrinsic ID and has extensive experience in cryptography, computer security and embedded digital signal processing. Prior experience includes positions with Intel, LSI Logic and ST Microelectronics. He is also a licensed pilot and conducts pilot training. Find Intrinsic ID on the web at Intrinsic-ID.com
Edited by
Ken Briodagh
