Security: The Role Software Plays in Shielding Against Cyber-Hacks

While securing an embedded system requires a multi-layered approach, involving everything from the system’s packaging to its software, the key ingredient is an MCU that can tie it all together. In a previous TechZone article (“Secure MCUs and Smart Design Harden Embedded Systems Against Cyber-Hacks”), we explored some of the techniques employed by hackers to exploit embedded systems’ vulnerabilities and the features included in security-conscious MCUs that can be used to defeat them. Here we will focus primarily on the role software plays in preventing intrusions and, when the inevitable happens, detecting them and limiting the damage they do. As we shall see, layered security strategies also apply to software, borrowing from strategies employed in enterprise-level systems that include multiple, independent defenses.

Virtually every hacking technique involves software at one level or another. While classical software attacks exploit weaknesses in a system’s programming without any direct physical contact, most hardware attacks are launched with the eventual goal of subverting the device’s operating system or the applications running on it to attain higher user privileges or complete (root) control of the system. One of the most common targets for this type of attack is the embedded system’s network interface and its associated protocol stacks.

Often, hackers will gain access to the system’s network connection and attempt to insert various types of malformed messages such as unexpected characters or sequences of characters that force the networking stack into an error condition which may be susceptible to manipulation. In a similar manner, sending a string of over-length packets can induce a buffer overflow condition in some protocol stacks, creating exploitable errors by overwriting critical variables or parts of the system’s operating code.

The first line of defense against this class of attacks is to verify that the communication software element has been rigorously tested to insure that it checks message length and screens incoming traffic thoroughly for valid messages. Additional measures to confirm the identity of the sender such as a protocol that uses a verified date/time stamp and Number Used Once (NONCE) exchange can help guard against a rogue system intercepting a login sequence and using it to gain access to your application (i.e., a replay attack). Other verification techniques that measure the time delay between a sender’s responses can be used to determine its relative distance from the target system and provide an additional layer of security.

Since there is no way to guarantee your network interface is 100% secure, it is wise to limit the damage a hacker can do if they manage to uncover some flaw they can exploit. Perhaps the most straightforward approach is to use separate processor cores (and memories) for communication and application functions and a strict message processing protocol that limits the interactions between the isolated systems. This has been a common practice in Smart Meters, with separate MCUs handling communications tasks, application processing, and the actual metrology functions, but several dual-core MCU chips have recently been introduced that offer a more integrated solution. For example, Texas Instruments’ F28M35x Concerto family combines an ARM Cortex-M3 core and a C28x digital signal controller core that communicate via a shared parity RAM. Intended for applications such as industrial controllers and solar inverters, the Concerto devices allow designers to isolate the communication and control elements of their application while maintaining a single-chip solution.

Freescale also recently announced the upcoming VF6xx (Figure 1) and VF7xx Vybrid families of dual-core processors (silicon, technical documentation, software, and tools will be available as of September 2012, according to Freescale), which will contain many features essential to secure meter, energy gateway, and financial transaction terminal designs. Both Vybrid series employ a Cortex A5 processor to run HMI/comms functions and a Cortex M4 core for application and control functions. On-chip security features include ARM’s TrustZone architecture with Freescale security extensions for secure transactions and a hardware core that supports digital rights management (DRM) transactions. Each of the Vybrid’s MCU cores is equipped with independent secure-boot logic that requires a handshake with a key retrieved from the processors’ secure NVRAM before it allows the core to execute any code. This prevents spoofing of software through key authentication or software re-imaging (roll-back attack).

Figure 1: Block diagram of Freescale’s upcoming Vybrid 6xx MCU. Note the security block in dark blue.

Alternatively, an MCU with single processor core can isolate the communication functions with an operating system (OS) that supports virtualization (such as Green Hills’s Integrity Multivisor or Wind River’s Hypervisor) or uses some other mechanism to compartmentalize the processes it runs.

Unfortunately, most virtualized OSs require a more complex MCU with a memory management unit (MMU) core, which may not be cost-effective for many embedded applications. There are, however, several operating systems (such as Green Hills’ Integrity RTOS and Wind River’s VxWorks RTOS) that include highly-managed “sandbox” capabilities that provide relatively secure compartmentalization between applications without the need for an MMU. For highly resource-constrained environments such as Smart Cards and other small memory footprint devices, the JavaCard VM environment provides applet firewalling that restricts and checks access of data elements of one applet to another.

Beware of the human factor

There is another class of attacks that takes advantage of the fact that, until recently, embedded designers have not been accustomed to thinking about security and often rely on “invisibility through obscurity.” As a result, some of the most routine (and successful) security breaches involve “human factor” issues, and use various techniques to exploit weak or default passwords. Many users make poor choices for passwords, leaving their device vulnerable to dictionary and scripting techniques or other brute force attacks. The hacked road signs in Figure 2 are an example of a common tendency among users to use weak passwords, or even simply fail to change the default passwords that were assigned at the factory.

Figure 2: One of the first reported incidents of hacked digital road signs occurred in Austin, TX in 2009. While these early pranksters physically broke into the sign’s control box and used the factory default password to access the display, hackers have now learned to remotely reprogram signs equipped with networking capabilities by exploiting weaknesses in their communication software.

The first layer of defenses against this class of password attacks also lies in the realm of human factors. Whenever possible, a designer should incorporate mechanisms into their user interface that strongly encourage (or even require) a user to choose a strong, unique password for each device at the time it is configured for use. It is also often worth the investment to include an application or web-based tool that gives your customer an easy, secure mechanism for password management. It should be noted, however, that neither of these measures offers much protection against so-called insider attacks by disgruntled employees or other individuals who manage to gain access to system passwords.

