Opinion: Security is the Achilles heel

One of the first changes that must occur is in the way Internet of Things System-on-Chip devices are designed and manufactured...

One potentially huge new market that is emerging from the convergence of cloud computing, machine-to-machine communications, wireless sensors, and the broadband Internet—both wireless and wired, is the so-called Internet-of-Things (IoT). The market got a boost recently when ARM helped form an industry forum to shape the IoT. If there any is doubt about ARM’s motive the observer needed only look back to March this year when ARM announced its Flycather CPU core designed especially for controlling the IoT.

While it is not obvious now, the one Achilles heel confronting this exploding market potential is security. The lack of security in the universe of machine-to-machine communications, notably industrial controllers was brought into clear focus by the U.S. Government’s successful cyber-attacks on Iran’s nuclear enrichment program using the Stuxnet computer worm.According to the New York Times, the worm “temporarily took out nearly 1,000 of (Iran’s) 5,000 centrifuges.” The implication was clear that any machine connected to the Internet could be successfully attacked and its intended purpose subverted.

Security risks have never deterred the advancement of new technology such as the IoT as the prevalence of on-line commerce will attest. However, just as previous technology advances confronted the issues of security liability, so too, will the IoT likewise rise to the challenge. One of the first changes that must occur is in the way IoT System-on-Chip devices are designed and manufactured.

In his remarks during the DAC Pavilion Panel discussion “Is "Lifecare" the Next Killer App?” Kristopher Ardis, Director of Business Development, Smart Grid Solutions at Maxim Integrated Products described this new methodology as designing security in from the start. “When you design a device it should do exactly what it was designed to do and nothing more,” he stated. “Engineers must think of all threats to a design from initial concept through completion of the design.”

One particular vulnerable element in the embedded controller within an IoT device is its program.Software has traditionally been executed from programmable memory after the system is booted up using code stored in read-only memory (ROM) or non-volatile memory (NVM). This approach must be re-architected given the vulnerability demonstrated by recent cyber-attacks.

To ensure that a device is resilient to cyber-attack, its control program should not be changeable in the field. One way to prevent changes is to execute the code from ROM or one-time programmable (OTP) NVM. The advantage of executing from ROM or NVM is that a hacker cannot change the code remotely. Furthermore, both provide security from hackers using physical attacks, however, of the two ROM is more vulnerable than NVM to physical attacks.

ROM is the absence or presence of a metal via deposited during the final stages of chip fabrication, which means that the program code is part of the metal mask layer of a chip—revisions require a new mask set. Thus, hackers using non-invasive techniques such as power analysis or more invasive reverse-engineering techniques such as de-processing and Focused Ion Beam analysis can read the contents of ROM memory.This is the one advantage of OTP NVM based on anti-fuse technology.

Storing a bit of data in anti-fuse bit cells occurs when a programming voltage is applied to the gate of a logic CMOS transistor to produce a breakdown in its gate dielectric, thus producing a logic “1” (changing a high resistance path into a low resistance).This storage mechanism provides very high security.Since the bit cell does not store a charge there is no physical evidence of its state. The bit determines an initial “0” or programmed “1” through the process of a very low sensing current, not voltage, thus making the cell less vulnerable to low-cost passive attacks—Glitching and Data Remanence—as well as semi-invasive attacks such as UV attacks, Fault Injection, and Voltage Contrast.

Finally, the anti-fuse NVM has one other benefit that contributes to increased security of an IoT device: its ability to be programmed during final test. The obvious plus is that one design can be configured for a number of different applications.ROM would demand a unique mask set for each version.The security advantage this provides over ROM is the ability to completely erase the memory upon detecting the devise has been or is being compromised. A programming voltage applied to the memory array turns all bits to “1”.

As the design community begins designing more IoT devices and realize the security vulnerabilities when these devices are installed in the field, the unique benefits of anti-fuse NVM will become more apparent. Thus, this technology that has provided secure storage of encryption keys in set-top boxes and other conditional access applications will offer similar capability to an entirely new generation of SoC designs.

About the author

David Hsu is senior field marketing and applications manager at Kilopass Technology Inc. He graduated from The Ohio State University and received his Master’s degree in Electrical Engineering from Purdue University. Hsu started his career in Siemens Components in the telecommunication division; later at Datapath Systems’ read channel program and as principal engineer at LSI Logic HyperPHy SerDes group from1998 to 2006. Between 2006-2009, he worked at TSMC in the role of customer support and in IP/Library quality management.

