Password Storage

The password information must be stored in non-volatile storage. The legacy BIOS typically uses the CMOS RAM as the non-volatile storage (NVS). The standard CMOS RAM only has 128 bytes, and the extended CMOS RAM has another 128 bytes. The CMOS RAM can be read/written via I/O port 70/71 and I/O port 72/73. The memory of the CMOS RAM is maintained by the CMOS battery. If an end user removes the CMOS battery, the CMOS contents are cleared.

The CMOS region is not tamper-resistant. If the password is stored in CMOS, it can easily be attacked. The attacker may write to port 70/71 to update the CMOS RAM directly or clear the CMOS contents by removing the CMOS battery.

Today, the UEFI BIOS no longer uses CMOS RAM for non-volatile storage because of the above-listed security issues. A tamper-resistant storage device must be used to store the encrypted password. Most UEFI BIOS implementations use the flash device as the non-volatile storage for storing the password in UEFI variables. The integrity protection must be guaranteed for the portion of the flash device used for the password.

Password Encryption

The password should not be stored in the non-volatile storage directly as plain text. Rather, it must be encrypted to maintain its confidentiality so that the password cannot be guessed from the value stored in the non-volatile storage. Typically, the password is encrypted using a one-way function – a hash. This hash (not the password) is stored in the NV storage. The password verification process calculates the hash of the input password with the same one-way function and compares the results between the calculated value and the stored value.

However, just storing the hash of the password is vulnerable to a rainbow table attack. The rainbow table is a database of precalculated hash values for common passwords. With a rainbow table, the attacker just needs to compare the value in the rainbow table and the stored value, which is much faster than hash calculation.

In order to mitigate the rainbow table attack, a salt value should be appended to the password before performing the hash calculation. The password verification process is as follows: get the salt value from the stored area, calculate the hash of the input password and salt, and then compare the calculated value with the stored value. When using the salt value, the fixed rainbow table is useless. The salt should not be a fixed value. It must be as random as possible. For example, each platform should generate the salt value at runtime to make sure it is different between platforms. When a user changes the password, a new salt value can be generated.

The purpose of adding the salt is to make sure that the hash reverse calculation time is closer to that of a brute force attack rather than the much lower time required when using rainbow table lookups.

Another method to increase hash reverse calculation time is to increase the hash iteration count. The hash iteration count is the number of times that the output of the hash function is then used as input and the result is calculated again and again. With a large iteration count such as 1000, the attacker needs to spend much more time to calculate the final result for each password in the dictionary. But the impact to one password calculation is negligible compared to the time the user spends to input the password.

When choosing the one-way function for calculating the hash, a slow hash function should be used, for example, Password-Based Key Derivation Function 2 (PBKDF2). The slower time means that an attacker must spend more time to create the rainbow table to perform the attack.

The recommended encryption algorithm is shown in Figure 10-2. The BIOS should adopt all good practices for a BIOS password solution.

Strong Password Enforcement

Even today, people are still inclined to use a simple password, such as 123456. When inputting or provisioning the password, the BIOS should enforce strong password requirements. Examples include the length of the password must be greater than or equal to eight, and also there must be at least one lowercase/uppercase letter, number, and symbol in the password. The BIOS should enforce the strong password requirements and reject weak passwords during provisioning.

Password Update Enforcement

Some computer systems have mandatory password change requests. The user is required to change the password of the system after a period of time, such as three months. This requirement may also be implemented in the BIOS. For example, the BIOS can save the date when the password is created along with the password storage and compare the current date with the stored value. However, it might be a burden for an end user to keep changing the BIOS password. Also, the PC typically doesn’t support a trusted time source, so enforcement of this requirement could be bypassed by an attacker.

Password History

Password history is the hash of previous passwords, such as the three latest passwords or five latest passwords. If the user is asked to change to a new password, some systems check if the new password has been used before by comparing the hash to the previous ones. This is a way to prevent a user from using an old password again. The BIOS may also implement this feature by saving the old password hash and salt data in order to compare the new password hash with them.

Password Retry Limit

In the normal OS or web login pages, the user is only allowed to attempt the password entry a limited number of times, such as three times or five times. After failing the predefined number of iterations, the account will be locked for a while to prevent further attempts.

