An embedded system is an electronic product that comprises a microprocessor or multiple microprocessors executing software instructions stored on a memory module to perform an essential function or functions within a larger entity.

1.1.2 What Is Embedded Security?

Considering securing entity as an embedded system that takes degree of measure to offer degree of resistance to, or protection from harming the resources of the overall system, to which either the embedded system is:

• – connected, or
• – in which it is subsumed.

1.2.1 Embedded Systems Complexity

With ever-growing demands for enhanced capability, increased digitization of new manual and mechanical functions, and turning dumb embedded devices into smart ones via interconnectivity, the complexity of the embedded system is increasing. Although these electronic complexities bring betterment to mankind they also bring security vulnerabilities.

The vulnerability of security cannot necessarily be attributed to electronic complexity if such complexity can be effectively managed.

Complexity gives birth to flaws, which are later misused to circumvent system security.

Complexity cannot only be measured by code size or transistor count. Let’s take few examples to understand it better:

1. 1. Software complexities
   1. a. Deciding to use Linux in systems which require higher security levels is debatable.
      1. i. The open-source nature of the Linux code is considered its strength as the code gets greater exposure and is reviewed by the worldwide community.
      2. ii. Linux has its disadvantages too, as the code undergoes continuous modification which can lead to the introduction of vulnerabilities.
2. 2. Hardware complexities
   1. a. Network connectivity to embedded systems.
      1. i. Traditionally, by not being connected, embedded systems were immune to the risks associated with the Internet.
      2. ii. Nowadays, there is a growing need for remote management of devices and device life cycle management.
   2. b. Embedded system consolidations.
      • There is a growing trend to have single, powerful embedded systems performing multiple tasks or components, in order:
        • • To have better interworking between them.
        • • To save costs in some cases.
      • Doing so, typically leads to mixing of high-security tasks with tasks that are low security of not security critical.

1.3.1 CIA Triad and Isolation Execution

Each of the defined security policies can be mapped to one, two, or all three of the CIA Triad:

1. 1. Confidentiality: restrict access to authorized and authentic users only.
2. 2. Integrity: resources should be protected against any modification done:
   1. a. intentionally by unauthorized users.
   2. b. unintentionally by authorized/authentic users.
3. 3. Availability: resources should be always accessible for intended usage.

To minimize the impact of a violation of security policy, another aspect is added to the CIA Triad, called isolation (Fig. 1).

If the CIA Triad is broken on one isolated execution plane it will not hamper the CIA Triad on the other isolated execution planes.

1.3.2 Policies for Information Flow Between Isolation Execution

There can be separate security policies governing the communication between two isolated execution planes. Security policies depend on the following questions:

• • Is communication allowed?
• • What information can be exchanged or accessed?

1.3.3 Physical Security Policies

Physical security policies are security policies detailing countermeasures to the physical threat to embedded systems.

2.1.1 How to Solve This Problem?

Alice and Bob can encode/encrypt the data while sending and decode/decrypt the data upon receiving. This would block the illegitimate user Eve from decoding the data sent over the unsecure channel. This technique is called cryptography. Cryptography refers to communication techniques derived from mathematical concepts and a set of rule-based calculations, called algorithms, to transform messages in ways that are hard to decipher, for secure communication (Fig. 4).

In an ideal world, Alice and Bob should keep secret the algorithm/technique used to encrypt and decrypt the data, so that Eve can not decode it. Keeping the algorithm secret is neither sensible nor practical. Moreover, making the algorithm public hardens it by allowing cryptoanalysts to evaluate and challenge the algorithm. Using an algorithm which is publicly unannounced is never recommended (Fig. 5).

However, now that the algorithm used to obfuscate the data is public, we need ways to prevent Eve from decrypting the message. The solution is that Alice and Bob should have a preshared secret which Eve is unaware of. This preshared secret is called the key to the algorithm. The security of this key is paramount (Fig. 6).

With the unavailability of the key to Eve, her next action is to use brute-force techniques.

2.2.1 Kerckhoffs’s Principle

A cryptosystem is deemed secure even if every detail about the cryptosystem is public knowledge, except the keys (https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle).

2.3.1 Symmetric Cryptography

Symmetric cryptography uses a single key for encryption and decryption. It is mainly deployed in scenarios which require privacy and confidentiality.

The biggest difficulty to this approach is the distribution of the key.

Symmetric cryptography can be further categorized into stream ciphers and block ciphers.

2.3.2 Asymmetric Cryptography

Asymmetric cryptography uses one key for encryption and another for decryption. It is usually used for cases which require authentication, key exchange, and nonrepudiation. This cryptography scheme is also referred to as public key cryptography.

In this type of cipher, a pair of keys is used to encrypt and decrypt the data. The key pair consists of two unidentical large numbers, where one of the keys can be shared with everyone, called the public key, and the other part, which is never shared, is called the private key.

