Internet of Things Security (Part 6)

Identifying Threats

In this final part of his Internet of Things Security article series, this time Bob returns to his efforts to craft a checklist to help us create more secure IoT devices. This time he looks at developing a checklist to evaluate the threats to an IoT device.

By Bob Japenga

A number of years ago (there were woolly mammoths around if I remember correctly), I attended a conference on the Ada programming language. Ada was created for the United States’ Department of Defense to replace the myriad of programming languages that were deployed by the DoD at that time. The language was named after the first programmer, Augusta Ada King Lovelace, a colorful character in her own right and the only legitimate daughter of the poet Lord Byron. Ada is credited with publishing the first algorithm for use on a computing machine: Charles Babbage’s famous analytical engine.

At the conference I attended a breakout session on algorithms. In the conference room next door, a popular speaker, whose name I don’t remember, held another breakout session. About ten minutes into the session, we heard a deafening chant coming from the conference room next door that repeated over and over: “I don’t care.” The speaker was making a point that, as software designers, we should not care about everything. There are legitimate things for which we need to say: “I don’t care.” We need to identify them as not relevant to the task at hand and emphatically say: “I don’t care.”
Although I remember nothing from the breakout session on algorithms, I have never forgotten this principle: “There are some things that we just don’t care to address when designing embedded systems.” Certainly, there is much to be said for thoroughness in design, but when we—with well thought through analysis—determine that some aspect of a design is a “don’t care” we need to let it go.

In designing secure IoT devices this is a very important principle. The threats are diverse and difficult to number. The assets are important and of differing value. This month we will continue to build our checklist for IoT security. Last time we created a checklist to help you identify the assets that you want to protect. This month we will add to that checklist with some questions to help you identify and quantify the threats.

Identifying the Threats

We need to start with definitions. A good working definition for a threat would be: “a person or thing likely to cause damage or danger.” Although this is a good definition, for the purpose of building our checklist, I want to expand upon it a little. Here’s why: In most cases “I don’t care” who the threat is, nor do I care what their capabilities are. Keep in mind that, if there is a threat with very little capabilities, that threat could get passed on. They can always sell either their knowledge or their access to the device to someone who has the capabilities to create a security breach with the device. Let me illustrate that. Imagine there are two threats: One is a disgruntled former employee with little or no capability of reverse engineering your design in order to find a security flaw. The second is an organization with deep pockets and highly skilled hackers. If any of the assets that we identified in the first part of the checklist are worth a significant chunk of change, the former employee can always sell what they have to this other organization. With all that in mind, in general “I don’t care” about who the threat is.

But I do care about the activities of these threat agents. This is in line with the way the OWASP Top Ten IoT Security Threats is laid out. The Open Web Application Security Project (OWASP) is a worldwide organization focused on improving the security of software. I introduced OWASP as a valuable resource in my August 2016 column (Circuit Cellar 313) when we discussed their list of the top ten security vulnerabilities. The list was updated in 2017 and worthwhile to review [1]. OWASP also provides what its calls the top ten threats to IoT devices. We will look at these a little later in this article. They agree with my assessment that we don’t care who it is or what their capability is. What we care about is the action that they can take.

Figure 1
Shown here are the five areas of threat I’ve identified for IoT devices.

When thinking about threats to the security of our IoT device, I would identify five areas of threat as shown in Figure 1: access to the physical device; access to the wireless services on the device; access to the network (LAN or WAN) the device is on; access to the cloud server used by the device; and access to the mobile app used by the device. Anyone who has access to one or more of these is a threat agent. So, the beginning of our checklist needs to analyze what harm could be done by such a threat agent who gained access to any of these five areas of threat. Not all of your IoT devices have all of these areas of threat but most have a majority of them. For each of the areas of threat we need to ask the question: What would be the potential cost if someone with a lot of time, highly skilled hackers and a lot of money got access to one of these areas of threat without permission?

This provides the first five elements of the Threat portion of the IoT Security Checklist. Let’s look at each of these.

Five Threat Elements

