CompTIA CySA+ Cybersecurity Analyst Certification: Software and Systems Security - Hardware Assurance Best Practices

Objective 2.3  Explain hardware assurance best practices
In the previous objective, we discussed software assurance. This particular topic gets a lot of attention because most of the vulnerabilities that are obvious to users, as well as security practitioners, involve software. However, software vulnerabilities are not the only thing we should be noticing. The other half of the computing device, the hardware, also has numerous vulnerabilities and concerns that we need to address. Hardware vulnerabilities may not be as obvious to ordinary users or cybersecurity analysts, but they’re just as important because they can cause just as much damage and may be more challenging to address in some cases.
In this objective, we’re going to discuss the different aspects of hardware assurance, including the hardware root of trust, firmware, trusted manufacturing processes, secure processing, anti-tamper methods, and methods to protect hardware, such as self-encrypting drives, firmware updates, and trusted boot.

Hardware Root of Trust
To begin the discussion, let’s talk about what the hardware trust chain looks like. Software is ever-changing, and we must constantly be alert to the environment in which software executes. This environment is the hardware itself—the CPU, memory, and permanent storage. This environment, regardless of what software is running, must always be trusted, stable, and secure. This is where the hardware root of trust comes in. Hardware root of trust is a term given to a trusted execution environment. As part of this environment, there are tamper-resistant hardware, cryptographic functions that encrypt data and ensure its integrity, and processes that ensure that the data is secure, from generation to processing, storage, and transit. Different components contribute to this hardware root of trust, including the manufacturer using authentic, trusted components, the logistics and supply chain, and the end-user environment.

Two important components of the hardware root of trust are Trusted Platform Modules and hardware security modules. These provide cryptographic functions at a minimum, but also provide the trusted environment needed to run the software.

Exam tip: The hardware root of trust is the collection of secure supply chain management, the trusted hardware itself, and the secure processes that create a trusted environment for the operating system (OS), applications, and data to process within.

Trusted Platform Module (TPM)
Previously we discussed the concept of system-on-chip (SoC). As a reminder, this is almost a complete computer system that operates using firmware on a secure chip that is part of the motherboard in a piece of hardware. The Trusted Platform Module, or TPM, is such a system. It resides on the motherboard and is responsible for security functions, including storage and generation of cryptographic keys and digital certificates, both symmetric and asymmetric cryptography, and hashing. The TPM was developed by the Trusted Computing Group, which is an organization involved with creating and maintaining open standards of security for computing platforms.

TPMs perform several functions, including the following:
- Binding the hard drive computer to the system, encrypting it, and requiring that it remain with the system it is bound to in order to be decrypted
- Sealing a system state, which means that the system’s specific hardware and software configurations are recorded and locked so that attempts to modify the system configuration will be thwarted
- Cryptographic key generation and storage

The TPM uses several different types of keys and components for different services. The TPM has two different types of memory: persistent memory, which holds its values even when power is turned off, and a volatile type of memory called versatile memory. These components/keys perform different functions and are stored in different sections of memory.

A summary of these components is given in the following table:


Hardware Security Module (HSM)
A hardware security module (HSM) is similar to a TPM; however, whereas a TPM is installed as a system-on-chip on the motherboard of the computing device, an HSM is an external piece of hardware plugged in to the device, either as an add-on board or as an external device that can plug into a system port. HSMs can perform the same cryptographic functions as TPMs, including key generation, storage, and processing. For devices that do not contain a TPM, an HSM can be used to perform the same functions. Cryptographic functions can be processor-intensive, so the HSM offloads those intensive functions from the system itself.

Exam tip: TPMs and HSMs perform essentially the same functions; keep in mind that the real difference is that TPMs are embedded on the motherboard, whereas HSMs are a plug-in card or peripheral device.