A digital signature scheme can also be implemented using public key cryptography. This scheme has two algorithms, one for signing and the other for verification. Signing requires the use of a secret/private key while verification is done using a matching public key. RSA and DSA are two popular digital signature schemes.

These algorithms are computationally expensive. The hardness of RSA comes from its integer factorization while the hardness of DSA is related to a discrete logarithmic problem. More recently, elliptic curve cryptography (ECC) has been developed and is gaining traction over the RSA algorithm for the following two reasons:

• • with the same key sizes, ECC provides a higher cryptographic strength compared with RSA.
• • for the same cryptographic strength, the ECC key size is smaller than that of RSA.

2.3.3 Hash Functions

Hash functions use mathematical transformations to irreversibly encrypt information without the usage of any key. These are usually used for cases where message integrity is required, for example, the digital fingerprint of a file’s content and encryption of passwords. These functions are also called message digests or one-way encryptions. Some popular examples of hash functions are:

• • SHA (Secure Hash algorithm), SHA1., SHA256.
• • MD (Message Digest Algorithm), MD2, MD4, MD5.

3.1.1 Design

One of the important aspects during the design phase of an embedded product is to get the requirements right. “Threat modeling” helps define the security requirements for an embedded product. We will look in detail at how to do a risk assessment, followed by threat modeling, in the next section.

It is important to keep the design as simple and small as possible. Complex designs increase the likelihood that errors will be made during implementation, configuration, and use. Additionally, the effort required to achieve an appropriate level of assurance increases dramatically as security mechanisms become more complex.

3.1.3 Secure Testing and Verification

A comprehensive test suite that includes functional, performance, regression, and coverage testing is well known to be one of the best mechanisms to assure software is reliable and secure.

Before final penetration tests are performed by specialized teams, a formal security evaluation stage is needed. This is accomplished through dynamic runtime testing methods [1, 2], for example, fault injection systems can also be used to check for the presence of flaws.

4.1.1 Modeling Threat Analysis

Hunter et al. [3] demonstrate an iterative threat modeling flow for an embedded system. Initially, the first point of weakness and attack needs to be identified. This is followed by a detailed review of security requirements and objectives. Next, modeling must occur for each security requirement, considering the three points of view of an attack scenario discussed above, that is, asset, attacker, and mitigation/defense built in to address the threat. Both the modeling of the specific security requirements and system objects are then iteratively evaluated until a high level of certainty is reached that the model developed provides adequate security against the identified threats and that no new vulnerabilities have been introduced.

4.2.1 Physical Tampering

There are several ways an attacker, who has physical access to a system, may tamper with it. This tampering can be used to extract secret information or destroy the device. Methods used to achieve this include removing or adding material to the IC to access information. Etching or FIB can be used to remove such materials. Optical inspection can be carried out to read internal signals, probe bus, or memory to extract secret information.

The goal of achieving tamper resistance is to prevent any attempt by an attacker to perform an unauthorized physical or electronic action against the device. Tamper mechanisms are divided into four groups: resistance, evidence, detection, and response. Tamper mechanisms are most effectively used in layers to prevent access to any critical components. They are the primary facet of physical security for embedded systems and must be properly implemented to be successful. From the design perspective, the costs of a successful attack should outweigh the potential rewards.

Specialized materials are used in tamper resistance to make access to the physical components of a device difficult. These include features such as locks, encapsulation, hardened-steel enclosures, or sealing.

Tamper evidence helps ensure that visible evidence is left after tampering has occurred. This can include special seals and tapes which area easily broken, making it obvious that the system has been physically tampered with.

Tamper detection enables hardware devices to be aware they are being tampered with. Sensors, switches, or circuitry can be used for this purpose.

Tamper responses are the countermeasures enacted upon detection of tampering. Measures that can be taken by hardware devices include deletion of secret information and shutting down to prevent an attacker from accessing information.

4.2.2 Side-Channel Attacks

Side-channel attacks are typically noninvasive attacks where things like timing information, power consumption, or electromagnetic radiation from the system can be used to extract secret information. As the name suggests, an attacker does not tamper with the device under attack in any way but uses side channels, observations to mount a successful attack. The observation can be made either remotely or physically, using the right tools. The most common side-channel attacks are architectural/cache, timing, power dissipation, and electromagnetic-emission attacks. Let’s try and understand these attacks in a little detail to appreciate how secrets can be extracted using these side channels. The underlying idea of SCAs is to look at the way cryptographic algorithms are implemented, rather than looking at the algorithm itself.

SCAs can be instigated because it is possible to find a correlation between the physical measurements taken during computations and the internal state of an embedded device, which itself is related to a secret key. It is this correlation—with a secret key—that the SCA tries to find.

