Increasing Security Through Technologies Integrated into Microcontrollers

When security is under our direct control, it is an obvious aspect of everyday life; we lock doors and windows, we do not leave valuables in plain sight, and we shield our PIN when paying electronically. However, when that level of security is not under our direct control it becomes more obfuscated; it is unclear why security is needed and, in fact, how it is implemented.

Increasingly that is the scenario with embedded electronic devices, as they now implement some level of connectivity but have been historically immune to security issues.

Where connectivity exists covertly — such as in industrial equipment that is networked for productivity reasons, or medical devices that enable access to patient information — the danger may not be clear or, very often, even locally present. As connectivity is a global phenomenon, so too is the danger of remote attack, which increases security issues far beyond the immediate vicinity. Threats that may be initiated from the other side of the globe may specifically — or perhaps unintentionally — target benign devices and extend that threat to any other device to which it subsequently has access.

As a result, the Internet of Things is likely to promote the issue of embedded security far beyond local area networks or visible threats.

What is a security threat?

There are many aspects to security in electronic devices today. Predominantly, these can be categorized as threats to either content, intellectual property, or personal data. The trends behind the cost and benefits of adding connectivity are moving positively, but this is only possible thanks to another trend – the use of more diverse hardware solutions and the adoption of open source software.

While these are both, ostensibly, also positive, the effect is increased difficulty in guaranteeing security. When networking was first introduced, it was under the control of a small number of providers, which made the need for security almost moot. As connectivity has proliferated, the diversity in hardware and software solutions makes security harder to impose, unless you remain in complete control of your platform (such as Apple). Even then, threats can never be entirely mitigated. Security, therefore, is any method by which a threat can be curtailed or controlled. This accepts that threats cannot be entirely avoided but must, instead, have equal and preferably greater countermeasures.

Given that the ‘window’ of opportunity for threats — network access — is necessarily ‘open’, manufacturers must now implement hardware and software techniques that cannot only deter threats but also detect and defend against them.

It is now almost inevitable that any connected device, however obscure, will at some point be prone to a malicious attack of some kind. This will not take the form of a clumsy and unconvincing email stating it has won the lottery, but could come from an attack on the device’s resource sending it in to a more vulnerable operating mode, or forcing it to question the integrity of its own data. These increasingly sophisticated attacks are leading integrated device manufacturers (IDMs) to invent and integrate evermore-sophisticated lines of defense.

What level of security is needed?

As stated, the threat of attack is the real driver for increased security, as in all walks of life. The types of attack dictate the kind of security needed, and in embedded devices, this takes a number of forms.

At the software level, malicious software is and will likely always remain a major concern. Arguably, this threat is increasing with greater adoption of open source software, as it gives attackers the ability to examine the software for weaknesses.

If attackers are also able to examine the hardware platform their efforts could be doubled, so manufacturers now need to implement security at multiple points in the hardware architecture, as well. Most people are now familiar with the concept of a firewall — the name refers back to a physical barrier between two spaces, designed to inhibit the spread of fire. Today, the term is more commonly used to refer to the protection of a network against cyber-attacks and most routers incorporate a firewall of some kind, as do personal computers.

However, for the same reasons, firewalls are now also being deployed in embedded devices. An example of how firewall hardware can be incorporated into the smallest of microcontrollers (MCUs) can be found in Zilog’s ZGATE™ devices. Internet connectivity is increasingly used in remote devices for monitoring and control. The ZGATE family is designed for this application space, as it is supported by a full-featured TCP/IP stack, incorporating the underlying protocols such as IPv4, TCP, ARP and RARP. It also offers an FTP server and client and a command shell for remote debugging. These advanced networking features, which are typically vulnerable to attack, can be effectively secured through Zilog’s embedded Firewall technology. It offers static filtering, packet inspection, port, protocol and address limits, and threshold based filtering.

Beyond this, an actual physical attack can also deliver results without the need for intrusion, such as snooping or invoking glitches. These, too, now have hardware-based countermeasures. The kind of security countermeasures now being implemented in microcontrollers are based on a combination of industry-standard technology, supplier-specific technology and proprietary methods, designed to provide a level of security appropriate for the attacks most likely to be incurred by a device within a given application sphere. Banking terminals are, perhaps, more prone to ‘blunt’ attacks than, for instance, a piece of medical equipment, but the manufacturers of both will be making use of devices implementing some level of security countermeasures.

What’s the solution?

Many threats can either be avoided using, or attributed to, software; many MCU manufacturers have devised a solution to this based on protecting the content of a device’s memory from either unintentional or malevolent attack. The Memory Protection Unit found in Atmel’s SAM3S family, based on ARM®’s Cortex™-M3 core, is a case in point (Figure 1).

Figure 1: Atmel has implemented a Memory Protection Unit in its SAM3S family, providing a way of making software more secure.

As the Cortex-M3’s memory map is unified, both data and program instruction accesses have the same settings, but the core itself allows the memory to be partitioned into regions (with an additional ‘background’ region), each of which may have different settings and privileges. The MPU implemented by Atmel in the SAM3S devices allows memory regions to be defined by type, with a number of permissible attributes. These include types that define and control transaction order, as well as types that prohibit instruction execution. The memory region types supported include Code, SRAM, Peripheral and External RAM, while registers in the MPU define the accessibility to each type. This means memory accesses can be inhibited or used to invoke software reset, for example, which provides a level of security during execution.

For applications that need greater security, ARM developed its TrustZone® technology; a mixture of hardware and software features that licensees are able to implement and configure, to provide security or augment their own proprietary security features. TrustZone has been implemented as extensions to specific cores working in conjunction with hardware features present in the AMBA3 AXI bus fabric. This enables all the resources in the device to be partitioned into either what is termed the ’Normal World’ or the ‘Secure World’, creating a secure sub-system. In addition, the hardware extensions can allow a single core to operate as two virtual cores, using time slicing to move between the Normal and Secure Worlds.

While the technology is inherently flexible, ARM claims there are three main groups — or tiers — of solutions. Figure 2 shows a block diagram of TrustZone Tier Three, which delivers a DRM solution capable of supporting video streaming and on-the-fly decompression.

Figure 2: Licensees can implement ARM’s TrustZone technology in a number of ways.

A good example of this flexibility can be found in the Vybrid family from Freescale. It mixes TrustZone technology with bespoke features that comprise High Assurance Boot; Secure Storage; Hardware Cryptographic Accelerators; Secure Real-Time Clock; Hardware Firewalls; Secure JTAG, and Physical Tamper Detection.

For applications where security just means protecting data, cryptography is often the simplest and most reliable solution. This can be implemented in a variety of ways and often this may be in a ‘closed system’, where both receiver and transceiver are under the control of the developer. A good solution in this example could be Microchip’s KeeLoq cryptographic module, as implemented in the PIC12F635 and PIC16F636 families.

A more commonly deployed security element, particularly in MCUs, is the Advanced Encryption Standard (AES) and is frequently used to encrypt and decrypt data sent wirelessly. Silicon Labs has implemented an AES engine in its low-power C8051F96x family, which can support key lengths of 128-, 192- or 256-bits, where 128-bit keys provide the best performance. To increase the basic encryption offered by the AES state machine, a method dubbed Cipher Block Chaining Mode may be used. This means each block (16-bit) encryption becomes a function of the previous block, in addition to the current text/key used (see Figure 3).

Figure 3: Silicon Labs has developed an AES engine that provides hardware-based encryption/decryption.

A further development tackles some known issues with the original Data Encryption Standard (DES). The introduction and recommendation of the Triple DES offers several different modes of operation. The most common involves using two different keys, where the data is encrypted using the first key, decrypted using the second key and then re-encrypted using the first key. Different keys may also be used for each stage, leading to a three-key implementation.

Although DES and T-DES have now largely been replaced by AES, some microcontrollers can offer enough performance to implement T-DES in software alone, such as the PIC24, dsPIC and PIC32 families from Microchip. Microchip offers a software library for implementing both T-DES and AES algorithms, without the need for hardware acceleration.

Conclusion

As connectivity continues to pervade, it is becoming necessary to provide greater levels of security for both design and application data in a wider range of devices. The need for high levels of security in financial transactions may be largely obvious, but the same level of security is not currently associated with more deeply embedded equipment.

The general threat means it needs to be. With connectivity, any device on a network can become a weak link in overall security. The continued migration towards a cashless society is just one example of why total system security is necessary; paying for goods or services with a swipe of the hand may soon become commonplace, as NFC technology is rolled out in more guises. Fraudulent and malevolent activity can most effectively be challenged with increased levels of security. In the future, that will likely involve some kind of biometric interface, but until then we are reliant on the kind of technologies now being integrated into microcontrollers to protect us, our IP and our other valuables from the nefarious element of society.