Physical access: Not all IoT device designers will consider physical access to the device an area of threat. For example, we are currently working with a client who has determined that there is very little risk of an unauthorized person having physical access to their device. For most cases this is true. The device is only touched by employees and is physically inaccessible to everyone else. But I have not pushed them to protect the assets accessible through physical access for other reasons. I have gone along with that assessment because the assets available inside the device are minimal. But if the assets were valued higher, I would push back more strongly primarily due to the potential of a disgruntled or greedy insider handing the unit off to a qualified hacker.

Figure 2
Shown here are the access areas of threat if physical access is a threat area for your device.

If physical access is a threat area for your device, then the following access areas portrayed in Figure 2 need to be protected: access to data storage; access to user interfaces; access to USB ports; access to console ports; access to side channel information; and access to debug ports.

Mobile app: Many of our IoT devices have a mobile app associated with it. Although not strictly part of the IoT, it is certainly something that needs to be considered when designing your IoT device. Certainly, one approach is to limit who can put your mobile app on their phone or tablet. This certainly provides a great physical barrier to access. But the integration of Google’s Play Store and Apple’s App Store with your phone and tablet makes for very easy deployment and is very tempting to us designers. Surely the next line of defense is to drastically limit what the mobile app can access. Again, this is the power of the mobile app interface and you hate to lose it. Requiring a username and strong password is your next line of defense. For now, our job is to identify what harm someone bent on destroying your business would do if they were given unlimited access to your mobile app. How your mobile app communicates to the device is another concern we’ll look at next.

Wireless access: Your IoT device may provide several wireless ways to connect to it: cellular, Wi-Fi, Zigbee, Thread, Bluetooth, IrDA and Near Field Communication (NFC) are some of the most common. At this point in our checklist we need to ask: What if an unauthorized person got on your device wirelessly? What harm could be done? What if someone could perform a man-in-the-middle attack? The most recent Bluetooth hacking technique [2] shows us that even secure transmissions can have holes in their implementations allowing for man-in-the-middle attacks. So, we cannot just rely on secure transmissions as our only source of protection. I think about this every time I connect over Bluetooth to my OBD2 (on-board diagnostics) interface in my car. What would happen if someone could get on that interface and muck with my on-board computer? There’s no doubt that providing good access control through usernames and passwords, encrypting and authenticating all traffic and limiting physical access are all in your arsenal of protection. For now, we are concentrating on evaluating the harm nefarious access over the wireless interfaces on your IoT device could do.

Cloud access: Like mobile access, your cloud access is not strictly part of the IoT device. But again, we must pursue the questions: What if an unauthorized person got on your cloud interface? What harm could be done? The cost of that harm will help you to evaluate the amount of security you need to provide to the cloud interface. Clearly, we don’t want to use unencrypted transmissions. HTTPS provides encryption for us. But we found that on one of our major projects the cell modem chip only supported HTTP. So, we needed to encrypt the transmissions ourselves. Secure user access is pretty standard for cloud interfaces. But again, don’t rely on these layers. Seriously address what harm a malicious hacker intent on destroying your company could do if they had full access to your IoT cloud interface.

IoT network: Some of our IoT devices still have an Ethernet interface and provide some form of local area networking (LAN) or wide area networking (WAN). But this could be any wired network interface. Again, we need to look hard at what someone could gain from watching the traffic on the network. Our company’s most serious security breach came because of a little used Ethernet port that provided unencrypted traffic to a Link Local address. A researcher sniffed it out and found a security flaw. …

Read the full article in the December 341 issue of Circuit Cellar

Bob’s IoT Checklist can be found here.

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!

Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Wearables Drive Low Power Demands

320 Wearablese Lead Image for Web

MCUs & Analog ICs Meet Needs

Wearable devices put extreme demands on the embedded electronics that make them work. Devices spanning across the consumer, fitness and medical markets all need a mix of low-power, low-cost and high-speed processing.

By Jeff Child, Editor-in-Chief

Designers of new wearable, connected devices are struggling to extend battery life for next-generation products, while at the same time increasing functionality and performance in smaller form factors. These devices include a variety of products such as smartwatches, physical activity monitors, heart rate monitors, smart headphones and more. The microcontrollers embedded in these devices must blend extreme low power with high integration. Meanwhile, analog and power solutions for wearables must likewise be highly integrated while serving up low quiescent currents.

