System and method for tamper-resistant booting

Disclosed herein are systems, methods, and non-transitory computer-readable storage media for booting a computing device having an encrypted storage medium using full disk encryption, referred to as tamper-resistant boot. The system retrieves a kernel cache and a kernel cache digest from an unencrypted storage medium and verifies the authenticity of the kernel cache based on the credentials and the kernel cache digest. Initiation and execution of the operating system is performed if the kernel cache is authentic. In one embodiment, the system verifies the authenticity of a request to disable tamper-resistant booting by utilizing a password verifier and a password proof.

BACKGROUND

1. Technical Field

The present disclosure relates to encryption and more specifically to tamper-resistant booting of a computing device.

Many computing devices today require some degree of information protection. Cryptography is one such method utilized in protecting computing devices. Cryptography refers to both encryption and decryption of information. Encryption is the process of changing intelligible information (plaintext) into unintelligible information (ciphertext) and decryption is the process of changing ciphertext back into plaintext.

Computing devices can encrypt data of varying sizes, from small sets to large blocks of data. Full-disk encryption (FDE) is a method that encrypts an entire disk volume on a computing device. Decryption of the entire disk volume is necessary before the disk volume is accessible. Full-disk encryption is considered more secure than file-level encryption since all files (including temporary files) are encrypted.

Although FDE is considered more secure than file-level encryption, systems with FDE employed are still vulnerable to attack. In one simple attack, a hacker can change the boot sequence of a computing device so that it boots from the hacker's own malicious code instead of performing the normal boot sequence. FDE systems must prompt the user for a password at boot time in order to unlock the FDE volume. The hacker's malicious code can display an identical looking screen that asks for the FDE password, but steals it instead of using the password to unlock the FDE volume. When the user enters the password, the hacker logs it and gains access to the computing device. The hacker can therefore surreptitiously steal the user's password. Without a chain of trust from the booter to the operating system kernel, such attacks are able to defeat even full-disk encrypted computing devices.

SUMMARY

Disclosed are systems, methods, and non-transitory computer-readable storage media for booting a computing device having an encrypted storage medium using full disk encryption, referred to as tamper-resistant booting. One way to remedy the attacks outlined above is called tamper-resistant boot. When a computing device employs a high-security mode such as FDE, it should be more difficult for a hacker to change the boot sequence than when operating under lower-security modes. However, even in a computing device with an FDE-enabled storage medium, the operating system kernel is not encrypted. This is because the boot environment is not sufficiently complex to decrypt FDE volumes. Instead, the boot environment must rely on an operating system kernel to do the decryption. The unencrypted operating system kernel is an obvious weak link in the overall FDE security model, as it can be surreptitiously replaced with malicious password-stealing code by an attacker. One way for a computing device to address this deficiency is to verify the authenticity of the boot sequence by establishing a chain of trust from the firmware to the kernel in the operating system.FIG. 1illustrates an exemplary system100that can practice the methods disclosed herein. A system100receives at a boot time credentials associated with a volume key for a FDE enabled encrypted storage medium from a user. The system retrieves the unencrypted kernel and unencrypted kernel cache digest from the storage medium. The system then verifies that the kernel cache is authentic by comparing the retrieved kernel cache digest with a computed digest. Initiation and execution of the operating system is performed if the system determines that the kernel cache is authentic. The system produces an error if the kernel cache is not authentic.

A system practicing the method initiates the tamper-resistant booting process by first generating a volume key based on a full disk encryption password received from a user. The system encrypts the storage medium with the volume key to yield a full disk encrypted storage medium. Then the system encrypts the kernel cache with the full disk encryption volume key to yield a kernel cache digest, which the system stores on an unencrypted storage medium or an unencrypted portion of an otherwise encrypted storage medium, alongside the kernel cache itself. When the system boots, it verifies the integrity of the kernel cache based on the stored kernel cache digest and a computed digest.

The system verifies that the operating system has not been tampered with by booting the system with firmware and confirming, via the firmware, the integrity of the booter. The system passes control to the booter where the booter confirms a kernel cache of the operating system based on a stored kernel cache digest and a computed digest. Once the system determines that the operating system has not been tampered with, it passes control to the operating system for initiation and execution and any remaining boot tasks.

