Part of the  

Chip Design Magazine


About  |  Contact



Security Issues in IoT

Gabe Moretti, Senior Editor

Security is one of the essential ingredients of the success of IoT architectures.  There are two major sides to security: data security and functional security.  Data security refers to the avoidance that data contained in a system is appropriated illegally.  Functional security refers to having a particular system function in a manner it was not intended to by an outside factor.  Architects must prepare for both eventualities when designing a system to foresee devise ways to intercept or isolate the system from such actors.

Data Protection

The major threat to data contained in a system is the always connected idea.  Many systems today are always connected to the internet, whether or not they need to be.  Connection to the internet is the default state for the vast majority of computing systems, whether or not what is being executed requires such connection.  For example, the system on which I am typing this article is connected to the internet while I am using Microsoft Word: it does not need to be, all I need is already installed or saved on the local system.  It is clear that we need to architect modems that connect when needed and that use “not connected” as the default state.  This will significantly diminish the opportunity for a attacking agent to upload malware or appropriate data stored on the system.  Firewalls are fine, but clearly they can be defeated, as demonstrated in many highly publicized cases.

Encryption is another useful tool for data protection.  Data stored in a system should always be encrypted.  Using the data locally should require dynamic decryption and encryption as the data is used locally or transmitted to another system.  The resulting execution overhead is a very small price to pay given the execution speed of modern systems.

I asked Lee Sun, Field Application Engineer at Kilopass Technology what his company is doing to insure security.  Here is what is said:

“Designers of chips for secure networks have begun to conclude that the antifuse one-time programmable (OTP) technology is one of the most secure embedded non-volatile memory (eNVM) technologies available today.  Antifuse OTP is a configurable on-chip memory implemented in standard CMOS logic with no additional masks or processing steps. Most importantly, antifuse OTP offers exceptional data protection because information stored in an antifuse bitcell provides virtually no evidence of the content inside. The bitcell does not store a charge, which means there’s no electrical state of the memory bit cell. The programming of the bitcell is beneath the gate oxide so the breakdown is not visible with SEM imaging. This protection at the physical layer prevents the antifuse eNVM from being hacked by invasive or semi-invasive attacks. Additional logic is available with the Kilopass IP to prevent passive attacks such as voltage tampering, glitching or differential power analysis. To date, there have been no reports of any successful attempts to extract the contents of an antifuse OTP using any of these techniques.”

Of course such level of protection comes at a price, but a large part of IoT systems do not need to store data locally.  For example, a home management system that controls temperature, lighting, intrusion prevention, food management and more, uses a number of computing devices that can be controlled by a central system.  Only the central node needs to have data protection and commands to the server nodes can be encrypted.
Robert Murphy, System Engineer at Cypress Semiconductor addressed the problem by using a secured processor or MCU.  He continued:

“These are general purpose or fixed function devices, used in applications such as home automation or mobile payment authentication. They provide Digital Security functions and are occasionally encapsulated in a package that offers Physical Security. Because various applications require different levels of security, the FIPS 140-2 standard was created to put security standards and requirements in place for hardware and software products. FIPS 140-2 provides third-party assurance of security claims, ranging from level 1 through level 4. Certification for systems can be obtained through test facilities that have been certified by the National Institute of Standards and Technology.

Securing data in the system is mostly accomplished through Digital Security, which includes a combination of cryptography and memory protection. Cryptography secures a system through confidentially, integrity, non-repudiation and authentication. Confidentially refers to keeping a message secret from all but authorized parties through the use of a cryptographic ciphers that employ the latest symmetric (secret-key) and asymmetric (public-key) standards.  Integrity ensures that a message has not been modified during transfer though the use of a hash function such as SHA. Non-repudiation is the process by which the recipient of a message is assured that the message came from the stated receiver, through the use of asymmetric encryption. Authentication provides confirmation that the message came from the expected sender. Authentication can be addressed using either a Message Authentication Code (MAC), which relies on symmetric encryption and provides message integrity; or digital signature, which relies on asymmetric encryption and provides both message integrity and non-repudiation. Attackers will attempt to circumvent cryptography through brute-force attacks or through side-channel attacks. Considering that Cryptography is centered around symmetric or asymmetric keys, protecting those keys from being altered or extracted is critical. This is where Secure MCUs utilize Physical Security and the detection methods described earlier. For added security, devices can incorporate a Physical Unclonable Function (PUF). These are circuits that rely on the uniqueness of the physical microarchitecture of a device that are inherent to the manufacturing process.  This uniqueness can then be applied to cryptographic functions, such as key generation.

Memory protection is comprised of several aspects, which work in layers. The first layer is JTAG and SWD access to the device. This is the mechanism used to program the device initially and if left exposed, can be used to reveal memory contents and other critical information. Therefore, it is important to disable/lockout this interface once deploying a system to production. A Secure MCU can permanently remove the interface through the use of Fuse bits, which are one-time programmable (OTP) memory where an unblown bit is represented by a logical value of zero and a blown bit is represented by a logic value of one.  The next layer is the Secure Boot Process. As discussed earlier, the Secure Boot consists of a Root-of-Trust that verifies the integrity of the device firmware, and can prevent uncertified firmware from having a chance to execute. Since the root of trust cannot be modified by firmware, it is immune to malicious firmware.  Next is Memory Protection Units (MPUs), which are hardware blocks in a device that are used to control access rights to areas of device memory. For example, using MPUs, a Secure MCU can limit access to crypto key storage. In the event an attack can circumvent the secure boot procedure or initiate a software attack through a communication interface, MPUs can limit the resources that the firmware has access to.