Modern wearable electronic devices all share some common requirements. They have an extremely low budget for power consumption,. They tend not to be suited for replaceable batteries and therefore must be rechargeable. They also usually require some kind of wireless connectivity. To meet those needs chip vendors—primarily from the microcontroller and analog markets—keep advancing solutions that consume extremely low levels of power and manage that power. This technology vendors are tasked to keep up with a wearable device market that IDC forecasts will experience a compound annual growth rate (CAGR) of 18.4% in 2020.

MCU and BLE Combo

Following all those trends at once is Cypress Semiconductor’s PSoC 6 BLE. In September the company made its public release of the PSoC 6 BLE Pioneer Kit and PSoC Creator Integrated Design Environment (IDE) software version 4.2 that enable designers to begin developing with the PSoC 6. The PSoC 6 BLE is has built-in Bluetooth Low Energy (BLE) wireless connectivity and integrated hardware-based security.

Photo 1 The PSoC BLE Pioneer Kit features a PSoC 63 MCU with BLE connectivity. The kit enables development of modern touch and gesture-based interfaces that are robust and reliable with a linear slider, touch buttons and proximity sensors based using Cypress’ CapSense capacitive-sensing technology.

Photo 1
The PSoC BLE Pioneer Kit features a PSoC 63 MCU with BLE connectivity. The kit enables development of modern touch and gesture-based interfaces that are robust and reliable with a linear slider, touch buttons and proximity sensors based using Cypress’ CapSense capacitive-sensing technology.

According to Cypress, the company had more than 2,500 embedded engineer customers registering for the PSoC 6 BLE early adopter program in just a few months. Early adopters are using the flexible dual-core architecture of PSoC 6, using the ARM Cortex-M4 core as a host processor and the Cortex-M0+ core to manage peripheral functions such as capacitive sensing, BLE connectivity and sensor aggregation. Early adopter applications include wearables, personal medical devices, wireless speakers and more. Designers are also using the built-in security features in PSoC 6 to help guard against unwanted access to data.  …

Read the full article in the December 329 issue of Circuit Cellar

Don’t miss out on upcoming issues of Circuit Cellar. Subscribe today!
Note: We’ve made the October 2017 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Reliability and Failure Prediction: A New Take

HALT methodology has been a popular way to test harsh environment reliability. A new approach involves PCB design simulation for vibration and acceleration for deeper yet faster analyses.

By Craig Armenti & Dave Wiens—Mentor Board Systems Division

Many electronic products today are required to operate under significant environmental stress for countless hours. The need to design a reliable product is not a new concept, however, the days of depending on a product’s “made in” label as an indicator of reliability are long gone. PCB designers now realize the importance of capturing the physical constraints and fatigue issues for a design prior to manufacturing to reduce board failure and improve product quality.

Simulation results should be available in a two-phase post-processor for each simulation, providing broad input on the PCB’s behavior under the defined conditions.

Simulation results should be available in a two-phase post-processor for each simulation, providing broad input on the PCB’s behavior under the defined conditions.

Although every product is expected to fail at some point. That’s inevitable. But premature failures can be mitigated through proper design when proper attention is paid to potential issues due to vibration and acceleration. ….

Read this article in the August 325 issue of Circuit Cellar

Not a Subscriber yet? Become one today:

 

Or purchase the August 2017 issue at the  CC-Webshop

 

Power Analysis of a Software DES Encryption Routine

This article continues the foray into breaking software security routines, now targeting a software implementation of DES. This builds on a previous example of breaking a hardware AES example.

By Colin O’Flynn

In the previous column, I broke a simple XOR password check using side-channel power analysis. How can we apply this to more complex algorithms though? In my Circuit   Cellar   313   (August   2016) story, I demonstrated how to break the AES encryption standard running on a FPGA.

The EFF’s “Deep Crack” board could brute force a DES key in a matter of days. (Photo courtesy of Electronic Frontier Foundation)

The EFF’s “Deep Crack” board could brute force a DES key in a matter of days. (Photo courtesy of Electronic Frontier Foundation)