In one embodiment, the system disables tamper-resistant booting by generating, at the firmware level, a password verifier and comparing it to a password proof. The system generates the password verifier by applying a number of iterations of an encryption algorithm to a salt value and a password. Once the system receives a request from a user to disable tamper-resistant booting, the operating system generates a partial password proof. Generating a partial password proof is accomplished by applying a portion of the number of iterations of the encryption algorithm to the request password and the salt value, and then rebooting the computing device. Once the system reboots, the firmware retrieves the partial password proof and performs the remaining portion of the number of iterations of the encryption algorithm to produce the complete password proof. If the password proof matches the password verifier, the system disables tamper-resistant booting. In this way, the system authenticates a request to disable tamper-resistant boot.

Additionally, the system initializes tamper-resistant booting by establishing a database that stores password verifiers. The operating system generates a list of users that are authorized to disable tamper-resistant booting and sends the list to the firmware. The operating system generates password verifiers for each user and sends them to the firmware as well. The firmware stores this database in non-volatile random access memory (NVRAM). The system also generates a system salt in the firmware and stores the system salt in NVRAM for later use. The principles disclosed herein apply to a computing device having an encrypted storage medium using full disk encryption.

DETAILED DESCRIPTION

The present disclosure addresses the need in the art for verification of the authenticity of a boot sequence. A system, method and non-transitory computer-readable media are disclosed which boot a computing device having an encrypted storage medium using full disk encryption. A discussion of a basic general purpose system or computing device is provided inFIG. 1which can be employed to practice the concepts disclosed herein. A more detailed description of the methods for establishing, managing, using, and removing tamper-resistant booting on computing devices using full disk encryption (FDE) will then follow. These variations shall be discussed herein as the various embodiments are set forth. The disclosure now turns toFIG. 1.

Having disclosed some basic system components, the disclosure now returns to a discussion of tamper-resistant booting, as shown in the exemplary method embodiment ofFIG. 2. For the sake of clarity, the method is discussed in terms of an exemplary system such as is shown inFIG. 1configured to practice the method.

FIG. 2illustrates an exemplary method embodiment for booting a computing device having an encrypted storage medium using full disk encryption, otherwise known as tamper-resistant booting. Tamper-resistant booting makes it more difficult for a hacker to change an authorized boot sequence in unauthorized ways or to insert his own unauthorized boot sequence. One way to protect the boot sequence is to establish a chain of trust from the firmware to the operating system kernel. Firmware refers to the fixed programs that control low-level basic operations of a device. However, while firmware is referred to as a “fixed” program, firmware updates can modify the functionality the firmware provides, in some instances. Firmware is typically stored in ROM, EEPROM, and the like for BIOS (Basic Input/Output System) based or EFI (Extensible Firmware Interface) based computer boot-up implementations. The kernel is a central component of the operating system that provides software applications with access to computing resources such as the hardware of a computing device, including the central processing unit (CPU), memory and other devices. In establishing the chain of trust, the firmware can confirm the integrity of the booter, but the booter cannot confirm the integrity of the kernel. A computer updates its kernel after leaving the manufacturing factory, and contains kernel extensions for a particular machine at boot. The kernel is customized for a particular user's machine. The booter must confirm the integrity of the kernel to protect the entire boot sequence.

When a system100uses full disk encryption, the volume key for the encrypted volume serves as a shared secret between the booter and the kernel. The booter must have the volume key in order to verify the password and pass it along to the operating system kernel that can then decrypt the disk. While the system is running, the kernel also has the full-disk encryption volume key in memory. At boot time, the booter uses the volume key to perform an integrity check on the kernel. The volume key can be the same as the password or can be derived based at least in part on the password.

