As more IoT devices are deployed, security is growing in importance. Security can be a scary topic on many levels. For example, news of someone hacking a baby monitor is not only frightening for the consumer, but also for companies making these devices, as the resulting exposure and liability can hurt their business.

IoT security is not an add-on function—it starts at the SoC level. If you think of securing your SoC like securing your home, it helps clarify what protections are needed. A home has entry points, like doors and windows, that need locks; the same is true for your SoC. In both homes and SoCs, security measures, such as alarms, can alert you to potential threats, and these security measures have associated costs.

Three basic principles of security should be considered when architecting SoC security for a connected device: confidentiality, integrity, and authenticity. You want to ensure that data is protected if it falls into the wrong hands; that data or device functionality have not been tampered with; and that access to data and the ability to make software changes, are restricted.

One of the best home security measures is also one that most people don’t think of as security: curtains. Obscuring what you have provides less of a temptation to thieves, because without knowing what they’ll get, they don’t know if it’s worth their time and effort to break in. IoT devices are connected, making sending or storing sensitive data one of the big security concerns for IoT edge node devices. Encryption is one of the baseline functions required from IoT SoCs to obfuscate the sensitive data. Encryption standards, such as AES, can be implemented in a few different ways and each has tradeoffs that should be considered when architecting an IoT system.

You can, of course, use a standalone encryption block that performs the function, but you pay the penalty in area and may have trouble meeting cost goals. Running a software algorithm on your processor is also an option, but it could be too slow or use too much energy for your budget. A third possibility is to use the processor already in your system to run the encryption software and include hardware extensions to accelerate cryptographic functions.

An example of this implementation is Synopsys’ DesignWare ARC CryptoPack option for ARC EM processors which uses ARC APEX technology to add custom instructions and registers to accelerate standards such as AES or SHA. This option maintains the flexibility of changing algorithms while delivering significant performance improvements (up to 7X with the ARC CryptoPack option). At a 5-10% increase in processor gate count, it’s still an order of magnitude smaller in area than a full hardware approach. Figure 1 shows an example comparison between using CryptoPack to accelerate AES versus using a software-only or hardware-only approach.

1. Comparison of AES implementations.

Another common function of cryptography is to ensure the integrity of the data that’s been stored or transmitted. Hashing algorithms such as SHA-2 are often used for this purpose. Similar to AES encryption, the SHA function can also be performed in multiple ways. Figure 2 shows the energy benefits that can be achieved by accelerating the software algorithm with CryptoPack.

2. Energy comparison for accelerating a common hash algorithm.

Another parallel to home security is the concept of access permission. In the home, door locks permit access and can come in multiple forms. The most traditional approach to a door lock is a key; to gain entry to the home, the person must possess a key that matches the lock on the door. However, keys can be lost or duplicated, and the mechanism itself can be tampered with. To solve this problem, other methods have emerged that are more secure and convenient, including code locks, biometric locks, and locks controlled by your cell phone.

When IoT edge nodes talk to each other or to a server, it’s important for the other end to know who has permission to send or receive data. This is called authentication. Exchanging keys is one method for authentication; if you have the key, you’ll then have access to the encrypted data.

There are some drawbacks with this approach. There must be a secure way to transfer the keys initially. In addition, the key can also be compromised if there isn’t a secure enough way to store it. Another authentication method is based on some unique property of the device, a digital fingerprint, if you will. Physically unclonable function (PUF) technology can be used to create a unique identifier for a processor and, by extension, the IoT edge node device that it’s in.

Intrinsic-ID and Synopsys ARC teams have collaborated to offer a small footprint PUF solution that’s protected by ARC SecureShield technology and accelerated by CryptoPack. This solution for authentication is well suited for IoT edge nodes because it’s a firmware-only approach, and lightweight with small code size and processing horsepower requirements.

Imagine a thief who doesn’t have the key, the code, or the fingerprint to get into the house, but still believes that there’s something worth stealing inside. He’ll wait till no one is around and start tampering with locks or looking for other ways to get in. The same is true of a hacker, and that’s where alarms come in. One example of an alarm you can implement for processor security includes a watchdog timer that detects system failures and enables countermeasures. Another example is data- and instruction-path integrity checking, a mode that detects errors that could result from tampering and puts the processor in secure mode to prevent any user interference with operation of the device. This will prevent a hacker from trying to figure out how to bypass access privileges by detecting what happens when the wrong key is used or incorrect code is entered and intentionally forcing the opposite response.

Another way to gain access is to ride along with someone who already has access. In a home, that might be someone coming in with a plumber or contractor. In the case of a processor, it might be malware with a downloaded application. This is where a trusted execution environment comes in handy, as it enables the separation of non-trusted applications from processing of secure code. This lets you share system resources for secure code and user code, eliminating the need for a completely separate secure processor and memory, especially important when you have stringent area and energy budgets, as is the case with IoT edge node devices.

Building on that trusted starting point, a processor can securely boot, load, and verify application software before starting to execute it. Figure 3 is an example of a trusted execution environment on an ultra-low power core enabled by ARC SecureShield technology. In this example, the processor uses multiple privilege levels of access control, a bus state signal denoting whether the processor is in a secure mode, and a memory protection unit that can allocate and protect memory regions based on the privilege level to separate the trusted and non-trusted worlds. Also, another unique feature is that each memory region can be scrambled or encrypted independently, offering an additional layer of protection.

3. Trusted Execution Environment using ARC SecureShield technology.

Although protecting the platform from attacks that can take down the IoT edge device and network is very important, there’s also concern about protecting proprietary software from IP theft. It’s important to consider these factors when choosing a processor solution for the SoC. Synopsys’ Enhanced Security Package for ARC EM processors provides the ability to encrypt and decrypt instructions in a way that they aren’t accessible to a potential IP thief.

The higher the value of what you’re trying to protect, the more incentivized someone is to get to it, and thus, the more security measures you need. There’s no perfect solution to prevent all attacks and not every house can be guarded like Fort Knox, but it shouldn’t stop you from locking your doors and windows and setting your alarms to make the thief’s job harder.

Angela Raucher is the product line manager for Synopsys’ ARC EM processors. She has over 20 years of experience in the semiconductor industry and has held a number of leadership positions in product line management, technical support, software development, and marketing across embedded processing and mixed-signal semiconductor businesses serving consumer, industrial, communications, and automotive markets. Angela holds a Bachelor of Science degree in Electrical Engineering from Virginia Tech.