The power consumption of a device can provide information about the operations that take place and the parameters involved. An attack of this type is applicable only to the hardware implementation of cryptographic algorithms. Such attacks can be divided into two categories—Simple Power Analysis and Differential Power Analysis (SPA and DPA) attacks. In SPA attacks, the attacker wants to essentially guess from the power trace which instruction is being executed at a certain time and what values the input and output have. Therefore attackers need precise knowledge about implementation to mount such an attack. The DPA attack does not need knowledge about implementation details and alternatively exploits statistical methods in the analysis process. DPA is one of the most powerful SCAs that can be mounted, using very few resources. These attacks were introduced by Kocher et al. in 1999 [5]. In this particular case DES implementation in the hardware was under attack.

Popular countermeasures against SCAs include masking and hiding. With masking the line is broken between the processed and algorithmic intermediate value. This means that an intermediate value can be masked by a random number. To remove the mask, changes must be tracked through operations. Such a mask is not predictable and is not known to an attacker. Masking can be done at the architectural or chip level.

“Hiding” helps break the link between processed intermediate values and emitted side-channel information. It tries to make the power consumption of a device independent of the processed intermediates. There are two different strategies adopted for hiding:

• • Random power consumption in each clock cycle (SW and HW).
• • Equal power consumption in each clock cycle (mainly in HW).

No perfect solution has been found so far for hiding. A list of countermeasures proposed by various authors is available for the further study of this topic [6].

4.2.3 Timing Attacks

Timing attacks are popular and occur when the time taken by cryptographic operations can be used to derive a secret. Cryptographic implementation can be done via hardware or software libraries—both implementation types are vulnerable to this kind of attack.

OpenSSL is a popular crypto library which is often used in Linux web servers to provide SSL functions. Brumley and Boneh [7] demonstrated that timing attacks can reveal RSA private keys from an OpenSSL-based web server over a local network.

In recent times there have been cross-VM timing attacks on OpenSSL AES implementations [8, 9]. Here cache Flush + Reload measurements were used. This type of attack takes advantage of the fact that the executable section of the code is shared between processes. When a process is run for the first time, the operating system loads the process into physical memory. If another use launches the same process for a second time, the operating system will set the page tables for the second process to use the copy that was loaded into memory for the first process. Here, by calculating the time it takes to access any data in shared memory, it is possible to determine if another process accessed it.

In the Flush + Reload attack, both the attacker and victim have some shared memory mapped into their own virtual space. The attacker flushes the lines it is interested in, waits for some clock cycles, and then calculates the time it takes to read those lines again. If the read is fast, it means that the victim’s process accessed these lines. These lines can be either in the code area of the victim or some other data the attacker is interested in.

One possible countermeasure for these attacks is to adopt timing- invariant implementation of the algorithms in the hardware as well as the software.

In recent times, these cache attacks have been used in the popular Meltdown and Specter attacks. We will discuss in more detail the Meltdown and Specter attacks in a case study later in this chapter.

4.2.4 Fault Injection Attacks

Fault attacks are active attacks against cryptographic algorithms where the hardware is exposed to random and rare hardware and software computation faults. These faults result in errors which in turn can be used to expose secrets on the chip.

The most common fault injection techniques include underpowering, temperature variation, voltage bursts, clock glitches, optical attacks, and electromagnetic fault injection. All these fault injection methods manipulate the physical layer of the device causing the transistors to switch abnormally.

Clock glitches and voltage bursts/spikes are the most popular form of noninvasive fault attacks where no damage is done to the equipment. Clock glitches can be introduced by supplying a deviated clock signal to chips while voltage spikes are introduced by varying the power supply to the chip. Both these techniques can affect the program as well as dataflow. These glitches can cause the processor to skip the execution of instructions, can change the program counter, or tamper with loops and conditional statements. Effects on the dataflow include the possibility of invalid data in memory reads, computation errors, and corrupt memory pointers. Both these fault attacks are easy to implement and are very inexpensive. Some other examples of noninvasive attacks include exposing the chip to very high or low temperatures and underpowering the device.

Another type of fault attack is the optical attack. These are semiinvasive/invasive in nature. In such attacks, a decapsulated chip is exposed to a strong light source. These attacks require expensive equipment and a complex setup. With a focused laser beam it is possible to set or unset a bit in memory.

An external electromagnetic field can also be used to change memory content. These EM field changes induce eddy currents on the surface of the chip and can cause single bit failures.

Fault attacks can be used to change program flow by attacking critical jumps. For example, say we have an authentication code sequence where a decision needs to be made to pass control to the next image if authentication passes or to stop in the case of failure. An attack on the authentication check can be critical to the execution flow (Fig. 12).

We have just considered an example where attacks on program flow can lead to the skipping of security branches or bypassing of security settings.

There are attacks which are launched on I/O loops in the code. Typically, all programs have I/O loops where copies are happening from buffers. Attacks can be launched on the copy loops to:

• • Copy either more or less than expected.
• • Copy from a different source.
• • Copy to a different destination.

These attacks can lead to the wrong initialization of data or keys.