BIOS password design should use a similar mechanism. If the maximum trying count is reached, the BIOS should stop accepting any further password input. The user needs to reset the system before trying again.

Password Lost

Sometimes the user really forgets their password. Most web pages support the reset password option. After a user clicks the forget password link, the system sends a new link to the end user’s registered email or cellphone. However, it is hard to implement such a solution in the BIOS because it requires a full network stack in the BIOS, a full user registration process, and a dedicated database for BIOS user management. Those are huge burdens for a BIOS implementation and the system manufacturer.

The platform designer must balance between the usability and security of the system. A high-assurance platform may request the platform be sent back to the manufacturer to unlock, such as with a return merchandise authorization (RMA) process. An alternative solution is to let the user submit a password reset request via another machine with the proper user identification and allow the remote administrator to clear password via an out-of-band (OOB) method. A low-end platform may allow the end user to press a special key combination or enter a recovery mode to clear a new password with the assertion of physical user presence if the person who touches the machine is assumed to be the owner of the machine.

Password Verification

Password verification or update must be in a trusted execution environment, for example, system management mode (SMM) or the early UEFI environment before any third-party code is running. If the password needs to be updated, the old password verification and new password update must happen in the same trusted execution environment, and there must be no interruption between them.

Password Management

The typical BIOS password is stored in the local NV storage area. However, the system password may be managed by a dedicated key server in an enterprise environment. For example, Kerberos is a network authentication protocol used in operating systems such as Windows or Linux. With Kerberos, the client sends the user identity and credential to the remote Kerberos server. The user information and password are stored in the Kerberos server, and the authentication happens in the Kerberos server.

The BIOS may implement the Kerberos client. Once a user inputs the password credential, the BIOS Kerberos client communicates with the remote Kerberos server to finish the user authentication. Care must be taken for the location of the remote Kerberos server. If the server location is saved in the UEFI NV storage region, this data must be protected. Otherwise, the attacker may try to modify the location of the Kerberos server and redirect the action to a fake server.

BIOS Update Mode

If the encrypted user password is saved in the NV storage area, this password information should be preserved during the BIOS update process.

S3 Resume Mode

S3 resume is a resource-constrained execution environment because the primary goal of a S3 resume boot mode is to restore the system configuration and return to the OS as soon as possible. As such, a typical S3 environment does not have the keyboard device driver or the graphic device driver. It is hard to authenticate a user in the S3 resume phase.

Recovery Boot Mode

Recovery boot is another special environment where the UEFI variables might not be available. If the user information and credential are saved to the UEFI NV storage area, they cannot be retrieved during recovery mode. As such, the user authentication may be skipped. If the user authentication is important for an authorized capability, such as continuing to boot, then the authorized capability will be disabled in recovery mode.

User Enroll Enforcement

Some systems or web pages may enforce the enrollment of a username and password at the first boot or at the first web visit. The BIOS password may use this policy as well to enforce user input of a password during the first boot.

Multiple-User Management

A typical BIOS may support the user password and the administrator password. To support multiple users requires more work because the BIOS needs to save the user identity. The purpose of enabling multiple users is to assign different privileges for different users. For example, user A can boot Windows, and user B can boot Linux. If all users have the same authority to boot the OS, then multiple-user support is not required.

Single Sign-On

Single Sign-On (SSO) may be a use case for the multiple users in the BIOS. Once the user authentication is done in the BIOS, the BIOS may pass the user identity and credential to the OS. There are a couple of technical issues that need to be considered. For example, how does the BIOS protect the credential in the memory when the BIOS passes the information to the OS? How does the BIOS handle the situation when the user changes the password in the OS environment? How does the OS trust the information from the OEM BIOS?

EDK II User Authentication

The EDK II BIOS provides a reference implementation for user authentication. A user needs to input a password to enter the BIOS setup UI page to change the BIOS settings, for example, to change the boot option from “boot from hard drive” to “boot from USB device.” As such, only the authorized user is allowed to change such settings.

