By Alex Koepsel, IoT Marketing Manager, Silicon Labs

If you consider how much digital security has evolved in recent years, it is quite astonishing. Our mindset and social acceptance of what is “secure” has changed dramatically over time.

For example, before the adoption of ATMs for personal cash withdrawals, the only place you trusted to make cash transactions was your local bank. At the bank, the distance over which you communicated was the four feet of air between you and the glass-protected bank teller. Now, not only are physical trips to the bank rare, but ATMs and mobile banking apps are commonplace.

In fact, today, ATMs are now somewhat vintage, as most people are “Paypal-ing” or using other online transfer systems. You tap the grocery store’s point-of-sale (POS) system with your Apple Pay®, save your credit card information on most e-commerce websites, and make pre-approved payments to the unknown driver who you just met via Uber or Lyft.

It’s amazing how quickly our trust in these systems and digital security has evolved!

The same evolution of consumer trust in websites and apps is now happening in the realm of connected things. The growing imperative around security is now extending from cyber (cloud) security down to the hardware level (silicon). This is where embedded security comes into the story and provides a key link in granting both enterprise and consumer trust.

What is embedded security?

Also known as “device security,” embedded security can be boiled down to two major aspects – ensuring integrity and confidentiality.

• Integrity – How do you know the data you’re receiving is coming from a trusted place, and how do you know the data itself is authentic?
• Confidentiality – How do you protect your own data, intellectual property, and the safety mechanisms (keys) for those secrets?

Embedded security can help protect against real threats. Here are just a few:

• Distributed denial of service (DDoS) attacks – One of the most common attacks, where devices and IP addresses are hijacked to then flood other network servers to the point of temporarily shutting down.
• Counterfeiting – This includes both unauthorized duplicates and the overwriting of existing product firmware with a new unauthorized firmware image.
• Tampering – This could include physical tampering to extract keys or yield desired results such as incorrect meter readings. On the other hand, it could also involve electronics. Some devices can emit electromagnetic radiation that will unlock certain models of electronic door locks.

These are just a few examples. The threats are real and will only continue to grow and evolve.

Fortunately, your silicon and software suppliers can help you with many of the challenges of security. As shown in Figure 1, device security is one aspect that works together with cloud security, protocol security, and manufacturing security, when the device is created.

What Does this Evolution Mean for Businesses?

Businesses that are hoping to be sustainable for the next ten years and beyond should be evaluating their own products, systems, and threats. The goal is to assess the cost of a security breach versus the cost of implementing security solutions or barriers. It is commonly said that there is no “one size fits all” solution in digital security. However, let’s discuss some of the solutions you can use in your device.

Device Security Solutions Overview

Developer best practices

The first solution isn’t a product or feature – it’s simply taking the right decisions and precautions in product development from the start. There are many steps you can take without extra hardware or software. Here are some recommended practices for developers to follow:

• Review code for security issues, such as buffer overflows and unregulated input data
• Use third parties to test your device
• Lock debug interfaces
• Use built-in protocol security

Protective layers in memory

In addition to recommended developer practices, specific hardware and software features can help. A memory protection unit (MPU) is a common example that can enable protected areas in embedded memory to limit the effects of an attack. Other ICs also have security management units (SMU), offering more flexible and fine-grained protections that map to microcontroller peripherals.

The latest ARMv8 architectures incorporate TrustZone, which has the benefits of an MPU without the overhead of power consumption and latency. Read more about TrustZone on Arm’s website.

Built-in hardware accelerators for encryption and key generation

Encryption and key generation are also common security solutions. Almost all Internet of Things (IoT) applications should use some form of cryptography for encrypted data transfer. Rather than doing cryptography in software, devices may include built-in hardware modules that make this easy and increase device performance. Almost all microcontrollers (MCUs) now include hardware accelerators for cryptographic functions like AES and SHA hash functions.

Many MCUs also include Random Number Generators (RNG) for generating secure keys. A superset of RNGs offer even higher robustness, or “entropy,” and are then deemed True Random Number Generators (TRNG).

Aside from key generation, other hardware accelerators, such as a cyclic redundancy check (CRC), can help with code error-detection. The CRC can help with maintaining data integrity in some aspects of your device.

Debug and maintenance

