The design of security for embedded systems is a critical and difficult task. Security requirements are often not fully identified at the beginning of the project. Once they have been identified they are not necessarily static and can change multiple times through the design cycle. One reason for changing security requirements is that the various cyber threats and threat vectors are constantly evolving. As a result, the ability to update system security software throughout a system’s operating life is an important design consideration. Encryption is a common element across all embedded system security designs.

The Advanced Encryption Standard (AES) is an algorithm used to encrypt and decrypt data to protect the data when it is transmitted electronically. AES supersedes the Data Encryption Standard (DES). The algorithm described by AES is a symmetric-key algorithm, meaning the same key is used for both encrypting and decrypting the data.

The AES algorithm allows for the use of cipher keys that are 128, 192, or 256 bits long to protect data in 16-byte blocks. AES is a U.S. Federal Information Processing Standards approved algorithm that is also approved for commercial and private applications. AES is widely used in a variety of applications. Data encryption is only one aspect of security design in embedded systems. There are firmware and software tools for enhancing embedded systems’ security against various threats and attack vectors.

Differential power analysis attacks

Differential power analysis (DPA) is a security attack which involves statistically analyzing power consumption measurements from a cryptosystem. The attack exploits varying power consumption of microprocessors or other hardware while performing operations using secret keys. DPA attacks have signal processing and error correction properties, which can extract secrets from measurements which contain too much noise to be analyzed using simple power analysis. Using DPA, an adversary can obtain secret keys by analyzing power consumption measurements from multiple cryptographic operations performed by a vulnerable smart card or other device.

Power analysis attacks cannot generally be detected by a device, since the adversary’s monitoring is normally passive. In addition, the attack is non-invasive. Some countermeasure strategies to protect against DPA attacks involve algorithmic modifications such that the cryptographic operations occur on data that is related to the actual value by some mathematical relationship that survives the cryptographic operation.

One approach involves blinding parameters to randomize their value. Other countermeasure strategies to reduce DPA attacks’ effectiveness involve hardware modifications: varying the chip internal clock frequency can be used to desynchronize electric signals.

Evaluation assurance level

The Evaluation Assurance Level (EAL) of an embedded device is a numerical value from 1 to 7 that is determined using an internationally standardized “Common Criteria” security evaluation. The higher the EAL levels, the more detailed the verification and testing requirements are outlined in the corresponding devices “Security Target” document. A higher EAL level does not necessarily identify a “more secure” device. It simply indicates more thorough testing and verification process. In the case of two devices having the same Security Target definitions, the higher rating device should be more trustworthy. EAL levels are defines as follows:

• EAL1: Functionally Tested
• EAL2: Structurally Tested
• EAL3: Methodically Tested and Checked
• EAL4: Methodically Designed, Tested, and Reviewed
• EAL5: Semiformally Designed and Tested
• EAL6: Semiformally Verified Design and Tested
• EAL7: Formally Verified Design and Tested

The EAL requirements can also be augmented to include assurance requirements more extensive than the minimum needed for a given EAL. Augmented EALs can be indicated using the word “augmented” or using a “plus” sign as in EAL5+.

For example, STMicroelectronics offers its STSAFE-A110 Secure Element that can protect consumer and industrial connected devices in the Internet of Things (IoT), preventing the counterfeiting of genuine products by strictly assuring their authenticity. The device features an embedded secure operating system and is based on hardware that is certified to Common Criteria EAL5+. Each unit comes with a unique identification and X.509 certificates that aids secure device connection. STSAFE-A110 is designed for use as brand protection for components like consumables, accessories, power-tool batteries, and the authentication of cloud-connected IoT devices such as vending machines, farm implements, etc. environmental sensors.

Secure boot configurations

In addition to hardware-based security devices such as the STSAFE-A100 described above, there are software and firmware tools for enhancing the security of embedded devices. Secure boot is a feature in the Unified Extensible Firmware Interface (UEFI) 2.3.1 specification. Secure boot defines an interface between the operating system and firmware/BIOS. Secure boot can detect tampering with boot loaders, key operating system files, and unauthorized option ROMs by validating their digital signatures. Detections are blocked from running before they can attack or infect the system.

For example, the PSoC 64 Secure MCUs from the Cypress subsidiary of Infineon Technologies is embedded with a Cypress-owned Root of Trust (RoT) when it comes out of the factory. This RoT is based on a public key that is owned by Cypress. When an OEM customer purchases devices, there is a secure process to transfer the RoT to the OEM. This process replaces the Cypress public key with the OEM’s public key. From that point on, the OEM “owns” the device, and the secure device will only accept any further security-related interaction if it is appropriately signed by the OEM. To work with Secure devices, the designer provides three “things”:

• A set of cryptographic keys, the public key of which will be used for validating OEM application firmware
• A set of security policies that define how the secure chip should behave
• Certificates (optional) used to bind device identity or provide a chain-of-trust to a higher certifying authority

This information, along with the bootloader, is securely injected into the device before the firmware is programmed. The process is called provisioning. The information provides the rules that the ROM boot code follows when launching the bootloader and provides the resources required to verify the code’s authenticity. The designer develops the software to run on the device and digitally signs the application using a private key that corresponds to the device’s keys. With policies and keys in place, the ROM boot code verifies the bootloader, which verifies the signature and the integrity of any code before launching it.

This was the second article in a three-part FAQ series on embedded system design. The first article looked at managing power consumption and dissipation in embedded systems for a greener world. The third and final article in this series will look at embedded systems software and programming for a safer world.

References:

Advanced Encryption Standard, Silicon Laboratories
Differential Power Analysis Countermeasures, Silicon Laboratories
Evaluation Assurance Level, Wikipedia
Power analysis, Wikipedia
Security for the Connected World, Renesas