The system100establishes a chain of trust from the firmware to the kernel to protect the boot sequence of a computing device. The system receives210credentials associated with a volume key from a user at a boot time. In cryptography, a credential is used to establish the identity of a user. Some examples of credentials include passwords, certificates or biometrics, such as a fingerprint or voiceprint. The volume key is the same as the credential, or some derivation thereof. For example, the volume key could be the user password, an encrypted version of the password, or the output of an algorithm that takes the user password as input. Once the system100establishes the volume key, the system retrieves230a kernel and a kernel cache digest generated by the operating system from an unencrypted storage medium. A kernel cache digest is generated using a cryptographic hash function, a secret key and the kernel cache. The kernel cache contains the kernel code and kernel extensions. A digest is also referred to as a hash value, message digest or hashed-message authentication code (HMAC). An HMAC may be used to verify both authenticity and integrity of a message simultaneously. A cryptographic hash function is a procedure that takes a block of data and returns a fixed-size bit string, referred to as the hash value or message digest. Any change in the block of data will change the digest. The kernel cache digest is a keyed hash of the kernel cache where the key is the FDE volume key.

Once the system retrieves the stored kernel cache digest, the system verifies240that the kernel cache is authentic based on the user-entered credentials and enables250initiation and execution of the operating system if the system determines that the kernel cache is authentic. The system produces an error260and does not execute the operating system if the kernel cache is not authentic. The system assumes that the computing device has been tampered with if it cannot verify the integrity of the kernel. This process is referred to as a tamper-resistant boot because integrity checks are performed at each stage in the boot process, making the system resistant to tampering and able to detect when critical portions of the boot process are altered without authorization.

A user can manually enable full-disk encryption or some automatic process can initiate full-disk encryption but most automatic processes require some user input, such as entering a password from which the system generates the volume key. The tamper-resistant boot process can be used when full-disk encryption is enabled and/or in other situations when some other suitable shared secret is available as a substitute for the full-disk encryption volume key.

FIG. 3illustrates the authentication of a kernel cache, part of establishing a chain of trust from the firmware to the kernel. A system100verifies240that a kernel cache is authentic by computing310an HMAC using an encryption algorithm, the user-entered password and the kernel cache. The system100uses the kernel cache and the password as input to a cryptographic hash function, which outputs the HMAC. The system100compares320the computed HMAC with the stored kernel cache digest to determine if the operating system has been tampered with. If the compared values match330, the operating system has not been tampered with and is considered authentic and the system can continue to boot. If the compared values differ340, the operating system has changed since the kernel cache digest was created and is not authentic. At this point, the system can halt the boot process, prompt the user to reenter the password, send an alert to a remote device, and/or trigger any other desired action.

FIG. 4illustrates a tamper-resistant boot process. The system100verifies that the operating system has not been tampered with by booting the system with firmware410and confirming, via the firmware410, the integrity of the booter420. Once the system confirms the integrity of the booter via the firmware, the system passes control to the booter420. The booter confirms a kernel cache440of the operating system based on a stored kernel cache digest430and password entered at boot time420. The authenticity of the kernel cache is determined by computing450an HMAC using the kernel cache and a user-entered password. Once the boot process determines that the operating system has not been tampered with, the boot process passes control to the operating system for initiation and execution.

FIG. 5illustrates initiation of the tamper-resistant boot process. The system100initiates the tamper-resistant booting process by first generating a volume key510based on a full disk encryption password received from a user. The system100encrypts520the storage medium with the volume key to yield a full disk encrypted storage medium. The volume key can be generated as part of the setup process for full disk encryption and/or a user enrollment process. For example, if a user decides to set up full disk encryption on a storage volume, then the system prompts the user to enter a full disk encryption password or a password equivalent. Then the system generates a volume key based on the full disk encryption password, encrypts the volume with the volume key and can simultaneously use that same volume key for tamper-resistant booting. Then the system100generates530a kernel cache digest using the kernel cache and full disk volume key, which the system100stores on an unencrypted volume540. When the system boots, it verifies the integrity of the kernel cache based on the stored kernel cache digest and a computed digest. In at least one variation, the system100stores the kernel cache digest in a location other than the encrypted storage volume because the boot environment is unable to unlock the full-disk encrypted volume because the unlocking process is too complex and requires a more full featured kernel. Thus the kernel cache cannot reside in the encrypted volume because the booter cannot unlock full-disk encrypted volumes. As a result, the kernel cache resides unencrypted on a volume separate from the full-disk encrypted volume, where the booter can reach the kernel cache without the need to perform decryption of which the booter is incapable. Even though the data is encrypted on a FDE volume, the kernel cache can be completely unprotected and subject to replacement by an attacker.