If the embedded device were a house, the debug port would be the front door. It’s a necessary part of the device – for development, product creation, and the failure analysis of returned units. However, just like the opening to a home, it needs to be properly protected against inappropriate misuse.

There are many options when securing a debug port:

• Doing nothing (unlocked debug port) – Don’t do this! An unlocked debug port offers an unquestionably low level of security
• Permanent lock – Good security, but failure analysis (FA) is impossible
• Memory erase upon unlock – Protects data, but opens the device to new/fake malware
• Lock with global password – Protected port until the password leaks, at which point the entire IoT device fleet is compromised
• Lock with unique device password – Good security, but challenging to manufacture
• Lock with asymmetric key – Highest security, most flexible for FA

Root of Trust

So far, these solutions above are all great, but what if the software implementations become corrupted? It would quickly become a situation of the “fox guarding the henhouse”.

To avoid this situation, it is beneficial to validate the device’s contents against a Root of Trust (RoT). A Root of Trust doesn’t refer to one specific product or implementation but instead is a concept that can be satisfied by a few different implementations.

In embedded devices, this can be implemented with code and cryptographic keys that are stored in ROM or other immutable memory. A Secure Element (SE) can execute this process in isolated hardware. Secure elements come in both standalone (external) chip packages that connect to MCUs and built-in monolithic (on-die) elements. Still, the on-chip implementations are preferred as they provide greater levels of security and help reduce system cost.

Secure key storage

Protecting the secrecy of a system’s private key is critical. This begs the need for secure key storage, which then protects other secrets, such as intellectual property and private data.

Using a Secure Element (SE) is an excellent method for storing private keys. It provides an isolated and immutable memory location with limited access.

Furthermore, granting access to this key can be implemented with one final layer of hardware protection, a physically unclonable function (PUF). A PUF, which acts as a unique gate-level fingerprint of an MCU, is only active during the power-on boot sequence.  The uniqueness and volatility of its nature make a PUF an advanced way to give device-only access to a private key while keeping its exposure securely limited. This is a truly innovative and proven technology in the device security field.

DPA countermeasures and tamper detection

The previous examples are all great solutions for cyber/software attacks, which usually stem from remote locations. What if the hacker is within physical reach of the device? Some hackers can steal the device key by simply monitoring fluctuations in the power supply voltage during the key exchange process. This technique is called Differential Power Analysis (DPA).

This is where DPA countermeasures help. Some embedded devices can counteract DPA measurements by intentionally randomizing the power waveform. What may only take minutes to hack in products without DPA countermeasures might take several years with the advanced DPA countermeasure solutions.

In addition to countermeasures, some devices can detect anomalous changes in temperature or voltage and then alert the host interrupt handler. This is called tamper detection and is a unique feature beyond DPA countermeasures. Together, both features can add even higher security in products that protect valuable information and reside in places where people have physical access.

Finding the right solution 

As you can see, there is a lot to learn when it comes to security. Don’t be intimidated or overwhelmed by all these terms and potential threats. They might not apply to you and your system. Evaluating your own requirements is step one. Figure out which threats apply to your application. Weigh the threats and cost of those threats against the costs of implementing an embedded security solution.

Most importantly, work with various suppliers to see if they have a solution that fits. More security features are being added and integrated. These suppliers can provide wide-scale observations and insights to guide you. Then when it’s time to implement security layers, they can simplify that process with the right hardware, software, libraries, examples, and tools.

For example, Silicon Labs’ Series 1 Wireless Gecko devices offer built-in hardware security for Bluetooth, 802.15.4 mesh, and proprietary wireless applications. Security features include memory protection, error-code detection and correction, cryptographic accelerators, and debug control. These features provide a substantial amount of threat protection. The company’s new Series 2 portfolio offers even more security features such as additional crypto accelerators, Secure Boot with Root of Trust & Secure Loader (RTSL), Secure Debug with lock/unlock, and TrustZone from Arm.

This growing discussion around embedded security is just the tip of the iceberg. The need for silicon-to-cloud security is growing quickly. The faster that technology providers can provide cost-effective, easy-to-deploy solutions, the sooner connected things will meet the standards of secure payment apps. Then we can trust our wireless door locks, IP cameras monitoring our homes and families, and the enterprise devices that host secret and personal data.