While I originally considered breaking a software implementation of AES in this column, there was just too much overlap between those columns. So instead I decided to pick on something new. This time, I’ll cover how we can break a software implementation of DES. The actual process ends up being very similar. But by using a different algorithm, it might help give you a bit of perspective on how the underlying  attack  works.  ….

Read this article in the August 325 issue of Circuit Cellar

Not a Subscriber yet? Become one today:

 

Or purchase the August 2017 issue at the  CC-Webshop

 

The Future of IoT Security: One Size Doesn’t Fit All

Security is one of the hot topics today in the Internet of Things (IoT). There have been well-publicized security breaches of consumer devices that include hijacked video from wireless baby monitors being posted on the Internet and home automation systems that reveal whether a home is occupied or not. A number of systems have been breached just to demonstrate their vulnerabilities. Less well publicized are security breaches of industrial equipment with much more severe consequences. These are rarely made public for obvious reasons.

At first glance, it would seem that the existing security mechanism for the Internet and corporate networks would be an easy solution for IoT security. There are several problems with this. First, IoT applications only require security that is “good enough” for the specific application. Just like you don’t need razor wire and guard towers to keep your dog in the yard and don’t want to rely on a four foot yard fence to keep the prisoners in a maximum security prison, the level of security for an IoT product needs to be based on the needs of the application (often basic privacy rather than real security).

Consider data encryption for network transfers as an example of why existing security mechanisms generally do not work well for the IoT. Encryption standards typically target applications that require extremely high levels of security such as financial transactions and military or national security communications. These encryption standards are severe overkill for most IoT applications and present significant problems for small, battery-powered IoT devices. An encryption algorithm may require upwards of 4 KB of code space, which is as much or more than many otherwise suitable microcontrollers might have. Many encryption standards rely on multiple rounds of encryption. The time it takes to perform the encryption could be several times longer on a small micro than the time it takes the micro to perform its main tasks. Most common encryption standards rely on 16- to 32-byte keys to help ensure data security. For many IoT devices, these key lengths could increase the length of their network messages by a factor of 4× to 8× or more. The execution time and added network traffic can quickly chew-up precious battery capacity, increasing the size and cost of a product. The extremely high level of security provided by these encryption algorithms is what drives the large code size, long execution times, and high message overhead that makes them inappropriate for most IoT applications. Hardware encryption addresses the code size and execution time issues but still suffers from high message overhead.

 

The other major problem with using existing security mechanisms is IoT developers typically don’t have network security experience. There is a certain mindset and expertise required to develop IoT products and a completely different mindset and expertise required to be a security expert. The time required to develop these security mechanisms in-house could take several times longer than the basic product development. Several companies have recognized this problem and have recently introduced security framework products to be incorporated into IoT devices. True end-to-end security requires much more than just passwords and data encryption, and these framework products address other needs like key management and protection against common network attacks. These security frameworks may well be the future of IoT security, but to be widely adopted, they have to be right-sized for IoT devices.

When selecting the wireless technology to use in an IoT product, things like distance, bandwidth, cost, and physical size have to be considered. Words and phrases like “streamlined” and “light weight” need to be kept in mind when assessing security solutions for IoT products. A feature-rich security framework product might be appealing, but many IoT devices provide simple functions and don’t need a plethora of features. They also can’t afford the memory space and execution time overhead (and power consumption) imposed by these unneeded features. Whether future IoT products are based on a security framework or in-house developed security, there will not be a one-size-fits-all solution. Security for successful IoT products will be right-sized for the hardware resources available and the needs of the application.

Mike Lease is a hardware/firmware engineer with more than 30 years of product development experience, mostly in embedded products. He developed a number of battery-powered, wirelessly connected devices before “IoT” became a common buzzword, and several more since then. Mike enjoys taking on tough challenges and has recently developed a fascination with generating random numbers. In 2013 he founded CMicrotek (www.cmicrotek.com) to develop a family of ultra-low current measurement products primarily for developers of battery-powered products. Mike recently launched LSE Technologies, a provider of lightweight stream encryption software for M2M and IoT applications.

Light-Weight Data Encryption for IoT and M2M Applications

LSE Technologies recently announced it is enabling secure end-to-end network data transfers for M2M applications and IoT devices with its Lightweight Stream Encryption Technology (LSET) C source code packages. LSE tech