The kernel can reside on an unprotected volume, so long as a keyed HMAC digest (where the full-disk encryption volume key is used as the digest key) resides next to the kernel. Thus, an attacker can replace the kernel with a malicious one, but since the attacker does not know the full-disk encryption password, the attacker cannot create a matching digest file, and the booter will refuse to boot the malicious kernel.

Having discussed initiation and execution of the tamper-resistant booting process, the disclosure now discusses how to disable tamper-resistant booting of a computing device. A system100must first authenticate a request to disable tamper-resistant booting to verify that the request is valid, and did not come from a hacker. The system verifies that a request to disable tamper-resistant booting is valid by generating a password proof. Since the firmware and the operating system do not run at the same time, traditional approaches offer no viable way for the two processes to communicate with each other. The operating system can send information to the firmware and reboot the machine, allowing the firmware to receive the message from the operating system at boot time. However, in some situations multiple reboots are unacceptable, so the system is allowed to send commands to the firmware only once. The firmware is stored in a non-volatile random access memory (NVRAM) chip that is not writable but is readable by the operating system. The operating system cannot send a raw password since it is stored in plaintext, readable by the operating system. The operating system also cannot send a hash of the password since an attacker can read the hash and trigger the unlock mechanism. The operating system must send data that is unprotected, yet still verify the authenticity of the disable request. This is accomplished using a password verifier and a password proof.

FIG. 6illustrates disabling tamper-resistant booting by generating, at the firmware level, a password verifier and comparing it to a password proof. The system100generates the password verifier610and stores it for later use. The system100receives a request620and a password from a user to disable tamper-resistant boot. The operating system generates630a partial password proof by applying a portion of the number of iterations of the encryption algorithm to the request password and the salt value and then restarts640the computing device. Once the system reboots, the firmware retrieves650the partial password proof and performs660the remaining portion of the number of iterations of the encryption algorithm to yield a complete password proof. If the password proof matches the password verifier, the system100disables tamper-resistant booting670. The system only disables tamper-resistant booting if it can verify that the request is authentic.

FIGS. 7 and 8illustrate generating a password verifier. The system100generates the password verifier by performing multiple iterations of an encryption algorithm, utilizing the output of the preceding iteration as input to the current iteration720. For example, the process uses PV1to generate PV2, and uses PV99to generate PV100. In the case of the first iteration710, a password P is used as input since output from a preceding iteration does not exist. The system100generates the password verifier by performing, for example, 100 iterations740. The password proof is derived from the output of one or more intermediate iteration, such as a halfway point iteration730. In addition to using the output from a preceding iteration as input to the encryption algorithm, a salt value is used. A salt value contains random bits that are used as one of the inputs to a key derivation function, usually a cryptographic hash function. Salt data complicates attacks since it increases the amount of storage and computation required to determine a password. To determine a password from a stolen hash, an attacker must calculate the hashes of random characters thereby increasing the required computational time. In some scenarios, this process is limited to being performed by a processor on the device with the full disk encrypted volume. Accordingly, the number of iterations can be selected or determined based on the speed of the processor such that the time required for any attack is a function of the processor's speed and cannot easily be brute forced. The use of any cryptographic hash function in calculating an HMAC is possible, for example SHA-1 or MD5.

The generation of a password verifier requires810a password P, salt value S, the number of iterations to perform n and index i. The system compares820the index i to the number of iterations n to check if the required number of iterations are complete. If they are not equal, the process is not complete and additional iterations are required. Next, the system generates a round password verifier830for the current round, i. The generation830of the round password verifier PViis performed using an encryption algorithm, the password verifier from the previous round PVi−1(if the current round is not one) and the salt value S. Since there is not a previous round verifier for the first round, the password P is used to initialize PV0810. Next, the system increments the index830and compares the index to the number of iterations to check if the required number of iterations are complete820. When the index equals the number of iterations, the process is complete and the system outputs the password verifier840.