The EDK II user authentication solution includes two parts. The first part is a password User Interface (UI). It accepts the end user input, puts the password into the SMM communication buffer, and triggers the system management interrupt (SMI). The second part is the password verification. It is inside of the trusted execution environment – the system management mode (SMM). Once the SMI is triggered to call the password verification handler, the handler copies the password from the SMM communication buffer into the SMM environment. Then the password verification handler reads the password salt value and stored hash value from the UEFI variable. Next, the verification handler calculates the real hash value from the salt and the real password. Finally, the password verification handler compares the real hash with the stored hash. If they are the same, then the password verification passes. If they are different, the password verification fails. See Figure 10-3.

The password update follows a similar process. The user needs to input an old password and a new password twice. All of these passwords need to be put into the SMM communication buffer. The password verification handler copies these passwords to the SMM environment and verifies the old password. Once the verification passes, the password driver creates a new salt and calculates the new password hash based upon the new salt and new password. Finally, the new salt and new password hash are saved to the NV storage area. The old salt and password hash are moved to the history variable. See Figure 10-4.

EDK II User Authorization

In the traditional BIOS, a user is authorized to boot the system, and an administrator is authorized to enter the BIOS setup page and modify the setup options. It is also possible that a BIOS may authorize the user to view the BIOS setup page information or authorize the user to modify some basic BIOS settings, such as the boot options.

Traditional Password Attack

The traditional password attacks include brute force attack against a weak password, dictionary attacks, and a rainbow table attack. There might also be a non-standard password encryption algorithm attack.

Some firmware-specific attacks are as follows.

Password Memory

The password is input from the end user via a keyboard. The keystroke is saved in the keyboard-specific memory. If the keyboard memory is not cleared, the attacker can read the whole keyboard memory. In legacy systems, the keystroke is saved in a fixed BIOS data area (BDA). That key buffer in the BDA must be cleared.

The UEFI BIOS does not use BDA. The keystroke is saved in the keyboard driver directly. However, the UEFI BIOS uses Unicode to save the key data. The Unicode buffer needs to be converted to an ASCII buffer and input to the SMM communication buffer. When the final code clears the key buffer, both the Unicode buffer and the ASCII buffer need to be cleared. It could be in a global data region, stack, or heap.

Encrypted Password Storage

The password storage must be tamper-resistant. If the legacy BIOS uses the non–tamper-resistant storage, such as the CMOS region, then the attacker can easily modify the password storage area or clear the password area in order to log into the system.

The UEFI variable storage is tamper-resistant. When the variable is deleted, though, the UEFI variable implementation does not erase the whole variable buffer but instead sets a bit to indicate that the variable is deleted. This is designed because of the hardware attribute of NOR SPI flash. The NOR flash can easily write a bit value of 1 to 0 but cannot write a bit location of value 0 to 1. If the NOR flash needs to set a bit value of 0 to 1, it needs to send an erase command to erase the flash section or block whose size is 4 K or 64 K instead of 1 bit or 1 byte.

If the UEFI solution needs to save the password plain text in the variable region and then delete it, the password content will be in the variable region. As a mitigation, the password plain text should never be put in the variable region.

UEFI Secure Boot

The UEFI secure boot feature requires executable image verification using an image signature database. The image signature database can be updated with authorization. According to the UEFI specification, the update of the image signature database needs to be signed by the platform key (PK) provided by the platform vendor or the key exchange key (KEK) provided by the operating system vendor. Otherwise, the platform needs to have a secure platform-specific implementation of this update. The EDK II uses the physical user presence as the secure platform-specific means by which to authorize the update of the secure boot image signature database. See Figure 10-5 for the two update methods.

In EDK II, the variable driver uses the AuthVariableLib to control the secure boot–related authentication variable update (see Figure 10-6). The AuthVariableLib invokes the PlatformSecureLib UserPhysicalPresence() function to determine if the physical presence is asserted or not.

PCD-Based Attack

The physical user presence check may happen in the trusted execution environment (TEE), such as system management mode (SMM). As such, the physical user presence function in SMM must not refer to any non-TEE data or function, such as the UEFI Platform Initialization (PI) specification–defined Platform Configuration Database (PCD). The PCD interface is a DXE service only. Referencing the PCD service at SMM runtime causes the typical SMM callout issue. The one possible mitigation is to get the PCD value at the SMM driver entry point and save it as a global variable. Afterward, this global variable can be used during the SMM runtime.

