Trusted MCUs for IoT applications
October 16, 2017
Secure MCUs should offer multiple levels of security elements to support various security algorithms like AES, DES, and SHA.
As IoT technology continues to make our lives more comfortable through greater intelligence enabled by networking smart devices, it becomes increasingly important to protect the information stored and transmitted by these devices. Embedded MCUs are at the core of IoT-based products, and selecting the right MCU is key to meeting the present and future needs of your customers.
An MCU designed for IoT applications needs to have sufficient processing capabilities, hardware-based security, and software algorithms to provide a safe and secure solution. Secure MCUs should offer multiple levels of security elements to support various security algorithms like Advanced Encryption Standard (AES), Data Encryption Standard (DES), and Secure Hash Algorithm (SHA). The MCU needs to provide a complete chain of security, secure boot process, hardware-based root of trust, true random number generation functionality in hardware, and user application code authentication, among other capabilities. Developers also need to consider that when security features are implemented in hardware, less time and energy is required compared to equivalent firmware implementations. This article highlights the key security capabilities an MCU needs in order to give developers a solid foundation for designing secure IoT systems.
[Figure 1 | Layers of security]
Secure boot
Secure boot process is the most critical element supported by secure embedded MCUs. It is a boot process that ensures that only authenticated code is executed on a device. Secure boot helps prevent malicious and unauthorized code from being loaded into a device during the system start-up process. Embedded MCUs using Flash memory to store their firmware can take advantage of a secure boot process to ensure that firmware code cannot be modified by unauthorized users. Secure boot protects a system by adding cryptographic checks to the boot process and can be implemented in many ways, including digital signatures, trusted flash loaders, encryption of the boot file, etc. Application firmware authentication is an important part of secure boot.
Secure boot employs a chain of trust methodology (see Figure 1). It begins with a secure root such as non-modifiable code in ROM or Flash that is trusted by the device. This code then authenticates another piece of code. The newly authenticated code authenticates any subsequent code and so on, creating the chain of trust. It works simply like this: you trust A, and A trusts B, so you trust B.
[Figure 2 | Chain of security implementation]
To illustrate building the chain of trust concept, consider this sequence (see Figure 2) which is used to implement a chain of trust using the PSoC 6 BLE, an embedded MCU from Cypress designed for IoT applications:
- The root of trust code is in ROM code so it cannot be modified. The root authenticates the Flash boot code stored in Supervisory Flash (SFlash) using AES-CMAC message authentication.
- Control is passed to the Flash boot code once it is authenticated successfully. Now the Flash boot is part of the chain of trust in the secure boot process.
- The Flash boot code verifies the user application stored in the main Flash using a digital signature.
- Control is transferred to the application once the digital signature has been successfully verified.
Secure boot uses ROM routines to authenticate user data in Flash. A secure boot is a process involving cryptography that allows an IoT device to start executing authenticated and therefore trusted software. This ensures that the system powers on from a known, trusted state. The secure boot flow requires in two steps. In the first step, the ROM boot authenticates the Flash boot by comparing the encrypted code stored in the eFuse to compute the encrypted value. In the second step, the Flash boot verifies the digital signatures of the Application using the public key stored in the SFLASH.
Hardware-based security
For many IoT applications, security is just one consideration that has to be balanced with energy efficiency, reliability, and low cost. In many cases, a hardware-based approach provides the most efficient, reliable, and cost effective way to ensure security. Hardware consumes less power than equivalent software methods using the main processor. Another issue with software-based security is that IP can be stolen without hardware-based security using integrated circuitry to protect the system. This is just one of the reasons MCUs for IoT applications have sophisticated integrated hardware security features such as cryptography blocks, code protection IP, and other hardware-based mechanisms.
Hardware-based security also eliminates the need to apply software patches to continuously secure a system. Hardware-based security also has the added benefit of providing faster performance with lower power consumption compared to firmware implementations. For example, the IoT processor showing in Figure 3 has a cryptographic block that provides hardware implementation and acceleration of cryptographic functions. Data to be transmitted is encrypted using a cryptographic algorithm before transmission. Access to this cryptographic block is allowed only using inter-processor calls and direct access at register level is not permitted to ensure security. This cryptographic hardware block performs important functions like:
- Symmetric key encryption and decryption
- SHAs
- Message authentication code (MAC) functions
- True and pseudo random number
- Cyclic redundancy check (CRC)
- Various utility functions such as enable/disable, interrupt settings, flags etc
[Figure 3 | Programmable SoC architecture with cryptographic hardware and secure boot]
Symmetric key encryption and decryption
Creating and managing keys is an important part of the cryptographic process. With symmetric keys, the same key is used for both encryption and decryption. The AES is an example of a symmetric key encryption method.
AES functionality includes a block cipher and an inverse block cipher per the AES standard. The block cipher (AES instruction) encrypts a 128-bit block of plaintext data into a 128-bit block of ciphertext data. The inverse block cipher (AES_INV instruction) decrypts a 128-bit block of ciphertext data into a 128-bit block of plaintext data.
Secure Hash Algorithms
Hashing is a type of algorithm which takes any size of data and turns it into a fixed-length of data. The main difference between hashing and encryption is that a hash is not reversible. The SHA is a family of cryptographic hash functions to keep data secured (see Figure 4). SHA consists of bitwise operations, modular additions, and compression functions. This function takes a message of arbitrary length and reduces it to a fixed length residue or message digest after performing a series of mathematically-defined operations, which guarantee that any change in the message will change the hash value. It is used for message authentication by transmitting a message with a hash value appended to it and recalculating the message hash value using the same algorithm at the recipient's end. If the hashes differ then the message is corrupted. These algorithms are used with the Digital Signature Algorithm (DSA) or the Digital Signature Standard (DSS).
[Figure 4 | SHA Example]
Message authentication code functions
MAC schemes use a secret key along with the message (see Figure 5). The recipient must know the key to be able to compute the MAC value. This helps the recipient of the message to authenticate that the sender of the message has the shared secret key and that no one without the key has sent or altered the message. First, a MAC value is computed by the sender and appended it to the transmitted message. When the message is received, the MAC is computed again and checked against the MAC value transmitted with the message. If they do not match, then the receiver knows the message has been altered. An example of a hash algorithm are the SHAs and they can be used to produce the MAC value. Even a block cipher such as AES can be used to produce the MAC value. The MAC methodology guarantees both data integrity as well authenticity.
[Figure 5 | MAC example]
True random number generation
True random number generation (TRNG) is an important cryptographic function. A TRNG block generates a number that is statistically random and based on some physical random variation that cannot be duplicated by running the process again. Compare this to Pseudo Random Number Generation (PSRNG), which is not truly random since it relies on an initial seed value. If the seed can be duplicated, the generated sequence can be duplicated as well. Highly secure systems will utilize true random rather than pseudo random number generation. Currently, few MCUs provide hardware-based TRNG. There are applications where a PSRNG may be preferred, so an MCU that has both TRNG and PSRNG provides the most flexibility.
External memory security
To support greater intelligence and applications, IoT systems are needing more and more memory. MCU vendors are careful to provide an optimal level of internal memory as the die size increases based on memory, driving cost up as well. To meet this ever growing demand of memory size, MCU vendors provide the option to expand memory externally. This helps IoT designers to design to the memory size of their choice based on application requirements. However, this introduces the challenge of securing sensitive code and data stored in external memory and ensuring it can only be accessed by an authenticate user.
To secure external data and code, MCUs support cryptographic functions with external memory interfaces. Thus, data can be encrypted before being stored in external memory devices. Similarly, data is decrypted when it is retrieved. Figure 6 shows a secure MCU where the Serial Memory Interface (SMIF) has built-in cryptographic capabilities to secure data when it is written to external memory.
[Figure 6 | Serial memory interface (SMIF) block in MCU architecture]
Figure 7 shows SMIF execute-in-place (XIP) mode. This is where a cryptography component supports on-the-fly encryption for data writes and on-the-fly decryption for data reads. This ensures that no leakage of sensitive data can occur when data is encrypted before storage in the external memory device.
[Figure 7 | Example of SMIF in XIP mode]
Communication layer security
Bluetooth Low Energy (BLE) is one of the most popular wireless standard for IoT applications. IoT designers must ensure that data communication is secure over the wireless link. The latest BLE protocol update comes equipped with several security and privacy capabilities to cover encryption, trust, data integrity, and privacy of the user’s data. For example, the BLE link layer provides various encryption algorithms such as CRC and AES for robust and secure data exchange (see Figure 8). BLE radios must also be designed to support these BLE secure functions provided by the BLE protocol. Enhanced encryption and authentication will allow only trusted users to track device locations and to confidently pair the devices.
[Figure 8 | PSoC 6 BLE – BLE subsystem block diagram]