One type of countermeasure against fault attack can be applied at the hardware level to prevent fault injections. Examples include active and passive shields. An active shield can consist of a wire mesh over the chip to detect any interruptions on the wire. Passive shields are metal layers that either cover the chip completely or partially to prevent optical injection or probe attacks. Light sensors and frequency detectors can be added to the chip to detect clock and voltage glitches. However, these countermeasures are costly, and attackers are always on the lookout for ways to bypass these and come up with novel fault injection methods.

Other countermeasures include protecting the software and hardware, so that faults can be detected. These employ redundancy checks to check if a computation has been tampered with and incorporate fault checks to detect and report faults. A detailed discussion of these countermeasures can be found in [10]. In embedded systems, these faults can be detected in different parts of a processor.

1. 1. Input part

If inputs are supplied to an algorithm or implementation externally, any miss on checking these input parameters can result in a fault. For example, typically in a Chain of Trust, for authenticating an image, signatures, public keys, and their lengths are provided externally. If the software does not do bound checks on these externally supplied parameters, attacks on copy loops may result. Say the user supplies a public key length which is greater than the buffer length allocated internally in the software. If no bound checks are performed on key length this would result in the copying of a key greater than the buffer allocated to it. An attacker can intelligently use this buffer overflow attack and modify some decision-making data lying in the periphery of this buffer. Thus proper checks on any input parameters are essential to prevent these kinds of attacks. Validity checking of input parameters is essential before doing any computation.

1. 2. Processing part (memory and data path), program flow

Attacks on processing parts usually attempt to change the program flow by skipping instructions or modifying memory content. Some of the countermeasures against such attacks include:

• • Adding parallel and redundant computations. This would mean to compute some operations more than once and comparing results.
• • Adding checksum over memory content.
• • Adding redundant forms in the coding of flags.
• • Checking the specific properties of an algorithm.

Meltdown [11] breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access memory and thus all the secrets of other programs and the operating system. One way an attacker can trigger a Meltdown attack is by making use of an exception. An exception can occur when a user tries to access something from kernel memory. This exception is handled by the kernel. Architecturally, the isolation mechanisms will not allow the user to access kernel memory, but in the short window between when the exception has been handled and control returns to client memory, some user space instructions might get executed out of order. These instructions in the user space can be used to deliberately access kernel memory. Due to execution being out of order, the content, though not visible to the user process, will be in the processor’s caches. After the exception is handled, before returning to the user process, the processor would do a cleanup. However, caches do not get cleaned up as part of this process. From the user space, an attacker can run the Flush + Reload attack, as described earlier, to extract this information.

You might be wondering about the practical aspects of this attack. In the Linux kernel, keys are usually stored and can be used for various purposes. One purpose being disk encryption. A user may be able to access this key by using the attack outlined above.

Specter [11] is like Meltdown in the sense that data being accessed speculatively will end up in cache, which is vulnerable to cache attacks looking to extract data. While Meltdown breaks the isolation between the kernel and user process, Specter attacks the isolation between different applications. It allows an attacker to trick error-free programs into leaking their secrets. Examples have been given in a white paper [11], showing how Specter attacks can be used to violate browser sandboxing. A java script code can be written to read the data from the address space of a browser process running it. There are two variants of Specter attack, one which exploits conditional branch misprediction and another which leverages the misprediction of the targets of indirect branches. We will discuss these variants in some detail in the following text.

4.3.2 Specter Variant 1—Bound Check Bypass (CVE-2017-5753)

Given below is the example stated in the Specter white paper [12].

Let’s try and define what we are going to steal using this attack. Let us assume that the target program has some secret data stored right after array [13]. This is what the attacker wants to get his hands on.

In the code snipper above, input to the program is x. Bound checking is done on “x” as expected so that extra data beyond the array [13] index in array2 does not get accessed. When the code executes, if the array1_size variable is not in cache, the processor will speculatively fetch and execute the next set of instructions. In this case, if the value of x is greater than array1_size, due to speculative fetch, bound check would be by-passed and the processor would fetch the data in array2 at the location denoted by array1[x]. However, his doesn’t solve our problem, does it? The attacker wants to find out the value of array1[x], with x being his invalid input pointing to some secret data in the target program. How does he find that value? For this he would utilize cache timing attacks as discussed in the previous sections.

Assuming array1 is a uint8_t-type variable, the possible values of array1[x] range from 0 to 255. So, this means access would be happening from array [3] at locations 0 *256,255 * 256. The attack process can use cache attacks (Prime + Probe) to fill the entire cache with values. If the value at array1[x] is 0 × 20, then the location pointed out by array2[0 × 20] will be evicted out of cache. The attacker can then measure the timing they need to fetch their data and predict the value. This is a very simplified example to help users understand how the attack can be implemented. For further details refer to the Specter white paper [12].