TCG Physical Presence

Operations 1~95 are for TPM2 management. All of these commands need platform auth and must be executed by the platform firmware. The physical presence check can prevent the TPM2 device from being compromised by a malicious program.

Operations 96~127 are for TCG storage devices. The physical presence check can prevent a malicious entity from taking ownership of a SID credential that is still set to its default value of MSID.

The pros and cons for each option are obvious. With physical presence control, a malicious software entity cannot control the system. It is proper for a high-assurance system. Software control, on the other hand, makes it easier for configuration automation. See Figure 10-7 for the two update methods.

The TCG Physical Presence (PP) also defines a set of operations to control the two options. For example, the user may perform the SetPPRequiredForClear_False operation and confirm the action. Then, the next time the software sends the TPM clear command, no user confirmation is required.

In EDK II, the TCG2PhysicalPresenceLib uses the PP variable to manage the TPM2 or TCG storage (such as OPAL, Opalite, Pyrite, or Ruby) device state. There are two PP variables – one is PP request variable that records the PP request and PP parameters, and the other is PP flags variable that records the PP management flags and the device states. The PP request variable is a read/write variable because everyone can send the PP request. The PP flags variable is a read-only variable because it records the final user-confirmed flags or states, which is used to set the TPM2 or TCG storage device state. Figure 10-8 shows the TCG PP Configuration Component Design.

According to the TCG PP specification, the PP request is submitted from the OS via the ACPI ASL interface. Typically, the ASL generates a software SMI whose handler records the PP request and its parameters to the PP request variable. On the next boot, BDS processes the TCG PP request via the Tcg2PhysicalPresenceLib. The Tcg2PhysicalPresenceLib pops up a UI to let the user confirm the request based upon the request. Once the PP request is confirmed, the Tcg2PhysicalPresenceLib has two ways to process the PP request. 1) If the request takes effect once, such as to clear TPM or set the TPM PCR bank, the PP library sends the command to the device immediately. 2) If the request takes effect on every boot, such as setting the BlockSID auth, disabling the TPM, or changing PPRequiredForXXX flags, the PP library records the information in the PP flags variable. Whether or not there has been a PP request, the PP flags variable should always be locked. On every subsequent boot, the TCG2 PEIM and the OPAL storage driver consume the PP flags variable information in order to set the TPM2 device state and set the BlockSID auth.

PP Flags Variable Attack

The PP flags variable records the expected device state and the need to request user confirmation. An attack may try to update the variable to bypass the user confirmation. Ideally the PP flags variable should be locked on every system boot.

One vulnerability we have seen before is when the PP flags variable is not locked during S4 resume. Because the TCG PP specification requires skipping the TCG PP process on the S4 resume path, the PP library might accidentally skip everything during S4 resume including locking the TCG PP flags variable.

Another vulnerability is during S3 resume. The OPAL PEI S3 driver uses a special read/write variable to record the TCG BlockSID request. As such, the attacker may change that variable to cause the driver to modify the TCG OPAL device state.

The mitigation is to make any TCG PP variable a read-only variable and lock the PP variable in every possible boot mode.

ATA Password

This feature is implemented in EDK II. Once the hard disk drive (HDD) is discovered, the HddPassword driver pops up a dialog to let the end user input the password. The HddPassword driver uses the password to unlock the hard drive and then saves the password hash and salt into the UEFI variable for a warm reset. The password and the device information are also saved into the LockBox for use during S3 resume. See Figure 10-9.

If the hard disk drive is already unlocked by the warm reset, the HddPassword driver needs to encrypt the password and compare it with the encrypted password stored in the UEFI variable. Then the password and the device information are also saved in the same LockBox for S3 resume. See Figure 10-10.

During S3 resume, the PEI HddPassword driver retrieves the password from the LockBox and uses it to unlock the hard drive. This action does not need any user interaction. See Figure 10-11.