The system generates a password verifier and password proof following the same process, with the exception that generating a password proof includes rebooting the computing device. The system performs only a portion of the total number of iterations required, usually half, and then reboots itself. Once the system has restarted, the remaining number of iterations is performed to yield the final password proof.FIGS. 9 and 10illustrate generating a password proof. For example, when the total number of iterations required to generate a password proof is 100, the system generates910a partial password proof using 50 iterations and stores the result before rebooting. Once the system restarts, it retrieves the stored partial password proof and performs the remaining 50 iterations to yield1010the final password proof. The partial password proof can be generated at the halfway point or at some other point in the set of iterations. The partial password proof does not reveal any useful information about the original password, the number of iterations, the password verifier, or the password proof and thus is safe to store in plaintext and/or in a region of memory that other processes can read.

FIGS. 11 and 12illustrate generating a password proof. The system100generates the password proof by performing multiple iterations of an encryption algorithm, utilizing the output of the preceding iteration as input to the current iteration. For example, the process uses PV1to generate PV2, and uses PV99to generate PV100. In the case of the first iteration, a password P is used since output from a preceding iteration does not exist. In addition to using the output from a preceding iteration as input to the encryption algorithm, a salt value is used.

The generation of a password proof requires1110a password P, salt value S, the number of iterations to perform n, index i and index j, where j is the number of iterations divided by two. The system compares1120the index i to the index j to check if the required number of iterations are complete. If they are not equal, the process is not complete and additional iterations are required. Next, the system generates a round password verifier1130for the current round, i. The generation1130of the round password verifier PViis performed using an encryption algorithm, the password verifier from the previous round PVi−1(if the current round is not one) and the salt value S. Since there is not a previous round verifier for the first round, the password P is used to initialize PV01110. Next, the system increments the index1130and compares the index to the number of iterations to check if the required number of iterations are complete1120. When the index i equals the index j, the system stores the partial password proof1140and reboots the computing device.

Once the computing device reboots, the firmware computes the remaining iterations to yield a complete password proof. The index i is initialized1210to j+1 since half of the iterations have already been performed. The system compares1220the index i to the number of iterations n to check if the required number of iterations are complete. If they are not equal, the process is not complete and additional iterations are required. Next, the system generates a round password verifier1230for the current round, i. The generation1230of the round password verifier PViis performed using an encryption algorithm, the password verifier from the previous round PVi−1and the salt value S. Next, the system increments the index1230and compares the index to the number of iterations to check if the required number of iterations are complete1220. When the index i equals the number of iterations n, the process is complete, and the system outputs1240the complete password proof, PVa.

FIG. 13illustrates generating a password proof. The partial password proof is secure, since it is not the raw password but a derivation of the password. A system100stores it in NVRAM1310for any process to read, even potentially malicious processes. A process must be in possession of the original password1320to get the proof to the halfway point. Then the firmware1330can iterate through the remaining iterations to verify that the proof came from a process that possessed the original password. This process lends itself to automatic improvement as hardware improves, since it runs the HMAC iteration in a loop until a set amount of time is reached and can easily adapt to newer, faster hardware. Faster hardware can simply run a higher number of iterations to achieve similar performance characteristics. The number of iterations can be selected or determined based on desired execution performance, security, and/or other characteristic threshold(s).

FIG. 14illustrates disabling full disk encryption. The system generates1410a list of users authorized to disable tamper-resistant booting and sends1420the list to the firmware. The system generates1430password verifiers for each user and stores the verifiers as software1340in the NVRAM1310. When the system issues a command with a password proof for a user, the system puts the password proof into a “dropbox” for the authenticated command interface (ACI) where the NVRAM1310reads the command on the next boot. Since the NVRAM is readable to the operating system and all users, any user can read the command placed in NVRAM and potentially steal the password proof. Traditionally, a salt is used to fix this problem. However, this is not easily accomplished. Thus, the system creates a system salt1440and stores the system salt in NVRAM1450when the machine boots the first time. The system salt stored in NVRAM is used for the next command issued to the firmware through the ACI interface. The firmware puts a new random salt in NVRAM each time a command is issued.

One new result achieved by the approaches set forth herein is a more secure boot process in a full-disk encryption enabled system that is able to detect unauthorized changes in the boot chain of trust. Another result of these approaches is enabling and/or disabling this secure boot with a minimal number of system reboots.

The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. For example, the principles herein are applicable to desktop and laptop computers, mobile devices, and any other computing environment with a suitable shared secret, such as a volume key, in which a secure, tamper-resistant boot process is desired. Those skilled in the art will readily recognize various modifications and changes that may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.