eFuse
An eFuse is a technology invented by IBM in 2004. It is intended to be a form of one-time programmable memory. It is a single bit of memory, constructed as a simple circuit, that is physically and electronically set to indicate the value of a binary “1” and is by default open and allows current to pass through it. It can be electronically changed, via inducing power to its chemical makeup, to block current, making it a resistor instead. This has the effect of changing it to a physical and electronic binary “0” value when the current is applied. Once this change takes place, it can never be reprogrammed again. This type of technology is used to create circuits made of eFuses, which can be changed once to a permanent value that remains with the device during its lifetime. Examples of practical uses of this technology are disabling functionality on a chip, including test and development features used during the manufacturing process, as well as permanently loading a value, such as a key, into the device. Since it cannot be reprogrammed after its initial programming, this makes the value permanent.

Exam tip: Remember that eFuses are set to a default value of binary 1 and, once programmed as a binary 0, cannot be programmed again since the circuit has been physically dissolved into the “open” state.

Unified Extensible Firmware Interface (UEFI)
Computing devices rely on startup instructions in order to boot up, locate their operating systems, and execute programs. The startup instructions, since they are required before the main operating system is even loaded, must be permanently stored on the device. These instructions, as well as sometimes a basic rudimentary operating system used for configuration and troubleshooting purposes, are stored as firmware on the device. Firmware means that, unlike software, it is reasonably permanent and cannot be erased, even when power is taken away from the device.
For many years, the firmware used to load the startup instructions for a device was called the Basic Input/Output System, or BIOS, originally developed by IBM. The BIOS was stored in read-only memory and could not be altered. It contained information about the system’s hardware, including its CPU, RAM, and permanently attached storage. It also contained values that could be set, such as the time and date. These volatile values were maintained by an onboard battery, which, when removed, would revert these values to their default settings. Later, manufacturers developed a technology to update the system BIOS periodically, using different utilities that could be loaded at boot time.
System BIOS was very limited in the functions it could perform, particularly security functions. It could be easily bypassed and changed by unauthorized processes or persons. A better system was required, especially to address performance, function, and security issues that came as part of newer operating systems. Enter the Unified Extensible Firmware Interface (UEFI).
UEFI is a vast improvement to the original BIOS in terms of functionality and security. Its functionality improvements include recognizing drive partitions over 2 TB in size and allowing more flexible boot options, such as from a variety of removal media, via a local network, and even using the HTTP protocol. From a security perspective, it provides the following improvements over the original BIOS:
- Establishes a hardware and software root of trust
- Assists in loading cryptographic keys for decryption of hard disks and other media
- Initializes hardware in the trusted chain, thereby preventing booting from unauthorized devices
- Uses onboard digital certificates belonging to trusted hardware and software vendors
- Provides an enhanced, configurable, and secure user interface prior to boot

UEFI has been installed on computing devices manufactured in the last decade, and its most obvious feature for most users is the ability to securely boot from trusted media. When configured for secure boot, it prevents an unauthorized person from inserting boot media and accessing sensitive files through an insecure boot process. For better or for worse, secure boot can be disabled in specific circumstances, such as in testing and development environments.

Trusted Foundry
The term trusted foundry comes from the U.S. Department of Defense and is used to describe a program for vetting and approving vendors of trusted hardware. This program was developed in 2004 and is used to ensure a secure supply chain for critical military and government systems. These vendors have been put through a rigorous process of vetting, including process audits, verification of component procurement, and secure manufacturing, and then approved to provide components in systems to the government. These components are trusted because they come from known manufacturers, using a validated supply chain. These components and systems can be validated as being authentic, and without any unintended or malicious modification to their subassemblies, lower-level components, or firmware. One prominent disadvantage in the trusted foundry process is its cost. The increased measures needed to provide assurance of secure manufacturing, production, and supply chain cost vendors significantly, which drives up the cost of trusted components versus their counterparts that are not part of a trusted foundry program.

Secure Processing
Data typically resides in one of three states: at rest (while it is in storage and not in use), in transit (while it is being transmitted or received across a network connection between hosts), and in use (while it is being processed). You already know how data is protected in the first two states. Encryption can protect data both at rest and in transit, so it cannot be accessed by unauthorized entities. It can also be protected using permissions associated with a user’s account. But how is data protected while it is being processed, or in use? For normal applications, encrypting data while it is in use is not feasible since it must be continually decrypted and encrypted—something that is beyond the capability of most applications to deal with. This is where hardware can come into play. Trusted hardware can create an environment where data can be processed securely, using a combination of hardware, a trusted execution space, and applications that are specifically designed for this process. There are different combinations of methods used to create a trusted space for data to be processed within. These include a trusted execution environment, or secure enclave, as well as the use of processor security extensions. This also involves the use of atomic execution. All three of these will be discussed in the upcoming sections.

Trusted Execution and Secure Enclave
We have already discussed the use of sandboxing and containerization as initial environments in which we can run applications. These environments prevent outside applications or processes from interfering with their execution and protect the underlying operating system (OS) from vulnerabilities that may be inherent in those applications, providing us with a sort of mutual protection layer. These trusted environments can also be created using a variety of different methods.

One method is to create a protected part of the computer, such as memory, in which trusted data and applications execute without interference from outside influences, such as other applications or data.

Another method is to use more secure processor designs that contain special extensions used to create protected environments for each application. Still another method is for applications to temporarily gain exclusive use of the processor and memory to protect themselves from outside influences until they have completed executing. Let’s take a moment to discuss these in turn.

In a trusted execution environment (TEE), a software abstraction layer creates containers in which several applications can run, protected from the underlying OS and any potential vulnerabilities inherent to the OS (and vice versa). Note that a trusted execution environment is also referred to sometimes as a secure enclave, particularly when referring to Apple devices. As we previously discussed regarding containerization, this trusted execution environment is analogous to a virtualization environment, where a hypervisor abstracts hardware and processes to the virtualized operating system. Containerization works the same way, except that it abstracts the operating system from the software applications executing in the container. Note that a trusted execution environment or secure enclave can be used to run many applications within the trusted environment, or, as we will discuss with processor security extensions, used to create microenvironments for individual applications.

Note: Trusted execution environment (TEE) and secure enclave are synonymous terms. Secure enclave is what Apple uses to refer to its TEE.

Processor Security Extensions
Processor security extensions are specialized components found in modern CPUs. These extensions work together to create a trusted execution environment. Applications must be written to take advantage of these security extensions, which may include setting up a reserved area of memory for an application’s process to execute securely. This might even include encrypting and decrypting those areas of memory dynamically, protecting the application processes and data that resides in them. The main function of processor security extensions is to provide a protected area for data execution.

Atomic Execution
In Objective 1.7, we discussed race conditions and the time-of-check/time-of-use (TOC/TOU) attacks possible when conditions allow for certain processes to be executed out of sequence or when there is contention for the exclusive use of a resource, such as CPU time or memory, by multiple processes. A method for preventing these types of attacks is atomic execution, which is used for controlling a programming run so that processes must execute in a specific sequence and cannot be interrupted between the time when the process starts and when it ends. This prevents other applications or processes from interfering with resources used by a particular process. Essentially, it allows exclusive use of those resources during processing time. Atomic execution works as a combination of secure programming and the allowed use of hardware in this manner.
One word of caution regarding atomic execution: it should only be used sparingly. Overuse will incur serious system performance degradation, as it requires more processing power to dynamically lock and unlock resources as well as track and manage multiple processes that must be performed in sequence.