The user may want to update the HDD password in the BIOS setup page. Because the BIOS setup UI is not in the platform manufacturer auth environment, setting a new HDD password is not allowed. As such, the user can only send the password update request and reset the system. During the next boot, the HddPassword driver detects the password update request and processes it. It shows a dialog to let the user input the current password and the new password. The current password is used to unlock the device. The new password is used to lock the device. Once that is done, the encrypted new password is saved into a UEFI variable, and the new password is saved into the LockBox. See Figure 10-12.

TCG Storage Password

The ATA/ATAPI command set is only for ATA/ATAPI devices. However, there are other storage devices such as those attached to other buses, such as the Small Computer System Interface (SCSI), Universal Serial Bus (USB), Non-Volatile Memory Express (NVMe), and so on. How can we support the similar security features on those storage devices? The Trusted Computing Group (TCG) storage group defines common security services that allow all storage devices to support the storage device password.

The TPer may contain one or more Security Providers (SPs). A Security Provider is a set of tables and methods that control the persistent trust state of the SP or TPer. Each SP has its own storage, functional scope, and security domain. A Security Provider includes tables, table content, methods, authorities, access control lists (ACLs), and access control elements (ACEs). See Figure 10-13.

The only way to communicate with an SP is via a session. Only the host is able to open a session. Methods are invoked within sessions. In order to start a session, the host needs to indicate the 8-byte SP Unique Identifier (UID) – which SP the host wants to communicate – the 8-byte Host Signing Authority UID, and the host challenge data for the Host Signing Authority. Within the session, the host may invoke the method provided by the SP, and the host needs to indicate the 8-byte invoking ID (such as session manager, this SP, table UID, object UID) and 8-byte method ID – the method provided by the invoking ID and the method parameters.

See Figure 10-14. In order to unlock the TCG storage, the TcgOpalPassword driver needs to create a session for communication with OPAL_UID_LOCKING_SP with the Signing Authority being OPAL_LOCKING_SP_ADMIN1_AUTHORITY and host challenge data being the user input password. To start a session, the TcgOpal driver sends a CALL method with the invoking ID being TCG_UID_SMUID and the method being TCG_UID_SM_START_SESSION. The parameters of the start session method are SP UID, Signing Authority ID, host challenge, and so on. After the session is created, the TcgOpalPassword sends the second CALL method with the invoking ID being OPAL_LOCKING_SP_LOCKING_GLOBALRANGE and method ID being TCG_UID_METHOD_SET. The parameter is ReadLocked=FALSE and WriteLocked=FALSE. After this command is received by the device, the device is unlocked. Finally, the TcgOpalPassword driver sends the ENDSESSION token to the device to close the session.

Compared with ATA security features, the TCG defines a more complicated method of host/device communication. The benefit of this approach is that device functionality is abstracted as the method within the SP.

Figure 10-15 shows the second example, to set a new admin password. This is a more complicated case. Totally three sessions are involved. First, the TcgOpalPassword driver creates a session with OPAL_UID_LOCKING_SP with OPAL_LOCKING_SP_ADMIN1_AUTHORITY and old password. The purpose of this step is to verify the password. If the password verification fails, the driver will stop and pop up an error message to the end user.

Second, after the verification passes, the TcgOpalPassword driver creates the second session with OPAL_UID_ADMIN_SP with the OPAL_ADMIN_SP_SID_AUTHRITY and the old password. After the session is created, the TcgOpalPassword driver invokes the CALL method with invoking ID being OPAL_UID_ADMIN_SP_C_PIN_SID and the method ID being TCG_UID_METHOD_SET. The parameter is the PIN column number and the new password. This session is to update the PIN in the ADMIN_SP.

Third, the TcgOpalPassword driver updates the PIN for the LOCKING_SP. It creates a session with OPAL_UID_LOCKING_SP again and invokes a new CALL method with invoking ID being OPAL_LOCKING_SP_C_PIN_ADMIN1 and method ID being TCG_UID_METHOD_SET. The parameter is the PIN column number and the new password.

After those steps, the PIN is updated in both the ADMIN_SP and the LOCKING_SP.

