Devices in the Cloud

Protecting the Internet of Tiny Things: Embedded Firewall Can Secure an 8-Bit MCU

Very small—and often critical—devices are now connected to the web and controlled by 8-bit MCUs. Implementing security for these devices can be a challenge given their often limited resources.


  • Page 1 of 1
    Bookmark and Share

Article Media

8-bit MCUs are increasingly used to build small Internet connected devices. Devices such as home automation sensing and control units, utility meters, traffic lights and remote sensors make up a portion of the Internet of Things that we can refer to as “The Internet of Tiny Things.” 

While these devices are characterized by minimal processing resources, they include a TCP/IP stack and utilize the Internet for reporting, configuration and control functions. As their numbers skyrocket, so have the number of cyber-attacks targeting these devices. Despite the growing threat from hackers, few devices include robust, multi-layered security to protect against attacks. This is particularly true in the most resource-constrained devices.  

An 8-bit MCU is often selected to meet bill of materials cost requirements, resulting in devices that are resource constrained but often still require sophisticated functionality. Adding communication that requires deterministic timing can be challenging on an 8-bit MCU. Security protocols and encryption are complex and resource intensive, and adding them to an 8-bit MCU may not be practical or even possible. Engineers are forced to forgo security protocols or select a larger, faster and more expensive processor for their design. A faster processor and the additional engineering time to implement security protocols often cannot be justified in cost-sensitive designs characterizing this segment of the market. Due to these constraints, many devices built using an 8-bit MCU do not support any security beyond password authentication.  

In addition to being resource intensive, security protocols only protect the encrypted channel, leaving the device vulnerable to insider attacks, denial-of-service (DoS) attacks and attacks on non-encrypted protocols. Password authentication is easy to implement, but short of any other protection, does not provide an adequate defense against attacks.

The embedded marketplace needs a resource-friendly security solution specifically designed to provide sensible defensive capabilities against a variety of Internet-based attacks. Embedded firewalls provide a solution. The firewall is integrated directly into the communication stack at the link layer of the supported protocol and configured with a set of rules specifying what communication is allowed. For TCP/IP, those rules block packets by IP address, port, protocol and other criteria. The integrated firewall (embedded firewall) provides a basic but critical level of security by controlling what packets or messages are processed. Because each packet or message is filtered before passing from the protocol stack to the application, many attacks are blocked before a connection is even established. The result is an effective layer of protection with minimal impact on system resources. 

How a Firewall Protects against Attacks

An embedded firewall enforces a set of rules or policies that govern who the device can talk to, what protocols and ports can be used, and who can initiate communication with the device. Embedded devices typically have very well-defined communication requirements, only supporting a small number of protocols and ports and in many cases only communicating with a limited number of devices/IP addresses. Some embedded devices need the ability to communicate with any IP address, but even then communication is usually limited to one or two protocols and ports that are open to the world. 

These well-defined communication requirements allow the creation of restrictive firewall policies. The firewall enforces policies by filtering packets as they are received, comparing each packet to the policies, and blocking anything not matching the communication policies (Figure 1).  

Figure 1
By enforcing firewall policies, packets from non-trusted senders are dropped, blocking cyber-attacks.

By only allowing packets meeting communication polices, most cyber-attacks are blocked. A hacker attempting to login to the device is blocked because their IP address is unauthorized. DoS attacks and many other cyber-attacks will also be blocked because they use ports or protocols blocked by the firewall, or because they originate from an IP address not allowed by the policies. When combined with password authentication, this creates an effective, resource-friendly defense against cyber-attacks. 

MCU Operating System and Protocol Requirements

To provide an effective platform for building a secure, connected device, the MCU must provide an underlying operating system and communication protocols. The system must be customizable for specific applications and yet maintain deterministic timing of protocol implementations. 

The operating system manages resources, including the peripherals of the MCU. To provide allocation, sharing and control within the constraints of the limited resources, the operating system must be designed and optimized for the 8-bit MCU. Of course, the operating system needs to be reliable and fault tolerant.  

There are typically many sub-programs (threads) that need to run at the same time, such as receiving, processing and responding to multiple requests and handling the peripheral interactions. To handle these requirements and provide flexibility, the operating system will offload the work to different threads and only implement generic event-driven, sharing and priority level algorithms. To optimize MCU processing, the operating systems will implement a scheduling algorithm for allocating processing time between multiple threads. For threads to communicate, the operating system provides messaging, mutually exclusive control and semaphore handling.  

Internet protocols are industry standards for communications between many different vendors and systems. These are typically implemented through separate threads. The threads handle all the receiving, processing and responses are per the protocol specifications. There are different protocols for different applications, such as FTP, TCP/IP, SNMP, etc. Each protocol has its own specification and typically a device will support multiple protocols.  

Protocols require substantial resources so they must be optimized for an 8-bit MCU. Developing and testing the operating system and protocols can be extremely difficult and time consuming. Solutions developed for Linux or even 16- and 32-bit RTOSs often won’t scale to an 8-bit MCU. An 8-bit MCU with an integrated OS and protocols speeds development time and allows engineers to focus on the unique capabilities of their device.  

Implementing a Firewall on an 8-Bit MCU

There are numerous factors to consider when implementing a firewall on an 8-bit MCU. The firewall, like the communication protocols, needs to be designed specifically for the trade-offs of a small MCU. The time required to create a “home-grown” solution is extensive and costly.  

The first consideration is how the firewall rules will be maintained and updated. The firewall rules typically need to be modified either at the factory or in the field for a particular customer application. Factory settings can be achieved using a configuration file written to Flash memory. If the configuration needs to be modified in the field, the MCU must provide a remote configuration interface such as a command line, web or SNMP interface. It is critical that the configuration interface be secure. If a hacker can compromise the firewall configuration they can reconfigure the firewall to allow an attack or even disable it.  

Given the resource constraints of the system, care must be exercised in the implementation of the rules engine and rules database to ensure an optimal trade-off between memory usage and performance.  The rules must be stored in a format that does not waste memory while allowing efficient processing by the rules engine. A simple lookup table indexed by port or protocol provides optimal performance. However, because of the large number of possible ports and protocols, this approach could strain or overrun the memory resources of an 8-bit MCU based system. Possible solutions include using sparse table data structures such as a hash table or balanced binary tree, or limiting the number of rules supported by the firewall. 

The firewall filters packets as they are received, blocking unwanted packets, unfriendly login attempts and DoS attacks before authentication is allowed to begin. One or more methods are implemented by the filtering engine to enforce firewall policies and block Internet-based attacks. Common filtering methods are:

• Dynamic Filtering – The dynamic filtering engine performs Stateful Packet Inspection (SPI) by maintaining information regarding the state of each connection and using that information when making filtering decisions. SPI provides protection against packets received with invalid TCP state information, a common web-based attack. SPI can also be used to create a “lockdown mode” where all connections must originate from the embedded device.

Static filtering – The static filtering engine compares each packet to a set of static rules determining if the packet is blocked or allowed. All decisions are made based on the information in the packet. Rules-based filtering enforces policies by blocking unused protocols, closing unused ports, and enforcing IP address whitelists and blacklists. For some devices, rules-based filtering is all that’s required. Other devices require more advanced filtering.  

Threshold-based filtering – The threshold filtering engine maintains statistics on received packets and monitors threshold crossings to detect packet flood DoS attacks. Threshold-based filtering is complex and may require more system processing time and memory than some 8-bit MCUs can handle, but it provides a powerful tool for detecting packet flood DoS attacks. 

Firewalls provide the framework to implement security on tiny Internet devices. The firewall depends on properly defined policies allowing required communication and blocking all other communication. Defining the embedded device’s communication requirements is the first step that includes: 

• With what other systems will the device communicate?

• What communication services are provided for these systems? 

Can the other devices be grouped into sets of users that require the same services?  

Once the communication requirements are specified, they are coded as a set of rules. The rules specify the IP addresses, ports and protocols used by the device to communicate with other network nodes. For some devices the communication requirements are very well defined and restricted. Other devices require broader communication capabilities, resulting in broader, but not necessarily less secure, firewall rules.   

Consider an embedded sensing and control device logging information and performing a control function. Such a device might be found on a factory floor, or as part of the electrical grid. The device provides communication protocols supporting three different user groups. A web interface allows administrative users to view collected information and make configuration updates to the device. A machine-to-machine interface over UDP/IP enables other devices to collect data from the device and control output and switching levels. For this device, the communication rules would look like Table 1. 

Table 1
A general example of a set of communication rules.

Other types of devices will have very different communication requirements and different policies. A network print server would typically accept print jobs from any user while accepting firmware and configuration updates from only a small number of administrative users. The policies for a print server may look like Table 2. 

Table 2
Communication rules that might be used for a network print server.

The communication policies defined for the device need to be encoded as firewall rules. The syntax of the firewall rules is dependent upon the specific firewall in use. The rules define each user group in terms of the IP address for the group and define the protocols and ports allowable for each group. For the example smart grid control and reporting device, the rule set would look like this:

RULE 1: Administrative users supporting HTTP over TCP   

IP = { –}, protocol/port = {6, 80} 

RULE 2: Control users supporting a private port over UDP

IP = { –}, protocol/port = {17, 1170} 

RULE 3: Data readers, supporting a private port over UDP 

IP = { –}, protocol/port = {17, 1171} 

The rule set for the network print server would look like this:

RULE 1: Administrative users supporting HTTP and a private port for firmware upgrades over TCP

IP = { –}, protocol/port = {6, 80; 6, 1030} 

RULE 2: Printer users.  Allows any user to send print jobs over TCP to the print server

IP = {ANY}, protocol/port = {6, 35; 6,170; 6,515} 

All packets received by the device are passed to the firewall for filtering and compared to the firewall rules. Packets not matching the firewall rules are dropped. As a result, attempts to hack into the device are blocked before a connection is even established.  

Zilog and Icon Labs have teamed up to provide a solution to the problems and constraints of implementing security for devices built using 8-bit MCUs. Zilog provides the MCU, an integrated, preemptive multitasking operating system and set of TCP/IP protocols. Icon Labs’ Floodgate firewall is integrated on the MCU and provides rules-based filtering, SPI and threshold-based filtering all in one system. The solution is optimized for the 8-bit MCU and provides remote configuration of firewall policies using a CLI or web interface. The firewall controls the packets the embedded system processes and blocks invalid login attempts, denial of service attacks, packet floods, port scans and other common Internet-based threats.  


Icon Labs
Des Moines, IA.
(515) 226-3443.

Milpitas, CA.
(408) 457-9000.