Three versions of the LSET Professional product line are available for different levels of security and processing resources:

  • LSET Pro is targeted at 8-bit and low-end 16/32-bit microcontrollers and offers basic encryption algorithm for short control/status messages.
  • LSET ProX is targeted at mid-range 16/32-bit microcontrollers with an enhanced encryption/decryption engine and key security features. It is suitable for short control/status messaging as well as video and firmware updates.
  • LSET ProXT is targeted at higher end 32-bit microcontrollers and provides a more advanced encryption/decryption engine and additional key security features. It is suitable for longer messages such as in gateway applications as well as for video and firmware updates.

On a common 32-bit microcontroller, a typical implementation of the LSET ProX package would require about 600 bytes of code space plus 64 bytes of RAM and with a 20-MHz CPU clock encryption/decryption could be performed in about 2.5 µs per byte.

The LSET source code packages were designed to be easily incorporated into existing code bases. In many cases data encryption can be added to a product in just a few hours. The LSET Professional C source code packages start at $500 for the LSET Pro package.

Source: LSE Technologies

CC266: Microcontroller-Based Data Management

Regardless of your area of embedded design or programming expertise, you have one thing in common with every electronics designer, programmer, and engineering student across the globe: almost everything you do relates to data. Each workday, you busy yourself with acquiring data, transmitting it, repackaging it, compressing it, securing it, sharing it, storing it, analyzing it, converting it, deleting it, decoding it, quantifying it, graphing it, and more. I could go on, but I won’t. The idea is clear: manipulating and controlling data in its many forms is essential to everything you do.

The ubiquitous importance of data is what makes Circuit Cellar’s Data Acquisition issue one of the most popular each year. And since you’re always seeking innovative ways to obtain, secure, and transmit data, we consider it our duty to deliver you a wide variety of content on these topics. The September 2012 issue (Circuit Cellar 266) features both data acquisition system designs and tips relating to control and data management.

On page 18, Brian Beard explains how he planned and built a microcontroller-based environmental data logger. The system can sense and record relative light intensity, barometric pressure, relative humidity, and more.

a: This is the environmental data logger’s (EDL) circuit board. b: This is the back of the EDL.

Data acquisition has been an important theme for engineering instructor Miguel Sánchez, who since 2005 has published six articles in Circuit Cellar about projects such as a digital video recorder (Circuit Cellar 174), “teleporting” serial communications via the ’Net (Circuit Cellar 193), and a creative DIY image-processing system (Circuit Cellar 263). An informative interview with Miguel begins on page 28.

Turn to page 38 for an informative article about how to build a compact acceleration data acquisition system. Mark Csele covers everything you need to know from basic physics to system design to acceleration testing.

This is the complete portable accelerometer design. with the serial download adapter. The adapter is installed only when downloading data to a PC and mates with an eight pin connector on the PCB. The rear of the unit features three powerful
rare-earth magnets that enable it to be attached to a vehicle.

In “Hardware-Accelerated Encryption,” Patrick Schaumont describes a hardware accelerator for data encryption (p. 48). He details the advanced encryption standard (AES) and encourages you to consider working with an FPGA.

This is the embedded processor design flow with FPGA. a: A C program is compiled for a softcore CPU, which is configured in an FPGA. b: To accelerate this C program, it is partitioned into a part for the software CPU, and a part that will be implemented as a hardware accelerator. The softcore CPU is configured together with the hardware accelerator in the FPGA.

Are you now ready to start a new data acquisition project? If so, read George Novacek’s article “Project Configuration Control” (p. 58), George Martin’s article “Software & Design File Organization” (p. 62), and Jeff Bachiochi’s article “Flowcharting Made Simple” (p. 66) before hitting your workbench. You’ll find their tips on project organization, planning, and implementation useful and immediately applicable.

Lastly, on behalf of the entire Circuit Cellar/Elektor team, I congratulate the winners of the DesignSpark chipKIT Challenge. Turn to page 32 to learn about Dean Boman’s First Prize-winning energy-monitoring system, as well as the other exceptional projects that placed at the top. The complete projects (abstracts, photos, schematic, and code) for all the winning entries are posted on the DesignSpark chipKIT Challenge website.