15 Apr 2016

Integrated Microcontroller Security

Rich Miron, Digi-Key Technical Content Team looks at the important issue of micro controller security as this topic has grown significantly in importance.

When security is under direct control, it’s an obvious aspect of everyday life; doors and windows are locked, valuables aren’t left in plain sight, and PINs are shielded when paying electronically.

But when that level of security isn’t under direct control, it becomes more complicated. This is true with embedded electronic devices, as they now implement some level of connectivity but have, historically, been 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. Security 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 it subsequently has access to.

Microcontroller Security Needs

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. As connectivity has proliferated, the diversity in hardware and software solutions makes security harder to impose, unless complete control of the platform is exclusively maintained (such as Apple). Even then, threats can never be entirely mitigated.

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 won’t take the form of a clumsy and unconvincing email stating a lottery win, but could come from an attack on the device’s resources by sending the device into a more vulnerable operating mode, or forcing it to question the integrity of its own data. Security is an issue for all.

These increasingly sophisticated attacks on security are leading integrated device manufacturers (IDMs) to invent and integrate evermore-sophisticated lines of defense.

Security Levels

The types of attack dictate the kind of security needed, and in embedded devices that 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, too. As a result, 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.

Microntroller Security Solutions

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).

Microcontroller security Memory Protection Unit

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, each of which may have different settings and privileges. The MPU implemented by Atmel in the SAM3S devices allows for 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.

Microcontroller security ARM Trustzone technology

Figure 2: ARM’s TrustZone technology can be implemented in a number of ways by licensees.

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).

Microcontroller security hardware-based encryption/decryption

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) and led to the introduction and recommendation of the Triple DES, which 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.


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 isn’t currently associated with more deeply embedded equipment. With connectivity, any device on a network can become a weak link in overall security.

Page 1 of 1

About the author

Rich Miron is Technical Content Engineer at Digi-Key Corporation in Thief River Falls, Minnesota. His previous experience includes a position as a Senior Engineer for the Bettis Atomic Power Laboratory outside Pittsburgh, Pennsylvania. His main task was the maintenance of manuals for reactor systems in US Navy nuclear ships and the examination and troubleshooting of instrumentation and control systems.

Digi-Key Corporation, based in Thief River Falls, Minn., is a global, full-service provider of both prototype/design and production quantities of electronic components, offering more than four million products from over 650 quality name-brand manufacturers. With over one million products in stock and an impressive selection of online resources, Digi-Key is committed to stocking the broadest range of electronic components in the industry and providing the best service possible to its customers.

Most popular articles in Processing & embedded

  • Deep Learning Challenges in Embedded Platforms
  • Choice: Microcontroller, MCU or Microprocessor, MPU
  • Embedded World 2017
  • Capacitive Proximity Sensing Technology Update
  • Bringing Windows 10 IoT Core to life
  • Share this page

    Want more like this? Register for our newsletter

    Securing the future of IoT | Rutronik
    Securing the future of IoT
    Co-authored by Bernd Hantsche, Head of the GDPR Team of Excellence and Marketing Director Embedded & Wireless and Richard Ward, ‎Semiconductor Marketing Manager at Rutronik.

    Radio-Electronics.com is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on Radio-Electronics.com, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy