Monthly Archives: February 2014

Are you taking embedded security seriously?



February 4th, 2014

A lock with the key still in it isn’t much of a solution. Sadly, the security in many embedded devices isn’t much better.

By: Alan Grau, Icon Labs

At the gym last week I noticed a locker secured with a padlock but with the key still in the lock. One of the assumptions of locking something up is that there is something worth protecting. If the contents of the locker weren’t worth protecting, then don’t bother with the lock. But if you are going to bother with a lock, or with adding security to your embedded device, you might as well make sure the security will work. A lock with the key still in it isn’t much of a solution. Sadly, the security in many embedded devices isn’t much better.

Is this your embedded security solution?

Is this your embedded security solution?

Many embedded devices have been built with very little, if any security. Too often what security is provided is insufficient. In June 2013, ICS-CERT (Industrial Control Systems Cyber Emergency Response Team) published a list with more than 300 medical devices from approximately 40 vendors that used hard coded passwords, almost the literal equivalent of leaving the key in the lock.

Other embedded devices are using out of date crypto standards. For example, keyless remote vehicle entry systems utilize encrypted RFID signals. Most implementations use a 40 bit encrypt key. When the standard was first introduced in the 1990s 40 bit encryption keys would take days to crack, but not today. A google search of “keyless vehicle entry systems hacked” turns up a number of articles describing how thieves are exploiting this weakness to steal cars.

Security – Priority or Afterthought

While embedded devices are very different from standard PCs and require unique solutions, the biggest challenge to embedded security isn’t technical.

Too often, security is simply not a priority. I recently received a call from a company putting together a requirements document for a critical new piece of technology for a Fortune 100 company. This was a core piece of technology that was to be used across a majority of the company’s products. As this document was being finished they realized they had not addressed security and they didn’t have the expertise in house for this task. They wanted to see how they could drop in some security at the last minute. While they were still in the requirements phase and there was time to address it, security was clearly not a priority despite the fact that this would go into a product that virtually everyone in the developed world uses on a daily basis – and a security breakdown could literally result in the loss of life. Sadly, this is not the only example I have seen in which security is an afterthought.

Security for Modern Embedded Devices

A security solution for embedded devices must ensure the device firmware has not been tampered with. It must also secure the data stored by the device, secure device communication and protect the device from cyber-attacks. This can only be achieved by including security from the early stages of design.

There is no one one-size fits all security solution for an embedded device. Security requirements must take into consideration the cost of a security failure (economic, environmental, social, etc.), the risk of attack, available attack vectors, and the length of time the device will be in service. Many embedded devices will still be in service 10 or even 20 years from now. Given Moore’s Law, an encryption key that provides strong encryption today may not hold up for the next two decades.

Embedded security features that need to be considered are:

  • Secure Boot – Achieved using cryptographically signed code from the manufacturer along with hardware support to verify code is authenticated. This ensures that the firmware has not been tampered with.
  • Secure Access – Access to the device (remote login, access to a web interface, etc.) need to be secured with encryption and a strong authentication method. A strong password or an authentication method such as Kerberos can be used.
  • Secure Communication – Communication to/from the device needs to be secured using encrypted communication (SSH, SSL, etc.). Care must be taken to avoid the use of insecure encryption algorithms.
  • Embedded Firewall – Embedded firewalls provide a critical layer of protection against attacks. A firewall can limit communication to only known, trusted hosts, blocking hackers before they can even launch an attack. A layer of defense to protect against common attacks such as packet flood attacks, buffer overflow attacks and known protocol exploits.
  • Summary

    If security is made a priority, I believe engineering teams are more than capable of building much higher levels of security into their devices. Solutions are available for including encryption, secure boot, authentication and firewalls into embedded devices. The key (no pun!) is that security needs to be considered early in the design of a new device or system. Support for secure boot or device tamper detection requires specific hardware capabilities. Since hardware is typically selected early in the design phase, this capability must be considered very early in the process. Since many embedded devices are deployed outside of the standard enterprise security perimeter, it is critical that security be included in the device itself.

    Alan Grau

    Alan Grau is President and co-founder of Icon Labs, a leading provider of security software for embedded devices. He is the architect of Icon Labs’ award winning Floodgate Firewall. Alan has 20 years of embedded software experience. Prior to founding Icon Labs he worked for AT&T Bell Labs and Motorola. Alan has an MS in computer science from Northwestern University. You can reach him at alan.grau@iconlabs.com