Implementing Robust Information Security for Every Connected Device

We hear about security breaches at big retailers and banking institutions just about every day. Looking in the near future, we can only expect these breaches to happen even more frequently as hackers use more sophisticated tools and the value of the information they can extract continues to grow. And attacks against embedded systems are also growing dramatically. In fact, the U.S. government recently asked critical infrastructure firms, one of the largest users of connected embedded systems, to check if their networks were infected by malicious software from the "Energetic Bear" hacking group. The Department of Homeland Security's Industrial Control Systems Cyber Emergency Response Team issued the request around concerns that the nation's power grid could be at risk.

Attacks that target critical infrastructure or the secure data of millions of customers are scary, but bringing it down to a more personal level, there are major concerns about the ease of which hackers can access data from the embedded systems in homes, cars, and the hundreds of embedded devices that the general population interacts with on a daily basis. An individual's smart home, for example, might know when to expect its owner home, but is the homeowner safe if anyone has access to that information? If an individual wears an activity tracker that connects to the cloud, what are the security ramifications if just anyone can access details about the location of the wearer, whether he or she is sleeping, and what he or she had for lunch? Who knows what seemingly innocent data might be used for if it can be combined, compared, and data-mined from other sources?

Device Security

As systems designers, what can we do to improve the security of personal information and what features should we expect embedded system building blocks like MCUs and FPGAs to provide? Perhaps considering a few ideas from Big Data information security initiatives is a good first step. The Big Data security mantra maintains that robust security must be layered so a single point of failure doesn't give attackers (or data miners) an easy way to access important data. So the question arises: How can layered security be implemented in an embedded device?

Figure 1: Device level security drives information security in connected devices (Source: iStock #52639560)

Perhaps the most obvious security functions required in an MCU or FPGA are support for common cryptographic standards for encrypting and decrypting sensitive data. Additionally, secure password protection is critical so that passwords can't be accessed via network attacks or physical tampering. Some of the most advanced password protection techniques use the nanoscale differences in the integrated circuit manufacturing process to create unique device passwords that never leave the device and are never visible to outside attacks. One example of such a physically unclonable function, or PUF, relies on the slight differences in SRAM initialization values during a power up cycle to create a truly device-unique and random password.

In order to provide another layer of security to a device, it can be necessary to disable some of the functions used to access on-chip data. For example, if the MCU code can be easily accessed via a debugging or test port, device security could be easily compromised. MCUs and FPGAs need to provide protection - perhaps via special locks or passwords - so that unauthorized users cannot access data via these ports. At a minimum, these ports should be able to be completely 'turned off' so that they don't provide a potential attack vector.

Another opportunity for layered security relates to the data stored on-chip. Many MCUs and FPGAs can provide restricted access to on-chip data. Security-related code, for example, could be stored in an execute-only memory bank that can't be easily accessed by other on-chip processes. Common attack methods on embedded devices count on programming errors that generate "wild" pointers to access otherwise inaccessible data. However, hardware protection of critical data can restrict such access attempts and flag the error as a potential tampering event, so the system can apply appropriate penalties.

Often an embedded device can be reprogrammed remotely, a useful capability for fixing bugs and adding features. Unfortunately, if this facility isn't protected, an attacker could insert their own malicious code and hijack confidential data as it flows through the system. Additional security layers need to be provided when remote updates and bug fixes are supported by the embedded device or security functions could be easily compromised.

Conclusion

The above examples are just a few of the issues that need to be addressed by MCUs and FPGAs as their use in connected embedded systems continues to expand over the next few years. Systems designers should expect devices that provide for multiple layers of security at the device level to be growing players in the rollout of connected devices in the near-term.