4.3.3 Specter Variant 2—Branch Target Injection (CVE-2017-5715)

Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via side-channel analysis. Here the user tricks the branch predictor and influences the code which will be speculatively executed. Usually processors have a branch target buffer (BTB) to store the branch target prediction.

5.1.1 TPM

The Trusted Computing Group (TCG) is a not-for-profit organization formed to develop, define, and promote open, vendor- neutral, global industry specifications and standards, supportive of a hardware-based Root of Trust, for interoperable trusted computing platforms. They define standards for what is called TPM. TPM is a dedicated secure crypto-processor are designed to secure hardware or software by integrating cryptographic keys into a device. TPM chips are passive and execute commands from the CPU.

The main objectives of TPM include:

1. 1. Protecting encryption and public keys from external stealing or misuse by untrusted components in the system.
2. 2. Preventing malicious code from accessing secrets from inside it.

Given below is a high-level block diagram of a TPM chip (Fig. 14).

TPM must be physically protected from tampering. In PCs this can be accomplished by binding it to the motherboard.

There is an I/O port which connects the TPM chip to the main processor. The data transmitted over this I/O port follows standards specified by the TCG. The I/O block is responsible for the flow of information between the components inside TPM, and between TPM and the external bus.

TPM consists of a lot of cryptographic blocks which help provide cryptographic isolation. The RNG block is the true random bit stream generator. Random numbers produced by the RNG can be used to construct keys, provide nonce, etc. It has a SHA1 engine to calculate hashes which can be used for PCR extension, integrity, and authorization. There is an RSA engine to execute the RSA algorithm. The RSA algorithm can be used for signing, encryption, and decryption.

TPM also has some nonvolatile storage to store long-term keys. Two long-term keys are the Endorsement Key and the Storage Root Key. These form the basis of a key hierarchy designed to manage secure storage. NV storage (nonvolatile) is also used to store authorization data like owner passwords. Such passwords are set during the process of taking ownership of TPM. Some persistent flags related to access control and Op-In mechanisms are also stored here.

PCRs are used to store integrity metrics to store measurements. These are reset every time the system loses power or restarts.

Keys form part of nonvolatile memory that is used to store them for crypto operations. For a key to be used it needs to be loaded into TPM.

TPM acts as the Hardware Root of Trust, providing:

• - Root of Trust for measurement.
  • • TPM uses PCR (Platform Configuration Registers) to save the state of the system.
• - Root of Trust for reporting.
  • • TPM acts as an entity to report information accurately and correctly.
  • • PCR and RSA signatures are used for this purpose.
• - Root of Trust for storage.
  • • TPM uses PCR and RSA encryption to ensure that data can be accessed only a when platform is in a known good state.

5.1.2 Secure Element

A secure element (SE) is a tamper-resistant platform (typically a one-chip secure microcontroller) capable of securely hosting applications and their confidential and cryptographic data (e.g., key management) in accordance with the rules and security requirements set forth by a set of well-identified, trusted authorities.

The main features of a SE are:

• - Hardware-supported cryptographic operations.
• - Execution isolation.
• - Data protection against unauthorized access.

5.1.3 ARM TrustZone

ARM TrustZone technology provides protective measures in the ARM processor, bus fabric, and system peripheral IPs to provide system-wide security. TrustZone technology is implemented in most ARM modern processors including Arm Cortex-A cores and the latest Cortex-M23- and Cortex-M33-based systems.

ARM TrustZone starts at the hardware level by creating two worlds that can run simultaneously on a single core: a secure world and a nonsecure world. Software either resides in the secure world or the nonsecure world. A switch between the two worlds can be done via a monitor call in Cortex-A processors or using core-logic in Cortex-M processors. This partitioning extends beyond the ARM core to memory, bus, interrupts, and peripherals within an SoC.

The ARM core or processor can run in two modes: secure and nonsecure mode. This state of the processor is depicted by a flag called NS. This flag is propagated to the peripherals though the bus (AMBA3 AXI system bus). Between the bus and the various peripherals, such as external memory and I/O peripherals, sits a gatekeeper. This gatekeeper allows/restricts access to these external resources based on policies set. Examples of these gatekeepers are:

1. 1. TZASC (TrustZone Address space controller) for external memory.
2. 2. TZPC for the I/O peripherals.

TrustZone technology within Cortex-A-based application processors is commonly used to run a trusted boot and a trusted OS to create a TEE. Typical use cases include the protection of authentication mechanisms, cryptography, key material, and digital rights management (DRM). Applications that run in the secure world are called Trusted Apps [14].

TrustZone for Cortex-M is used to protect firmware, peripherals, and I/O, as well as provide isolation for Secure Boot, trusted update, and Root of Trust implementations while providing the deterministic real-time response expected for embedded solutions [14].

Access control is required to ensure that only authorized users and processes can access resources they are entitled to access. These resources include not only data files but memory, I/O peripherals, and other critical resources of the system.

At a high level, access control policies of a system can be divided into following categories:

1. 1. Discretionary Access Control (DAC).
2. 2. Mandatory Access Control (MAC).

DAC, as the name suggests, is discretionary, that is, at the discretion of the user. The user decides the policies on its objects. For example, when a user creates a file, they decide who can has certain permissions on that file. These permissions are stored in the inode associated with the file. Thus each object on a DAC-based system has what is called an ACL (access control List). The ACL has the complete list of users and groups which the creator of an object has granted access to. Here the user who owns the resource gets total control whether they want it or not. One important point to note is that a user can set/change permissions for resources they own. There is another category called the super user, where the DAC policy for managing the system can be bypassed.

In MAC, it is not the user but the system administrator or a central user that controls what resources each user gets access to. It is stricter than DAC and helps in containing bugs in the user space software. In MAC, the object is associated with a security label instead of an ACL. The label contains two pieces of information:

• - The security classification of an object—if the object is secret, top secret, or confidential.
• - The category of the object which indicates the level of user that is allowed access to that object, for example, management level or the project to which the object/resource is available.

Each user account also has a classification and category associated with them. A user is allowed access to an object only if both the category and classification of the object match that of the user. SELinux, AppArmour, and SMACK are some of the widely used implementations of MAC in the Linux world [15].

5.4.2 Application Sandboxing

Application sandboxing helps to isolate applications from critical system resources thus adding a security layer to prevent malware from affecting systems. Sandboxing is also sometimes referred to as “jailing.” It provides a safe environment which is monitored and controlled, such that the unknown software cannot do any harm to the host computer system [16]. It ensures that a fault in one application doesn’t bring down the complete system.

Virtualization is one of the ways of achieving application sandboxing. Virtualization is the use of hypervisors or virtual machine monitors to create and manage individual partitions that contain guest OSs on a single real machine. The hypervisor allocates system hardware resources, such as memory, I/O, and processor cores, to each partition while maintaining the necessary separation between operating environments. A hypervisor enables hosting multiple virtual environments over a single physical environment. A critical function of the hypervisor from a security stand point is to maintain isolation between partitions and continue running even if another OS crashes [17]. The ability to maintain isolation is highly dependent on the robustness of the underlying hypervisor. There are two types of hypervisors:

1. 1. Type 1 hypervisors.
2. 2. Type 2 hypervisors.

Type 1 hypervisors run on bare metal while Type 2 hypervisors have an underlying operating system. Since the security of a Type 2 hypervisor depends on the underlying host operating system, these hypervisors are not used in mission-critical deployments.

CPU hardware assists are generally used for implementation of hypervisors in embedded systems. Popular CPU architectures like PowerPC and ARM have hypervisor extensions defined in them.

Apart from CPU extensions, ARM architecture also provides another capability called ARM TrustZone which provides ways to partition systems into two zones: secure and nonsecure. Trusted software which uses secrets, like keys, completes cryptographic operations, and operates digital rights management software, etc., can be run in the secure world which is isolated from the nonsecure world. Further details about ARM TrustZone are provided in the Section 5.1.

Linux containers are also used for providing application isolation, apart from virtualization. While hypervisors are used to provide virtualization, containers use the functionality of underlying OSs, like namespaces, to restrict applications from accessing certain system resources, files, etc. This effectively means that applications share the same operating system but have separate user spaces. With containers, the operating system, not the physical hardware, is virtualized (Fig. 18).

Let’s discuss the security aspects of the two approaches. If an application running in a container has some vulnerability and affects the operating system, all other applications running in the container would be affected. In a similar situation in the case of a virtual machine, only the OS running that application is affected, leaving the host OS and other VMs unaffected. While a container uses software mechanisms to achieve isolation, virtualization is tied up with hardware and provides more security. However, this added security comes at a price—performance is lower in the case of VMs since many context switches are involved. Containers have lower overheads and are less resource-heavy. So, you need to choose the right sandboxing methodology based on your use case and requirements. For a constrained embedded device, not capable of running virtual machines, containers seem to be the first practical virtualization technology.

Container adoption is on the rise in IoT devices that have limited storage space, bandwidth, and computing power. Docker is a popular container technology which is built on LXC and has an “easy button” to enable developers to build, package, and deploy applications without requiring a hypervisor.

5.4.3 Application Authenticity

Attackers usually try to modify existing code or inject malicious code into a system, tricking the user to run it. This can be prevented if applications are authenticated before execution. Authentication helps ensure that application code is from a trusted source and has not been modified. A typical way of doing this is by using certificates and signatures. The hash of an application can be compared with the hash present in the certificate that comes along with the application. The certificate always comes from a trusted authority. For example, Apple iOS implements this by enforcing all applications through the App Store.