Bus Encryption
Bus encryption is yet another measure taken to prevent data from being compromised during the processing state. We’ve seen how data can be encrypted while in storage or while in transit, but it is theoretically possible for an attacker to implant malware on a system that can intercept data as it is being decrypted and transferred from the drive to the CPU or on its way to RAM. Even with self-encrypting drives, the data must be decrypted at some point for processing. Bus encryption simply moves the encryption point from the drive to the CPU. Data is transferred in encrypted form to the CPU and handled by a special chip, called a cryptoprocessor. This cryptoprocessor decrypts data upon arrival to the CPU and protects keys in memory. Cryptoprocessors are typically used in specialized machines, such as highly secure, real-time processing devices used in military weapon systems, banking systems (for example, ATMs), and so on. An example of where you might see a cryptoprocessor used in common household computing devices is a cable or satellite TV box that descrambles encrypted signals only for channel subscribers.

Anti-Tamper
In widespread efforts to combat counterfeit and compromised hardware in the supply chain, component manufacturers, vendors, industry partners, and cybersecurity professionals have created an overarching program known as anti-tamper.

The goals of an anti-tamper program are to ensure that authentic, trusted hardware is manufactured, sold, transported, received, and used by organizations such as companies, governments, and even individuals.

Anti-tamper looks at all stages of the supply chain—from architecture and design to manufacturing, logistics, and assurance. Vulnerabilities are assessed and mitigated at every stage in this chain. These efforts are intended to thwart counterfeit or compromised hardware and software, but also to ensure that legitimate hardware cannot be reverse engineered so that it can later be compromised or duplicated. For example, some attackers engage in reverse engineering components by applying voltages to chips and observing how they react. This makes it possible to map the functions of the chip and gain information on how they work. Attackers also engage in visual inspection of components by cutting them apart with precision tools, such as lasers, or with chemicals. Visually observing chips with a high-powered microscope enables a potential attacker to expose chip architecture, design, and function, and may yield information on how to circumvent security measures or even counterfeit those chips. Anti-tamper is concerned with preventing these instances by developing countermeasures against them. This includes random signal generation, which may thwart electronic probing, as well as automatic destruction of chip circuitry in the event a chip is physically compromised.

Self-Encrypting Drive (SED)
The self-encrypting drive (SED) does exactly what its name suggests. However, rather than using software such as Windows BitLocker, for example, it is a hardware-based solution. A cryptographic module is part of the drive hardware, typically built into the disk controller itself. Like TPMs, self-encrypting drives meet the standards promulgated by the Trusted Computing Group in Opal Storage Specification (OSS) 2.0. For the most part, an SED does not natively use the TPM because its hardware is built in. However, it performs some of the same functions in that it is bound to the machine it resides in and cannot be used outside of that machine once the binding occurs.
SEDs typically use an Advanced Encryption Standard (AES) 128- or 256-bit key, which is stored permanently in the cryptographic module attached to the drive. The user creates a password, which is used to then encrypt the drive’s key. In the event the user changes the password, the drive key is simply re-encrypted with the new password. When the drive is wiped (effectively by simply encrypting the entire drive’s contents), a new drive key is created.

Exam tip: A self-encrypting drive has its own cryptographic module attached to its drive controller and does not normally require a TPM for its encryption and decryption operations.

Trusted Firmware Updates
Traditional firmware updates for older BIOS implementations involved a user downloading a firmware image from a vendor site, running a specialized program that updated the firmware, and rebooting the device while the firmware update process takes place. Unfortunately, firmware, particularly when downloaded arbitrarily from an untrusted site, could be used to compromise the machine at the BIOS or operating system kernel level. This is one effective way a rootkit can be installed on a machine.
Trusted firmware updates, however, eliminate this issue. A trusted firmware update process eliminates the need for user intervention or downloading from an untrusted site. In this model, the ability to update firmware securely is part of the function of the computer’s firmware itself. Of course, in order to perform this function, the firmware update must be digitally signed and able to be verified by the firmware. This is an additional function that can be fulfilled by a TPM.

Measured Boot and Attestation
Earlier we discussed the process of a secure boot, which requires that the computing device boot into a trusted operating system, using strict security measures to prevent booting from untrusted media. There may be times, however, when the machine is required to boot into an alternate system, particularly in test or development environments. Most UEFI implementations support a nonsecure boot mode, sometimes referred to as a “legacy” boot option in its menu. However, this would seem to negate the entire reason for having a secure boot process in the first place. Not to worry: the boot process, even when used from an alternate operating system standpoint, can be controlled as well as audited. This is done by performing what is known as a measured boot. In a measured boot scenario, the system automatically hashes the alternative boot code and securely stores the hashes. These hashes can later be verified during the attestation process, which is the process of examining the hashes at a different station and confirming that they match known hashes of the alternate boot code. This way, when the system is booted from alternate code, it can be compared against known-good hashes to ensure that it is still booting to a known-good source.


Key Terms: Measured boot is the process of collecting hashes of startup or boot files when booting in a mode other than secure boot. Attestation is the process of comparing those same hashes to known-good ones to validate the startup or boot files.

REVIEW
Objective 2.3: Explain hardware assurance best practices In this objective, we discussed hardware assurance. You learned that the hardware root of trust is simply the ability to trust hardware all the way from its manufacturer through the logistics supply chain, including the fact that it is authentic and has not been compromised. Two components that help develop this root of trust are the Trusted Platform Module (TPM), which is a system-on-chip embedded on the motherboard, and the hardware security module (HSM). The TPM handles cryptographic functions, including key storage, as well as binding an encrypted hard drive to its computing device. An HSM essentially performs the same functions, except that it is an add-in card or external device.
An eFuse is a special circuit that can only be programmed once. It defaults to a binary 1, and once it is programmed, it changes to a binary 0. When many of these circuits are combined in their various 1 and 0 binary states, they represent data permanently embedded in the computer system. Once an eFuse circuit has been programmed, it cannot be reversed.
Replacing the older BIOS firmware is the new UEFI firmware, which provides additional functionality and security for modern computing devices. This firmware makes it possible to recognize larger hard drives as well as ensure a secure boot option.
Trusted foundry is the name given to vetted and approved vendors who can provide assurances of hardware from manufacture all through the logistics supply chain. This ensures that hardware is authentic and has not been compromised by an unauthorized third party. This is essential in maintaining a secure supply chain as well as a hardware root of trust. The trusted foundry program was developed by the Department of Defense in 2004 but is also used by industry.
Secure processing is the method of securely executing applications and data in a trusted environment, while data is in use. A trusted execution environment, or secure enclave, is one way to ensure secure processing by giving an application and its data an area where it cannot be altered by other applications or data. Containerization is one form of a trusted execution environment. Processor security extensions are built into newer CPUs and provide dynamic encryption and decryption of data for the CPU to use so that it cannot be intercepted between its decryption in storage and its use by the CPU, or as it travels through the internal computer components. Bus encryption similarly prevents access to data by other applications and ensures that data stays encrypted right up until it is processed by the CPU. Atomic execution contributes to secure processing since applications can be designed to take advantage of secure hardware by exclusively using that hardware for specific processes and executing instructions in sequence without interruption.
Anti-tamper is a program and process developed by the industry to come up with solutions to prevent counterfeit hardware and compromise early in the supply chain, as well as, to a certain extent, reverse engineering by malicious entities. This may include physical protections on chips as well as destruction of data if these components are disturbed in any way.
A self-encrypting drive makes use of a cryptographic module attached to the drive controller itself. It is transparent to the user and does not rely on software from the operating system or on the computer’s TPM.
Trusted firmware updates provide a process whereby the firmware itself can check for updates, request and receive those updates, and install them securely. It typically does not involve any user interaction, which may widen the attack surface (for example, downloading updates from a potentially untrusted site).
While UEFI provides for a secure boot process and other security functions, sometimes a legacy boot or a boot from an untrusted operating system in a development or test environment is required. Measured boot allows for hashing of boot and startup files for later review to ensure that those files can be verified. Attestation is the act of checking those hashes to ensure they are part of a trusted operating system and can confirm that the hashes from the boot files are valid.