What impact has the Heartbleed bug had on embedded security systems?

With its massive scope and untraceable reach, the Heartbleed bug will go down as one of the worst security exploits in recent history. But for all it’s worth, most of the media coverage over the last few weeks has centered on passwords, completely avoiding the subject of embedded security systems. To understand why embedded systems have their own special requirements that need addressing, let us first briefly recap what exactly the Heartbleed bug is.

Heartbleed is a security bug in version 1.0.1 of OpenSSL, an open source library commonly used for securing communications using transport layer security (TLS) protocols. The bug originated with the introduction of the RFC 6520 Heartbeat Extension that became widespread with the release of OpenSSL version 1.0.1 on March 14, 2012.

The TLS Extension was added to keep TLS connections alive avoiding the need to renegotiate the connection each time each time the data needs to be exchanged. A simple coding error that failed to initiate a correct length check was overlooked, introducing a bug that caused memory leakage of up to 64 kbits from the OpenSSL process whenever a malicious network packet was sent to the server with the Heartbleed code bug.

The 64 kbits of memory sent back may contain user names, passwords, and credit card numbers along with the authentication key that ensures the website is connecting to the right server. Using this key, attackers can create a false web server that impersonates the real one and steal all the information a user enters ─ essentially, a man-in-the-middle attack. Worst of all is that security breaches piggybacking off the exploit leave no traceable evidence, meaning there’s no way of determining how much data has been stolen over the last few years, if any at all ─ assuming no one knew about the bug until now.

Impact on embedded systems
To understand how this bug impacts embedded systems, it’s first important to familiarize yourself with how these issues relate to OpenSSL on a client system.

If you are  running a server using firmware that contains a version of OpenSSL with the Heartbleed bug, such as version 1.0.1 through 1.0.1f, then you’ll need a new firmware update immediately lest malicious scanners discover this weakness. Unfortunately, using OpenSSL in its client capacity does not place your embedded system in any less risk; an advanced technique called Reverse Heartbleed can theoretically attack OpenSSL clients who try to connect to servers.

In response to the vast amount of Heartbleed media coverage over the last few weeks, web servers have been patched to eliminate the vulnerability, new private master keys have been issued, and users have been notified to change their passwords. However, resolution on the embedded system level is not this straightforward or immediate.

Embedded systems don’t have the luxury of immediate patching. Patching an embedded system is a conservative measure that often requires months of regression testing to ensure no functionality was impacted; all the while the system remains susceptible to the bug’s exploits, assuming the embedded device is relatively recent and can even be patched in the first place. End-of-life devices must often be replaced all together. For this reason, maximizing embedded security from the get-go is a much better practice.

Our familiarity with the Heartbleed bug dictates that under best practices, embedded systems must only grant components access to the system resources or other components they absolutely need. One should be wary of component architecture and certify that the operating system creates a clear distinction between components to avoid linking everything together as was the case with OpenSSL. The memory leak in an embedded system will substantially worsen if the monolithic kernel is linked to the OpenSSL, potentially granting access to all the memory.

Lastly, incorporate embedded security from reputable vendors such as Maxim Integrated. Their DeepCover™ Secure Authenticator implements advanced physical security to provide clone prevention, and peripheral authentication to stop counterfeiters from stealing your IP and accessing valuable R&D data. Alternatively, the DeepCover Security manager allows users to add advanced physical security to systems using their existing system microprocessor. A proprietary “nonimprinting” memory is included in the IC to store critical data and immediately erase it upon tamper. While a tamper would not have been detected in the case of Heartbleed bug, the added security could prevent malicious users from stealing sensitive IP.

Whether designing your own embedded security or procuring it from an outside source, be vigilant that that best practices were employed in its design to avoid unnecessary human error that could cause drastic security breaches further down the line. This is especially valuable in the context of embedded systems and their slow updating cycle.