Normally asymmetric cryptography, using public and private keys, is used for authenticity, but this same effect can be achieved using symmetric key hashes too, like HMAC. Both methodologies have their pros and cons. When using a signature, the confidentiality of the private key needs to be ensured by a single authority and the system just needs to protect the integrity of the public key used for verification. However, since the system doesn’t have the private key, it cannot resign the application or file in case any changes are made to it. This schema can be used for read-only files and applications which don’t change during the lifetime of a system. However, if there are security- critical files which change during the lifetime of a system, they need to be protected by a local symmetric key. The caveat being that this local symmetric key needs to be carefully protected to prevent attackers from using it to sign a malicious application.

Linux IMA (Integrity Measurement Architecture) and EVM (Extended Verification Module) are example frameworks which have been built in Linux for application integrity and authenticity. These frameworks have been available in the Linux kernel since 2.6.30. Linux integrity frameworks provide the capability to detect whether files have been accidentally or maliciously altered, either remotely or locally, appraise a file’s measurement against a “good” value stored as an extended attribute, and enforce local file integrity. These goals are complementary to Mandatory Access Control (MAC) protections provided by LSM modules, such as SElinux and Smack, which, depending on the policy, attempt to protect file integrity [17].

At a very high level, the IMA and EVM provide the following functionality:

• • Measurement (hashing) of file content as it is accessed and tracking of this information in an audit log.
• • Appraisal of files, preventing access when a measurement (hash) or digital signature does not match the expected value.

The IMA maintains a runtime measurement list which can be anchored in hardware (e.g., TPM) to maintain an aggregate integrity over the list. Hardware anchoring in TPM, or in any other way, helps to ensure that the measurement lists can’t be compromised by a software attack. Further details about this infrastructure can be found in the Linux kernel documentation [17].

5.4.4 Case Study: Chain of Trust Along With Application Authenticity Using IMA EVM on Layerscape Trust Architecture–Based SoCs Without Using TPM

The Secure Boot mechanism (as shown below) is provided by NXP on its Layerscape trust architecture SoCs. This mechanism establishes a Chain of Trust with every image being validated before execution.

Root of Trust is established in boot ROM execution phase, by validating the boot loader image before passing control for its execution. Each firmware image is appended with a header. This header contains security information related to the image, such as an image signature or public key. The Chain of Trust ends after validation of the fit image or kernel image (Fig. 19).

Rootfs is another important entity that needs to be authenticated before passing control for its execution. Rootfs can be used in following ways:

1. 1. Rootfs is the part of the fit image (combined kernel/device tree/initramfs image) that is validated using the standard Secure Boot mechanism in the Chain of Trust. In this case, rootfs will always be expanded in RAM and hence no new application or image can be added at runtime.
2. 2. Rootfs is placed on some persistent storage device, such as an SD, SATA, or USB device. In this case, rootfs can be expanded at runtime but cannot be validated using a standard Secure Boot mechanism. On each boot to validate rootfs content we need to leverage the mechanism provided by the Linux kernel.

One such mechanism provided by the Linux kernel for validating rootfs content is the IMA EVM feature. This provides file-level authentication as discussed in the previous section.

The IMA EVM uses an encrypted-type key. An encrypted key blob for a user is derived by the kernel using the master key. The master key can be a:

1. 1. User key type. This is independent of any hardware and is dependent on the user mechanism to protect its content.
2. 2. Trusted key type. This is dependent on TPM hardware and is tied to it. The user is only able to access the blobs signed by the TPM hardware.
3. 3. Secure key type. This is dependent on the NXP CAAM (Cryptographic Accelerator and Assurance Module).

A secure key is generated using the CAAM security engine which constitutes random bytes. The key contents are stored in kernel space and are not visible to the user. The user space will only be able to see the key blob.

Blobs are special data structures for holding encrypted data, along with an encrypted version of the key used to decrypt the data. Typically, blobs are used to hold data to be stored in external storage (such as flash memory or in an external file system), making the contents of a blob a semipersistent secret. The secrecy of a blob depends on a device-specific 256-bit master key, which is derived from the OTMPK or ZMK on Layerscape trust architecture–based SoCs.

The IMA EVM operates in two modes: fixed mode and enforced mode. Fixed mode is meant to be executed at the factory setup stage, subsequently, the SoC is always booted in enforced mode. Fixed mode is meant to generate the key and label the file system with the IMA EVM security attributes. In enforced mode the attribute values are either authenticated or appraised only. Enforced mode denies access to the file if any mismatch is found in the security attribute values.

On Layerscape trust architecture–based SoCs the secure key (tied to CAAM hardware) along with an encrypted key type can be used to support the IMA EVM–based authentication mechanism.

The IMA EVM can be enabled on SoCs using a small initramfs image which is validated in the Chain of Trust. Initramfs is meant to perform the following tasks:

1. 1. Create the secure key and encrypted key (fixed mode) or load their corresponding blobs (enforced mode), to support file-based authentication by the IMA EVM. The key contents are added to the user keyring.
2. 2. In fixed mode the hardware-generated secure key blob and the kernel-generated encrypted key blob are saved on the main rootfs mounted over some storage device.
3. 3. Enable the EVM by setting an enable flag in the securityfs/evm file.
4. 4. Switch control to main rootfs for its execution.

The Chain of Trust with the IMA EVM is shown in Fig. 20.

5.4.5 Application Execution

Attackers have in the past exploited (and will probably continue to exploit) applications through user supplied input. One of the most common and oldest forms of attack is the “buffer overrun,” where user- supplied input goes unchecked and ends up writing directly to the operating system and application memory that is normally used to store the application execution code and temporary and global data. Instead, an attacker supplies sufficient data to take control of application execution (by manipulating the stack pointer) and executes, within the application context, the data and code they have written to memory rather than continue to execute the application. To mitigate this attack, several platforms and operating systems, such as Windows XP onwards, Apple iOS, Android, and SELinux, all mark application data as nonexecutable so that even if the attacker manages to write data to memory they will struggle to execute that data.

To mitigate the nonexecution of the overwritten data or where space available is too small to contain all the malicious instructions, attackers attempt to use another technique, “return to-lib-c/return orientated programming.” In this case, they attempt to use already preloaded and existing libraries and the code of the operating system, which they reference in a sequence to try to execute their desired function. To mitigate this attack, several operating systems have also adopted the technique of address space layout randomization. By randomizing the memory locations in which executable code and libraries are loaded the ability of an attacker to readily guess and access the predictable software codes they need is significantly reduced.

5.5.1 Security of Data at Rest—Secure Storage

Data at rest is data which is stored on a device and is not actively moving from device to device or network to network. This includes data stored on a hard drive, flash drive, or archived/stored in some other way. Protecting data at rest aims to secure inactive data stored on any device or network. This data may include credit card pins, passwords, etc., found on a mobile device. Mobile devices are often subject to specific security protocols like data encryption to protect data at rest from unauthorized access when a device is lost or stolen. The encryption methods used should be strong. Usually AES is preferred as an encryption method for data at rest. Encryption keys should be stored separately from data and should be highly protected. The total security of the data lies with the encryption key. Periodic auditing of sensitive data should be part of a security policy and should occur at scheduled occurrences.

Given below are some open-source encryption solutions in Linux:

• - dm-crypt—a transparent disk encryption subsystem.
• - eCryptfs–eCryptfs—a POSIX-compliant enterprise cryptographic stacked filesystem for Linux.

Both are supported by Ubuntu, SLES, RedHat, Debian, and CentOS.

Before choosing the right solution for your data at rest you need to answer a fundamental question—What do you mean by data you want to protect? Do you mean complete hard drive data or a file containing sensitive information?

5.5.1.1 Full Disk Encryption or Authentication

Full disk encryption or authentication involves encrypting and/or verifying the contents of the entire disk at a block level. In the case of Linux, this is performed by the kernel’s device mapper (dm) modules. This method can be used with block devices only (e.g., EMMC and NAND). This software is called dm-crypt and works by encrypting data and writing it onto a storage device (by way of the device driver) using a storage format called LUKS.

Linux Unified Key Setup (LUKS) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy. LUKS uses the kernel device mapper subsystem via the dm-crypt module. This arrangement provides low-level mapping that handles encryption and decryption of device data. User-level operations, such as creating and accessing encrypted devices, are accomplished using the cryptsetup utility (Fig. 21).

5.5.2 Protecting the Key Used for Encryption

The key which is used for encryption needs to be protected. Mechanisms that can be used to protect this key include:

• - Storing the key in external crypto or a security chip–like SE.
• - Using TPM.
• - Encrypting the key using an SoC mechanism (details are given below).

5.5.3 Security of Data in Motion—Secure Communication

To protect data in motion, an encrypted channel needs to be created for moving data. This encrypted channel can exist at the application layer or at the transport layer. We often select transport layer protections given our desire for code reuse and the wealth of battle- hardened encryption technologies available at the transport layer. The two most widely used mechanisms for transport layer encryption are Transport Layer Security (TLS) or IPsec.

IPsec, TLS, and SSH share a common goal, that is, to provide a secure connection between two peers/devices/endpoints. The difference between them is the layer at which they execute. There is no preferred protocol in that they all offer certain benefits. To decide which one to use, you really need to understand what you are trying to secure. Once you understand that, the choice of which network security protocol to use becomes easy! The security services provided by these protocols include:

• • Message integrity—ensuring that a message has not been altered to prevent theft of service. This is achieved by message signing using digital signatures, HMAC, etc.
• • Authentication to provide mitigation against theft or masquerading attacks. This is provided via user authentication using X 509 certificates.
• • Confidentiality to mitigate against eavesdropping using symmetric algorithms.
• • Nonrepudiation to ensure accountability (i.e., the person cannot later deny sending the message).