The CALL method or the ENDSESSION are the token in the data buffer. The OpalPassword driver adds three headers – TcgComPacket, TcgPacket and TcgSubPacket before the data buffer and constructs the whole data block. Once the data block is passed to the storage driver, the storage driver adds the storage secure command block (IF-SEND or IF-RECV, Security Protocol ID 0x1, ComId) and sends the whole message to the TPer device. See Figure 10-16.

TCG Storage – SID (Secure Identifier)

The Security Identifier (SID) authority is used by TPer owner, also known as the storage device owner, to authenticate to the Admin SP. After getting the device, the user may take the ownership by changing the SID Personal Identification Number (PIN). Figure 10-15 shows how to set the admin password.

TCG Storage – MSID (Manufactured SID)

When a TCG Storage device is shipped, it may carry a Manufactured SID (MSID) credential set at the manufacturing time by the storage device vendor. The MSID does not have any associated authority and it may be read by anybody. The MSID value can be used as the device initial SID value – the device owner’s password. Once the user takes ownership, the user may input the MSID value to the SID authority in the admin SP then set a new SID value to replace the default MSID value.

See Figure 10-17. To perform the MSID read, the OpalPassword driver communicates with OPAL_UID_ADMIN_SP with NULL authority and NULL host challenge, and then the driver invokes the OPAL_UID_ADMIN_SP_C_PIN_MSID read method with column OPAL_ADMIN_SP_PIN_COL to read the MSID data from the device.

At this point we can enable the admin password for the first time by using the MSID credential (See Figure 10-18). The OpalPassword driver communicates with OPAL_UID_ADMIN_SP with OPAL_ADMIN_SP_SID_AUTHORITY and MSID as the host challenge. Then the OpalPassword driver invokes the CALL method with invoking ID being OPAL_UID_ADMIN_SP_C_PIN_SID and method ID being TCG_UID_METHOD_SET. The parameter is the PIN column number and the new password. This session is to update the PIN in the ADMIN_SP.

After that, in the same session the OpalPassword invokes the CALL method with invoking ID being OPAL_UID_LOCKING_SP and method ID being OPAL_ADMIN_SP_ACTIVATE_METHOD, to activate the locking SP.

TCG Storage – BlockSID

Sometimes, the ownership of the TCG storage device is not taken. The SID PIN is the default MSID. In order to prevent a malicious program from taking ownership with default MSID, the BIOS needs to block SID setting. The storage driver uses the storage secure command block (IF-SEND or IF-RECV, Security Protocol ID 0x2, ComId 0x0005 BlockSID) and sends the message to the TPer device to enable the BlockSID. See Figure 10-19.

From the BIOS perspective, there is a policy that determines whether the BIOS needs to send the BlockSID command or not. TCG storage reuses the TCG Physical Presence solution to process the BlockSID enable/disable request from the OS and uses a read-only variable to store the policy information. See Table 10-1.

TCG Storage – PSID (Physical Presence SID)

If a user or an admin forgets the TCG storage password and still wants to use the device, he or she may use the Physical Presence SID (PSID) revert. The PSID revert resets the SID PIN to the default MSID and may erase all media encryption keys. As a consequence, the user data is destroyed. The PSID feature was designed so that if the user forgets the password, the user may input the PSID credential value to revert the device. The PSID delivery method is vendor specific. One simple solution is to print the PSID credential value on the device label. Any physical user who can touch the device can get the PSID value.

See Figure 10-20. To perform the PSID revert, the OpalPassword driver communicates with OPAL_UID_ADMIN_SP with OPAL_ADMIN_SP_PSID_AUTHORITY and PSID as the host challenge, then sends the OPAL_ADMIN_SP_REVERT_METHOD to revert the data on the device.

TCG Storage – TPer Reset

The platform reset attack may get the secret in the memory. In order to mitigate the reset attack to memory, the TCG defines the Memory-Only Reset (MOR) feature to inform the BIOS to clear memory after an abnormal reset. We have discussed that feature in Chapter 7. The storage device may experience a similar platform reset attack because the protected region may be unlocked after the platform reset. In order to mitigate the attack to the storage device, the BIOS needs to issue a TPer Reset command once the BIOS detects the MOR request. After TPer reset, all protected regions are locked again.

The storage driver uses the storage secure command block (IF-SEND or IF-RECV, Security Protocol ID 0x2, ComId 0x0004 TPerReset) and sends the message to the TPer device to issue TPerReset. See Figure 10-21.

No HDD Freeze Lock / TCG BlockSID

The HDD Freeze Lock and the TCG BlockSID feature are designed to prevent the attack by a malicious program in the operating system (OS) to take ownership of a device. The OS may want to take ownership of the storage device, or the OS might not take ownership by setting a new password to the storage device. This is a policy set by the OS. The TCG defines the physical presence (PP) interface for the policy passing from the OS to the BIOS via the ACPI method. Similar to the TPM PP interface, the storage PP interface also saves the storage management flag to a UEFI variable. This UEFI variable must be locked in any boot mode, including normal boot and S3 resume.

One vulnerability we have found before is that the BlockSID command is only sent in a normal boot, but not sent during S3 resume. Then the malicious program just needs to trigger an S3 resume then takes owner control of the device. The TCG storage driver should consume this storage management flag variable to send the BlockSID command in S3 resume as well if necessary.

No TCG TPer Reset

TPer Reset commands should be sent when the BIOS detects the MOR request. In order to issue a TPer reset to all hard drives, the platform needs to detect all the hard disks and restart all of them. However, some BIOSes may implement a fast boot path and only connect the boot device. That brings the risk that the TPer reset is not sent to the rest of the devices. The mitigation is that once the platform BIOS detects the MOR request, the platform BIOS quits the fast boot path and enumerates all the hard drives. Then the MOR driver discovers all hard drives and sends the TPer reset to all of them.

WIFI network

The physical layer of the network could be a wired network device or a wireless network such as Wireless-Fidelity (WIFI). In order to support connecting to a WIFI network, the user may be asked to input credentials for authentication. In client mode, the WIFI network uses the pre-shared key (PSK), also known as WIFI password, for authentication. In enterprise mode, the WIFI network uses IEEE 802.1X port authentication and the Extensible Authentication Protocol (EAP) authentication method.

For the PSK use-case, the user needs to input the WIFI password to connect the network. The question is if the BIOS needs to store the WIFI password. On the one hand, if the BIOS does not store any WIFI password, then the user is required to input the WIFI password whenever he or she wants to connect to the same WIFI network. That is a different user experience compared with the OS environment. On the other hand, if the BIOS stores the WIFI password in a UEFI variable or a configuration file, the plain text data may be exposed to any program. This solution may bring a security concern. The BIOS may choose to encrypt the WIFI password with a key. Now the problem is how to get the key in the boot. If the user is asked to input the key, we go back to the original problem – user interaction is required.

There is no simple answer on how to handle a WIFI password in the BIOS. The solution must balance the usability and the security.

Bluetooth

A UEFI BIOS may include Bluetooth support, such as a Bluetooth keyboard or mouse. Bluetooth device connection may also require authentication, such as numeric comparison, passkey entry, or an out-of-band mechanism. Once the device and host pairing is successful, a pairing key is generated. The UEFI implementation may choose to save the pairing key for future use. However, the integrity and the confidentiality of the pairing key might be a concern if the platform saves the pairing key plain text to a UEFI variable. That should be considered when implementing a Bluetooth auto-reconnection feature.

TCP/IP Network Security

Because the firmware may include the TCP/IP network stack, the network security features could also be implemented, such as Transport Layer Security (TLS) or Internet Protocol Security (IPSec). For the TLS example in Figure 10-22, the UEFI BIOS acts as a TLS client and initiates the connection with a remote server via a normal TLS session. The UEFI implementation may choose no-authentication, one-way authentication or mutual authentication. 1) If the TLS session uses no-authentication, the client and server won’t send any certification to each other. 2) If the TLS session uses one-way authentication – the client needs to authenticate the server. The UEFI client needs to provision the server public certificate in the UEFI authenticated variable. After the server sends the server certification and signing data in the handshake, the client will compare the server certificate and verify the server signature in order to finish the server authentication. 3) If the TLS session needs mutual authentication, things become complicated because the UEFI BIOS does not have an architectural way to save the client private certificate to sign the data. The UEFI variable cannot be used because the UEFI variable does not provide confidentiality support. One possible solution is that the client needs a special Trusted Execution Environment (TEE) feature to save the client private certificate. Then the BIOS gets the private certificate from the TEE at boot time and signs the client data to allow the server to authenticate. The TEE needs to close the service to return the private certificate after the BIOS boot.