If you found this article to be of interest, visit EDA Designline where you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of Electronic Design Automation (EDA).

Also, you can obtain a highlights update delivered directly to your inbox by signing up for the EDA Designline weekly newsletter – just Click Here to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you).

Hi David - appreciate the quote, and I certainly agree that "code security" is a key issue in making the Internet-of-Things work safely and reliably. I do want to point out that while ROM or OTP is an effective way to deter hackers from changing the behavior of a system, it may be too limiting for complex applications. In these cases, strong cryptographic authentication of firmware and firmware downloads can help to safeguard the system that relies on reprogrammable flash (or similar) for its code store.

Hi Kris, I invite everyone who found David's article interesting to view the DAC Panel "Is Lifecare the Next Killer App?" in which you participated on YouTube (http://tiny.cc/grggjw). It will provide a better understanding of the huge potential that machine-to-machine interaction, cloud computing, and Internet-or-Things represent.

Interesting article indeed. But is making my toaster subject to a hackers attack worth whatever nebulous advantage is to be gained? I am aware of the theory that smart appliances can be programmed to run when power is the cheapest, but we can also do that with a timer and published rate data. My point is that the internet of things will primarily benefit those who sell the internet connection part of the thing. Most of the benefits can be had in other manners, and almost all of them are more secure.
Ask yourself this: "do you want some hacker controlling your toaster?"

Is this barking article up the wrong tree? If it is a toaster or set-top box, do I WANT it to be capable of erasing itself? For such mundane applications, such heavy-handed approaches cost warranty dollars and customer confidence.
The REAL issues with putting everything on on the web are:
1. Can someone monitor the web and learn too much about a target of interest? This might include such things as whether one is home (making home a burglary target), and gathering data on any projects being worked on by a business that uses web-based but inadequately secure storage services (most of them).
2. Can someone intentionally or unintentionally (generally the former) vandalize property and equipment that they do not own (eg. Stuxnet)?
The biggest issue facing too many engineers and companies right now is,
"It can be done, and it can be sold, but SHOULD if be done?"

It is possible to do too much security too. If we require toasters to use OTP and/or cryptographically signed firmware, they cost and complication of product updates, warranty repairs and such could go up significantly. An example of problems with that strategy is the locked-in inkjet printer cartridges---manufacturers justified it by a combination of 'protecting the customer from expired/counterfeit product' and 'sell the printer cheap and make it up on supplies' strategies---but the end result is that customers either buy new printers on sale or stop buying inkjets entirely.
I actually look and buy products that have a reputation for openness and upgradeability: openWRT network routers, GE programmable lights, etc. I will avoid products that are designed to be locked up, just like I would never buy a car with the hood welded shut.

Obviously we have people looking at the How and Where of security with the IoT.
The whys are fairly obvious: so that damage (physical and monetary) is prevented, sensitive and personal information is not compromised, and that we feel safe and confident in our technology.
The next step is to consider the Who and What: there will be a lot of things on the Internet of Things. Some will be safety-critical, some will be life-critical, some will be information- or infrastructure-critical. Most will not be. What we need is classifications of devices and what security measures are necessary to ensure that if they need to remain un-compromised they can.
Should I be able to hack my power or water meter? No. Should I be able to hack someone's health device? No. Should I be able to hack my toaster? Maybe, so long as I can't hack yours remotely and burn down your house. Should I be able to hack my non-critical house sensors? Yes, absolutely, so I can gather more data or create special applications with them.

Obviously we have people looking at the How and Where of security with the IoT.
The whys are fairly obvious: so that damage (physical and monetary) is prevented, sensitive and personal information is not compromised, and that we feel safe and confident in our technology.
The next step is to consider the Who and What: there will be a lot of things on the Internet of Things. Some will be safety-critical, some will be life-critical, some will be information- or infrastructure-critical. Most will not be. What we need is classifications of devices and what security measures are necessary to ensure that if they need to remain un-compromised they can.
Should I be able to hack my power or water meter? No. Should I be able to hack someone's health device? No. Should I be able to hack my toaster? Maybe, so long as I can't hack yours remotely and burn down your house. Should I be able to hack my non-critical house sensors? Yes, absolutely, so I can gather more data or create special applications with them.