When employing any security solution, identify what needs to be secured and focus on that. Otherwise, you run the risk of creating a backdoor. By implementing these Digital Security functions, and layering it under a solid Physical Security solution, one can have a reasonable level of confidence that the data in the system is secured.”

Robert Gates, Chief Safety Officer ESD, at Mentor graphics described the data security requirements in automotive systems.

“Critical data in the automotive context will be handled in a similar way. A Trusted Execution Environment will be established to define and enforce policies for data that must be secured, which will apply to reading sensitive data, creating new sensitive data, and overwriting this data. This data will take on several forms; customer information such as financial and location information, as well as information that is managed by the manufacturer such as calibration settings and other forms of data.”

Inhibiting alien functionality

The collective security of a system requires that it uses the correct data and performs the required functions.  The first requirement is the one most often covered and understood by the public at large, but the second one is equally important with consequences just as negative.

Angela Raucher, Product Line Manager, ARC EM Processors at Synopsys summarized the problem and required solution this way: “With security there is no magic bullet, however taking care to include as many security features as is practical will help extend the amount of time and effort required by potential hackers to the point where it isn’t feasible for them to perform their attacks.”  Ms. Raucher continued: “One method to protect highly sensitive operations such as cryptography and generation of secret keys is to add a separate secure core, such as an ARC SEM security processor, with its own memory resources, that can perform operations in a tamper-resistant isolated environment (see figure 1).  The ARC SEM 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.  For the case of ARC SecureShield technology, there is also a unique feature enabling each memory region to be scrambled or encrypted independently, offering an additional layer of protection.”

Figure 1. Trusted Execution Environment using ARC SecureShield Technology

Robert Gates from Mentor takes the same direction and points out that “The root of trust starts with the microprocessor, which will generally have some kind of secure storage capabilities such as ARM® TrustZone or Intel Secure Guard Extensions (SGX). This secure storage, which is part of a trusted hardware component (an important topic in itself beyond the scope of the current discussion) contains the signature of a boot-loader (placed in secure storage by the device manufacturer) and the crypto key to be used to unlock and enable its operation; assuming these are as expected by the microprocessor, the second stage loader is allowed to execute, establishing it as a trusted component. A similar exchange occurs between the loader and the operating system on its boot-up (weather this is an RTOS or a more fully features OS like Linux or Android), establishing the kernel as a trusted component (Figure 2).”

Figure 2. ), establishing the kernel as a trusted component

Robert Murphy, System Engineer at Cypress points out that there are ways to steal information without executing code.  “Non-invasive attacks are the simplest and most inexpensive to perform; however, they often can be difficult to detect as they leave no tamper evidence. Side-channel attacks, the most common type, consist of Single Power Analysis (SPA), Differential Power Analysis (DPA) and Electromagnetic Analysis (EMA). SPA and DPA attacks are effective at determining information about general functionality or cryptographic functions, as the power consumed by a processor or MCU varies based on the operation being performed. For example, the squaring and multiplication operations of RSA encryption exhibit different power profiles and can be distinguished using an oscilloscope. Similarly, with EMA an attacker can reach the same outcome by studying the electromagnetic radiation from a device. Due to the passive nature of these attacks, countermeasures are fairly open-loop.  EMA attacks can be prevented though proper shielding. DPA and SHA attacks can be prevented by increasing the amount of power supply noise, vary algorithm timing and randomly inducing instructions, such as NOPs, that have no effect on the algorithm but impact power consumption.”

Developing a secure system

Both Imperas and OneSpin Solutions have pointed out to me that it is important to check the level of security of a system while the system is being developed.

David Kelf, Vice President of Marketing at OneSpin Solutions observed that “Many common hardware vulnerabilities take the form of enabling an unexpected path for data transfer or operational control. This can happen through the regular operational conduits of a design, or ancillary components such as the scan path, debug interfaces or an unexpected memory transfer. Even the power rails in a device may be manipulated to track private data access. The only sensible way to verify that such a path does not exist is to check every state that various blocks can get into and make sure that none of these states allows either a confidentiality breach, or an operational integrity problem.

An ideal technology for this purpose is Formal Verification, which allows questions to be asked of a design, such as “can this private key ever get to an output except the one intended” and have this question matched against all possible design states. Indeed, Formal is now being used for this purpose in designs that require a high degree of security.”

Larry Lapides, VP Sales at Imperas remarks that the use of virtual platform can significantly contribute to finding and fixing possible vulnerable issues in a system.  “The virtual platform based software development tools allow the running of the exact executables that would run on the hardware, but with additional controllability and observability, and determinism, not available when using the hardware platforms.

Among the approaches being used for security, hypervisors show excellent initial results.  Hypervisors are a layer of software that sits between the processor and the operating system and applications.  A hypervisor allows guest virtual machines (VMs) to be configured on the hardware, with each VM isolated from the others.  This isolation enables one or more guest VMs to run secure operating systems or secure applications.

Hypervisors have become increasingly common in different sectors in the industry: mil-aero, factory automation, automotive, artificial intelligence and the IoT. Embedded hypervisors face evolving demands for isolation, robustness and security in the face of more diverse and complex hardware, while at the same time needing to have minimal power and performance overhead.”

Imperas is a founding member of the prpl Foundation Security Working Group that has brought together companies and individuals with expertise in various aspects of embedded systems and security to document current best practices and derive recommended new security practices for embedded systems. Learn more at


Due to the scope of the subject this article is an overview only.  Follow up articles will present more details on the matter covered.

Tags: , , , , , , , , , , , , , , ,

Leave a Reply