Firewalls add another layer

Since insider attacks and many other routine (and successful) attacks involve weak or compromised passwords, a firewall is essential for authenticating and limiting access to authorized ports and IP addresses. When properly configured, a firewall can also use its policy-based filtering techniques to protect against insider attacks while adding another important layer of defense against other types of assaults such as dictionary attacks, denial of service (DoS), and packet flooding.

The concept of a firewall is straightforward – block packets sent by hackers or other Internet-based threats and allow packets that should be processed by the device. This is achieved by a filtering engine that compares packets to a set of rules (Figure 3) that define trusted senders, supported protocols, and open ports. There are three types of filtering an embedded firewall may provide:

• Static filtering: filters packets based only on the information in the packet. This includes filtering based on port number, protocol, IP address, etc.
• Dynamic filtering or Stateful Packet Inspection (SPI): filters packets based on the state of the connection, allowing packets to be blocked or rejected based on the connection state as well as the filtering rules.
• Threshold-based filtering: keeps statistics on the packets received and monitors for threshold crossings based on configured time intervals and threshold levels. If the number of packets received from a specific IP address during any time interval exceeds the pre-configured high-water threshold, future packets from that IP address will be dropped, blocking packet floods and denial-of-service (DoS) attacks.

Figure 3: A software firewall can apply rules-based packet filtering based on IP or MAC address or packet type to only allow traffic from trusted senders to access the system. (Courtesy of Icon Labs.)

A firewall that combines these capabilities can strictly limit access to a select series of IP or MAC address (or a range of addresses) or and limit the type of traffic (UDP, TCP, etc.) allowed on any particular port. Since firewalls reduce the likelihood of attack by blocking “bad packets” at the IP layer before they can enter the system, they complement and offload the SSH and SSL security protocols which actively protect against an attack in progress. These capabilities can also be used to block an embedded hacker’s dictionary attack on passwords, or even a known password obtained from an insider unless they were attempting to penetrate the system from a device whose MAC, IP, and port addresses were on the firewall’s “white list.” Other common firewall capabilities include a “lock-down” mode, which only allows outgoing communications from the embedded device to specific ports and IP addresses.

Firewall implementation issues

In order to successfully protect an application, a firewall must strike a difficult balance between locking down the system completely and allowing the application enough flexibility to do its job. For example, most embedded applications connect with a very limited subset of IP addresses so they can be locked down tightly. However, others (such as printers or network attached storage (NAS) systems) must be able to talk to both local devices and “phone home” across the net for updates and diagnostics. Modern firewall configuration tools make setting up these complex rules a relatively easy task. Ideally, the firewall would also support all three filtering methods (static, dynamic, and threshold-based), to provide the greatest number of options for protecting their device. As with password management, a firewall must have a straightforward method for configuring filtering rules and criteria, and for reporting blocked packets and possible attacks.

In addition, the code for an embedded firewall must be small, efficient and easily integrated with the operating system and TCP/IP stack of the embedded device. Since many embedded systems are based on slower, energy-efficient MCUs with modest amounts of memory, the firewall code must not excessively burden its host’s resources.

Icon Labs’ Floodgate is a good example of a firewall tailored to meet the often-conflicting requirements of embedded applications. The firmware has a compact software footprint of roughly 24 Kbytes (and as low as 12 Kbytes for certain applications), imposes a low processing load, and is currently available as a portable C library for several embedded operating systems including MQX, GHS Integrity, LinuxWorks, and VxWorks. The software package also includes a TCP/IP stack, a web-server-based management interface, and a royalty-free RTOS. Although it is primarily intended as a platform-independent adjunct to an operating system, Floodgate’s small footprint also enables it to be software-ported to Zilog’s 8-bit EZ80 MCU, where it is embedded as firmware in its on-chip flash. At the time of this writing, Icon is porting Floodgate to Freescale’s MQX RTOS for use with its CortexM4-powered Kinetis K30 MCU.

The road ahead

In the ever-escalating race for digital dominance, firewalls and other software security tools must continually adapt to stay one step ahead of their adversaries. One of the next steps will be to expand the limited messaging capabilities of today’s firewalls to support an SNMP agent or other standard reporting mechanism, used to remotely manage large collections of network elements. A bit further down the road, security-conscious MCU makers are planning on adding inter-node communication capabilities to their firmware. In a manner that mimics the immune system of living organisms, inter-node communication will allow each Smart Meter, ATM, or other networked application to alert its fellow devices about any attacks being made against it.

Deep packet inspection (DPI) has proven an invaluable tool for intrusion detection/prevention in enterprise networks, but today’s embedded firewall software does not presently include the compute-intensive algorithms required to support it. However, it is likely that the next generation of security products will offer at least some limited DPI capabilities. These will not overly burden the host processor, allowing it to quickly identify and defend against most common direct attacks and, more importantly, adapt to new ones.

It is also likely that firewalls, DPI functions, and pattern-matching logic will end up as hardware accelerator cores with the MCU, in much the same way that the compute-intensive algorithms behind the SSH/SSL protocols and commonly used encryption algorithms were offloaded to silicon over a decade ago. Many of the DPI and pattern-matching algorithms that would be used in embedded systems have already been refined and “siliconized” in network processors and traffic management silicon. It should be a relatively (for a given value of relative) straightforward task to scale down these architectures for use within the more limited confines of an MCU.