Private Certificate Storage Attack

The management of the private certificate or private key in the UEFI BIOS is always a big challenge. If it is saved in the UEFI Variable region, it becomes a problem because the UEFI Variable only provides the integrity support but not confidentiality support according to the UEFI Specification. Adding the certification management in the UEFI Variable might be an overhead because we may enable data encryption with the user password, which means user interaction is required. As an alternative, we can leverage the TPM non-volatile storage and key hierarchy to manage the private key, with the option to bind to a platform instead of a user. Another choice is to let a TEE maintain the private key, such as the Intel Converged Security and Management Engine (CSME). Care must be taken to keep the key service in the BIOS only accessible before any third-party code running and close the service before booting into the OS.

TLS Hostname Attack

The network security in the UEFI BIOS supports peer authentication. The UEFI client side may need to authenticate the server. One TLS issue in EDK II that has arisen before is about the peer hostname verification. Here is the issue: The server certificate has a Common Name (CN) for the subject. This name is used to match the hostname of the server site. The expected behavior from the client side is 1) to verify the hostname (identification), 2) to verify the certificate (authentication). The early version of UEFI TLS only verified the server certificate, but not the hostname, which brings in the potential of a man-in-the-middle attack.

TPM2 Hierarchy Auth Value

During system boot, the platform BIOS needs to take over the platform hierarchy by sending TPM2_HierarchyChangeAuth (TPM_RH_PLATFORM) command with a platform auth value. After this command is executed, the further access to the platform hierarchy requires the platform auth value. Usually the BIOS just creates a random value whose length is the same as the size of the TPM supported hash algorithm, uses this random value as the platform auth value, and discards the random value after the command is sent. This is to prevent a malicious program from controlling the platform hierarchy at the OS runtime.

EC Access Passcode

An Embedded Controller (EC) is a microcontroller in a system to control various devices such as keyboard, thermal, battery, Light Emitting Diode (LED), and so on. Some EC implementations require a passcode to unlock the EC to allow the EC firmware update (see Figure 10-23). This is designed to prevent the malicious program from performing an EC firmware update directly. Ideally, the platform BIOS generates an ephemeral value and programs the value to the EC as the passcode. The passcode should be discarded in the BIOS environment but saved in a TEE environment. Later when there is a need to update the EC, the TEE should use the saved passcode to unlock the EC and perform the update.

Smart Battery Access Code

In order to prevent malicious access to the device, the smart battery requires an access code to switch the battery mode from sealed mode to unsealed mode, and from unsealed mode to full access mode. Only after the program sends out the right access code can the battery mode can be switched.

Default Password or Static Password

If a platform uses the default manufacturer password or a hardcoded static password to unlock the device, the password can be easily retrieved by the attacker if the attacker searches the device data sheet or reverse engineers the firmware code. A platform should always apply the best practices for the device password, such as not hardcoding a password in the firmware, do not use the same manufacturer password for the device, use different passwords for different devices and different platforms.

S3 Resume Attack

The platform BIOS needs to send a TPM2_HierarchyChangeAuth (TPM_RH_PLATFORM) command to take over the TPM2 platform hierarchy in the normal boot to prevent a malicious program from controlling the platform hierarchy. This action should also be considered in the S3 resume because the malicious program may perform the S3 attack against the TPM2 device. If the TPM2 device is suspended successfully, the BIOS uses the TPM2_Startup(State) to resume the TPM2 state. However, if the attack performs the system reset without letting the OS suspend the TPM2 device, the TPM2_Startup(State) will fail in the BIOS S3 resume. A typical BIOS will send TPM2_Startup(CLEAR) to restart the TPM2. Then the platform auth is reset to NULL. In this case, the BIOS must send the TPM2_HierarchyChangeAuth (TPM_RH_PLATFORM) again to initiate a random platform auth value.