WO2022019910A1

WO2022019910A1 - Read protection for uefi variables

Info

Publication number: WO2022019910A1
Application number: PCT/US2020/043207
Authority: WO
Inventors: Richard Alden BRAMLEY, Jr.; Valiuddin Ali
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-07-23
Filing date: 2020-07-23
Publication date: 2022-01-27

Abstract

Examples of computing devices are described herein. In some examples, a computing device includes a memory and a processor in electronic communication with the memory. In some examples, the processor is to create a read-protected unified extensible firmware interface (UEFI) variable based on an authenticated read access attribute and first authorization information included in a command to create the read-protected UEFI variable. In some examples, the processor is to provide read access to the read-protected UEFI variable based on second authorization information included in a read request.

Description

READ PROTECTION FOR UEFI VARIABLES

BACKGROUND

[0001] Electronic technology has advanced to become virtually ubiquitous in society and has been used to improve many activities in society. For example, computing devices are used to perform a variety of tasks, including work activities, communication, research, and entertainment. Different varieties of electronic circuits may be utilized to provide different varieties of electronic technology.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various examples will be described below by referring to the following figures.

[0003] FIG. 1 is a block diagram illustrating an example of a computing device that may be utilized for providing read protection for Unified Extensible Firmware Interface (UEFI) variables;

[0004] FIG. 2 is a block diagram illustrating another example of a computing device that may be utilized for providing read protection for UEFI variables; [0005] FIG. 3 is a block diagram illustrating an example of a computer- readable medium for providing read protection for UEFI variables;

[0006] FIG. 4 is a flow diagram illustrating an example of a method for providing read protection for UEFI variables; and

[0007] FIG. 5 is a flow diagram illustrating another example of a method for providing read protection for UEFI variables. [0008] Throughout the drawings, identical or similar reference numbers may designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples in accordance with the description; however, the description is not limited to the examples provided in the drawings.

DETAILED DESCRIPTION

[0009] A computing device may be a device that includes electronic circuitry. For instance, a computing device may include integrated circuitry (e.g., transistors, digital logic, semiconductor technology, etc.). Examples of computing devices include laptop computers, desktop computers, smartphones, tablet devices, wireless communication devices, game consoles, smart appliances, vehicles with electronic components, aircraft, drones, robots, smart appliances, etc.

[0010] In some examples of the computing devices described herein, a computing device may include a Basic Input/Output System (BIOS). As used herein, a basic input/output system (BIOS) refers to hardware or hardware and instructions to initialize, control, or operate a computing device prior to execution of an operating system (OS) of the computing device. Instructions included within a BIOS may be software, firmware, microcode, or other programming that defines or controls functionality or operation of a BIOS. In one example, a BIOS may be implemented using instructions, such as platform firmware of a computing device, executable by a processor. A BIOS may operate or execute prior to the execution of the OS of a computing device. A BIOS may initialize, control, or operate components such as hardware components of a computing device and may load or boot the OS of computing device.

[0011] In some examples, a BIOS may provide or establish an interface between hardware devices or platform firmware of the computing device and an OS of the computing device, via which the OS of the computing device may control or operate hardware devices or platform firmware of the computing device. In some examples, a BIOS may implement the Unified Extensible Firmware Interface (UEFI) specification or another specification or standard for initializing, controlling, or operating a computing device.

[0012] In some examples, the BIOS may provide access to hardware resources (e.g., keyboard, display, and other input/output (I/O) devices) after the computing device has booted up. For example, the BIOS may provide an interface (e.g., Unified Extensible Firmware Interface (UEFI)) to enable processes running on the operating system of the computing device to interact with the BIOS. As used herein, these processes are referred to as applications. [0013] The UEFI specification describes a standardized mechanism to read and write variables that can persist across boots of a computing device. In some examples, an operating system may expose an application programming interface (API) to allow applications and kernel mode drivers to perform UEFI variable read and write operations. A UEFI variable may also be referred to as a firmware environment variable. The UEFI specification and corresponding OS APIs may also support writing what may be referred to as authenticated variables. These APIs may allow an entity (e.g., an application, process, driver, etc.) to create a variable that the entity itself can exclusively modify.

[0014] In some examples, the UEFI variables may be protected by a key such that writes made using the key will succeed. In these examples, the write protection is not bound to a particular entity, but the value being written is itself authorized.

[0015] The UEFI specification and corresponding OS APIs may provide restrictions so that the creator (e.g., an entity with control of the key), and not other entities, can modify the variable once created. Flowever, there is no UEFI mechanism or corresponding OS mechanism to restrict an unauthorized entity from reading the contents of the UEFI variable through some level of authorization. Therefore, there is no standardized mechanism for the BIOS of a computing device to return UEFI variable data to authorized applications. For example, the current APIs are designed so that the BIOS returns information stored in UEFI variables to any entity that asks (e.g., makes an API call through the OS to read the UEFI variables). [0016] The examples described herein extend and/or augment the UEFI variable API to provide read protection for UEFI variables. These examples provide an extension that makes little or no changes to the existing API structure for the UEFI variables or OS APIs while restricting unauthorized read access to the intended UEFI variables. Using UEFI variables to store data provides the ability to protect data against tampering as well as resilience (e.g., across an OS recovery). Furthermore, the examples described herein provide confidentiality for the UEFI variables.

[0017] FIG. 1 is a block diagram illustrating an example of a computing device 102 that may be utilized for providing read protection for UEFI variables. Examples of the computing device 102 may include computing devices, laptop computers, desktop computers, smartphones, tablet devices, wireless communication devices, game consoles, vehicles with electronic components, aircraft, drones, robots, smart appliances, etc.

[0018] In some examples, the computing device 102 may include a processor 104 and/or a memory 106. The processor 104 may be any of a central processing unit (CPU), a semiconductor-based microprocessor, graphics processing unit (GPU), field-programmable gate array (FPGA), an application- specific integrated circuit (ASIC), and/or other hardware device suitable for retrieval and execution of instructions stored in the memory 106. The processor 104 may fetch, decode, and/or execute instructions stored in the memory 106. [0019] The memory 106 may be any electronic, magnetic, optical, and/or other physical storage device that contains or stores electronic information (e.g., instructions and/or data). The memory 106 may be, for example, Random Access Memory (RAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), magnetoresistive random-access memory (MRAM), phase change RAM (PCRAM), non-volatile random-access memory (NVRAM), memristor, flash memory, a storage device, and/or an optical disc, etc. In some examples, the memory 106 may be a non-transitory tangible computer-readable storage medium, where the term “non-transitory” does not encompass transitory propagating signals. The processor 104 may be in electronic communication with the memory 106. In some examples, a processor 104 and/or memory 106 of the computing device 102 may be combined with or separate from a processor (e.g., CPU) and/or memory of a host device.

[0020] In some examples, the computing device 102 may include different types of memory 106. For example, the computing device 102 may store certain information (e.g., instructions executed in the operating system) in a first memory type (e.g., DRAM). The computing device 102 may store other information (e.g., variables) in a second memory type (e.g., NVRAM). Therefore, while a single memory 106 is depicted in FIG. 1 , in some examples, the memory 106 may be implemented as different types of memory.

[0021] In some examples, the computing device 102 may include an input/output interface (not shown) through which the computing device 102 may communicate with an external and/or remote device or devices (not shown). The input/output interface may include hardware and/or computer-readable instructions to enable the processor 104 to communicate with the external and/or remote device or devices. The input/output interface may enable a wired or wireless connection to the external and/or remote device or devices. In some examples, the input/output interface may further include a network interface card and/or may also include hardware and/or computer-readable instructions to enable the processor 104 to communicate with various input and/or output devices, such as a keyboard, a mouse, a display, another apparatus, electronic device, computing device, etc., through which a user may input instructions and/or indications into the computing device 102.

[0022] The computing device 102 may create a read-protected unified extensible firmware interface (UEFI) variable 112. In some examples, the memory 106 may include and/or store read-protected UEFI variable creation instructions 108. The read-protected UEFI variable creation instructions 108 may be instructions for creating a read-protected UEFI variable 112 based on an authenticated read access attribute 116 and first authorization information 118 included in a command 114 to create the read-protected UEFI variable 112. For example, the processor 104 may execute the read-protected UEFI variable creation instructions 108 to create the read-protected UEFI variable 112 based on the authenticated read access attribute 116 and the first authorization information 118 included in the command 114.

[0023] In some examples, the processor 104 may implement a BIOS. In some examples, the BIOS may restrict read access to the read-protected UEFI variable 112 based on the authenticated read access attribute 116 and the first authorization information 118. The authenticated read access attribute 116 may indicate that authorization conditions are to be met before the read-protected UEFI variable 112 can be read.

[0024] In some examples, the command 114 may be sent to the BIOS as an API call. In an approach, the API may be a UEFI API. Some examples of API calls used in this approach include a Get Variable call (also referred to as GetVariableO call) for reading a UEFI variable and a corresponding Set Variable call (also referred to as SetVariable() call) for creating and modifying the UEFI variable.

[0025] In some examples for creating and/or modifying the UEFI variable, the caller (e.g., application, process, service, kernel driver, etc.) may specify the following in a Set Variable call: a name (which may be considered a label), a Globally Unique Identifier (GUID) describing the complete namespace for a more comprehensive description and location of the UEFI variable, the attributes that are to be associated with the stored UEFI variable, and the data value itself. In an example, the UEFI attribute VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS may indicate that an authentication condition is to be met before writing to a UEFI variable. An example of the syntax for the SetVariable () call in the UEFI API is illustrated in Listing 1.

Listing 1

[0026] In Listing 1 , VariableName is the name of the variable. VendorGuid is a unique identifier for a vendor. Attributes is an attributes bitmask to set for the variable. DataSize is the size in bytes of the Data buffer. Data is the contents for the variable. In this example, the attribute VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS may be included in the Attributes field as a bitmask value (e.g., 0x00000010).

[0027] In the example of a WINDOWS operating system, the corresponding API call for creating authenticated variables is defined as “SetFirmwareEnvironmentVariableExA().” As used herein, this operation may be referred to as a Set Variable call. The WINDOWS API provides options corresponding to the UEFI API that it is designed to support. In an example, the attribute in WINDOWS that supports writing an authenticated variable is VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS as described above. In another example, in WINDOWS, the attribute VARIABLE_ATTRIBUTE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS may indicate authentication and time stamp conditions that are to be met before writing to a UEFI variable. An example of the syntax for the SetFirmwareEnvironmentVariableExA() call in the WINDOWS API is illustrated in Listing 2.

Listing 2

[0028] In Listing 2, IpName is the name of the variable. IpGuid is the GUID that represents the namespace of the variable. pValue is a pointer to the new value for the variable. nSize is size of the pValue buffer, in bytes. dwAttributes is the bitmask to set UEFI variable attributes associated with the variable. In an example, the attribute

VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS may be included in the dwAttributes field as a bitmask value (e.g., 0x00000010). In another example, the attribute

VARIABLE_ATTRIBUTE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS may be included in the dwAttributes field as a bitmask value (e.g., 0x00000020). [0029] In these examples, the use of the attribute while creating the UEFI variable makes the variable an authenticated variable. With an authenticated variable the data to be stored inside the variable is signed at the time of the writing of the variable with a private key, whose corresponding public key portion is part of the metadata stored with the variable. Some examples of authenticated variables include secure boot database variables.

[0030] When an attempt is made to update the data stored inside an authenticated variable, the new data is also to be signed by the original private key. The BIOS may use the original public key associated with the authenticated variable to verify the signature of the new data. The BIOS may also apply any other conditions (e.g., a monotonic count for restricting replay attacks) as appropriate. Thus, a data signing requirement for an authenticated variable provides a level of protection against un-authorized users modifying the variable value that has been written and/or stored by the creator. [0031] It should be noted that there may be a mismatch between different types of authenticated variables defined in the UEFI specification as compared to what is offered in an OS (e.g., WINDOWS, LINUX, UNIX, etc.). In other words, the UEFI specification may include certain authenticated variables that are not supported by other operating systems.

[0032] Once the variable has been created, the UEFI specification provides a Get Variable call (e.g., the GetVariable() call) to allow the caller to read the value stored in the named UEFI variable. In an example for the GetVariable() call, the caller specifies the name, GUID describing the namespace, size and address of the return buffer as well as a pointer to where to store the attributes associated with this variable. An example of the syntax for the GetVariable () call in the UEFI API is illustrated in Listing 3.

Listing 3

[0033] In Listing 3, VariableName is the name of the variable. VendorGuid is a unique identifier for a vendor. Attributes, if not NULL, is a pointer to the memory location to return the attributes bitmask for the variable. DataSize is the size in bytes of the Data buffer. Data is the contents for the variable.

[0034] In WINDOWS, the corresponding API call to read a variable is defined as “GetFirmwareEnvironmentVariableExA().” An example of the syntax for the GetFirmwareEnvironmentVariableExA() call in the WINDOWS API is illustrated in Listing 4.

Listing 4

[0035] In Listing 4, IpName is the name of the variable. IpGuid is the GUID that represents the namespace of the variable. pValue to a buffer that receives the value for the variable. nSize is size of the pValue buffer, in bytes. dwAttributes is the bitmask to set UEFI variable attributes associated with the variable.

[0036] As implemented in the UEFI specification, the GetVariable() call and corresponding OS-based API calls (e.g.,

GetFirmwareEnvironmentVariableExAO call) do not restrict reading of the data stored for a UEFI variable. Therefore, based on the current UEFI specification, the owner and/or creator of the UEFI variable cannot restrict read access of the UEFI variable to an authorized set of users.

[0037] The examples described herein provide for application-specific secrets to be stored in a read-protected UEFI variable 112 (e.g., an authenticated variable) that the application code may exclusively access. Some examples of data that may be stored in the read-protected UEFI variable 112 include platform-specific keys that an application creates and stores during application installation and/or during application provisioning. In some examples, the data in the read-protected UEFI variable 112 may then be used to identify the specific installation of the application on a specific platform on subsequent runs, which provides a cryptographic biding. In these examples, the information stored in the computing device 102 may be stored in a manner that the information cannot be transferred (e.g., to another computing device), which may result in the information targeted for the computing device 102 being sent to a non-targeted computing device. In these examples, the application may be granted exclusive access to the information stored in the read-protected UEFI variable 112, restricting others from even accessing the information.

[0038] To provide this capability, the BIOS and/or UEFI behind the write and read operations may be modified to recognize a read-protected UEFI variable 112 that is marked with an authenticated read access attribute 116 (also referred to as a protected read attribute) during the write operation. In some examples, the BIOS and/or UEFI may restrict read access to the data in the read-protected UEFI variable 112 unless the right level of authorization is provided as part of a read request 120. In some examples, the read-protected UEFI variable 112 may be implemented without changes to the UEFI specifications or the corresponding OS-based API interfaces for writing and reading of the read-protected UEFI variable 112. Flowever, in other examples, the read-protected UEFI variable 112 may be implemented with a new API format that is not part of the current UEFI standard, as described in FIG. 2. [0039] In some examples, the read-protected UEFI variable 112 may be created by including an authenticated read access attribute 116 in the command 114 to create the read-protected UEFI variable 112. For example, the authenticated read access attribute 116 may be included in the attribute field of a set variable call (e.g., SetVariable() call for the UEFI API or the SetFirmwareEnvironmentVariableEx call for the WINDOWS API).

[0040] In an example, the authenticated read access attribute 116 may be the attribute VARIABLE_ATTRIBUTE_AUTHENTICATED_READ_ACCESS. This attribute may be included in the attributes field (e.g., Attributes for the UEFI API or dwAttributes for the WINDOWS API) as a bitmask value (e.g., 0x80000000) that does not conflict with other attributes in the UEFI. [0041] The authenticated read access attribute 116 may indicate that there are authorization conditions that are to be met before the read-protected UEFI variable 112 can be read. When the authenticated read access attribute 116 is set, the data field of the command 114 may include first authorization information 118. In the example of the UEFI API, the buffer represented by Data may begin with the first authorization information 118 followed by the actual data of the read-protected UEFI variable 112. In the example of the WINDOWS API, the buffer represented by pValue may begin with the first authorization information 118 followed by the actual data of the read-protected UEFI variable 112.

[0042] The first authorization information 118 may include information used to control read access to the read-protected UEFI variable 112. For example, the first authorization information 118 may include a label for the type of authorization method to use (e.g., signatures, Flash-based message authentication codes (FIMAC), etc.). This authorization label may define the size of the first authorization information 118. In another example, the first authorization information 118 may include an authorization value (referred to as a first authorization value), which may include data (e.g., a public key to verify signatures or a secret to use for the FIMAC) used to authorize a read request 120. In yet another example, the first authorization information 118 may include an anti-replay value (e.g., a 64 bit value) to restrict read replays.

[0043] Upon receiving the command 114 (e.g., the Set Variable call), the BIOS may save the read-protected UEFI variable 112 with the authenticated read access attribute 116 and the first authorization information 118 in memory 106. For example, the BIOS may store the read-protected UEFI variable 112 with the authenticated read access attribute 116 and the first authorization information 118 in non-volatile random-access memory (NVRAM). The presence of the stored authenticated read access attribute 116 indicates to the BIOS that the read-protected UEFI variable 112 is to be protected against un-authorized reads.

[0044] In some examples, the memory 106 may include and/or store read access instructions 110. The read access instructions 110 may be instructions for providing read access to the read-protected UEFI variable 112 based on second authorization information 122 included in a read request 120. For example, the processor 104 may execute the read access instructions 110 to provide read access to the read-protected UEFI variable 112 in response to a read request 120.

[0045] In some examples, the read request 120 may be a Get Variable call to an API to access the read-protected UEFI variable 112. In the case of the UEFI API, the read request 120 may be a GetVariable() call. In the case of the WINDOWS API, the read request 120 may be a GetFirmwareEnvironmentVariableExAO call. The Get Variable call may include the second authorization information 122.

[0046] In some examples, when a Get Variable call is made to read the read- protected UEFI variable 112, the BIOS may locate the read-protected UEFI variable 112 in memory 106 (e.g., NVRAM). Because the read-protected UEFI variable 112 is saved with the authenticated read access attribute 116, the Get Variable call may return the real value of the read-protected UEFI variable 112 if the caller provides proper authorization.

[0047] In order to provide authorization when retrieving the value using a read request 120 (e.g., a Get Variable call), the caller may create a read request 120 with second authorization information 122 that contains a second authorization value (e.g., a signature or FIMAC). In some examples, the second authorization information 122 may also include an anti-replay counter (e.g., a 64-bit anti-replay counter).

[0048] In some examples, the second authorization information 122 may be passed to the BIOS via a buffer pointed to by an attributes parameter of the read request 120. For example, in the case of the UEFI API, the second authorization information 122 (e.g., the authorization value, anti-replay counter, etc.) may be included in a buffer pointed to by the Attributes parameter of the GetVariableO call. In the case of the WINDOWS API, the second authorization information 122 (e.g., the authorization value, anti-replay counter, etc.) may be included in a buffer pointed to by the pdwAttributes parameter of the GetVariableQ call. [0049] The BIOS may validate the read request 120 based on the saved first authorization information 118 and the second authorization information 122 included in the read request 120. For example, the BIOS may use the first authorization information 118 passed when the read-protected UEFI variable 112 was set and stored in memory (e.g., NVRAM) and the second authorization information 122 to verify whether the read request 120 will validate (e.g., authorization is successful). For example, the BIOS may determine whether the authorization value included in the first authorization information 118 verifies the authorization value included in the second authorization information 122. If the BIOS verifies the second authorization information 122 using the first authorization information 118, then the BIOS may provide read access to the read-protected UEFI variable 112 to the calling application. Otherwise, the BIOS may restrict read access to the read-protected UEFI variable 112 to the calling application.

[0050] In an example, the first authorization information 118 of the command 114 to create the read-protected UEFI variable 112 may include a public key. This public key may be used by the BIOS to verify a signature included in the second authorization information 122 of the read request 120. In some examples, the BIOS may also check the anti-replay counter to restrict read replays.

[0051] It should be noted that in the example of FIG. 1 , the read-protected UEFI variable 112 may be implemented without altering the UEFI or the OS- provided API signatures of the API, thus keeping the standards-based signature of the API calls intact. This means that applications that use the API with previously-specified API parameters will continue to function without change. The examples described herein may change the implementation of the read and write functions in the BIOS itself. The BIOS may provide the ability to detect new authenticated read access attribute 116 and the first authorization information 118 that are to be stored with the read-protected UEFI variable 112. The BIOS may then protect the read-protected UEFI variable 112 during subsequent read requests 120. It should be noted that applications wanting to use the read- protected UEFI variable 112 may include support for the new flag (e.g., the authenticated read access attribute 116) and the new data structure of the cryptographic authorization (e.g., the first authorization information 118 and the second authorization information 122).

[0052] Support for reading and writing UEFI variables may be provided in an OS (e.g., WINDOWS, LINUX, etc.). The examples described herein allow the use of OS-provided APIs to restrict read access to a read-protected UEFI variable 112 without using proprietary and/or side-band schemes (e.g., the use of private Windows Management Instrumentation (WMI)). In some examples, the job of data encryption may be delegated to the BIOS so that individual application developers do not have to implement the details of encryption/decryption.

[0053] FIG. 2 is a block diagram illustrating another example of a computing device 202 that may be utilized for providing read protection for UEFI variables. The computing device 202 may be implemented in accordance with the computing device 102 described in FIG. 1. For example, the computing device 202 may include a processor 204 and memory 206 as described in FIG. 1. In some examples, the computing device 202 may store certain information (e.g., instructions executed in the operating system) in a first memory type (e.g., DRAM). The computing device 202 may store other information (e.g., variables) in a second memory type (e.g., NVRAM). Therefore, while a single memory 206 is depicted in FIG. 2, in some examples, the memory 206 may be implemented as different types of memory.

[0054] The computing device 202 may create a read-protected unified extensible firmware interface (UEFI) variable 212. In some examples, the memory 206 may include and/or store read-protected UEFI variable creation instructions 208. The read-protected UEFI variable creation instructions 208 may be instructions for creating a read-protected UEFI variable 212 based on restricted access data 218 included as part of a name 216 included in a command 214 to create the read-protected UEFI variable 212. For example, the processor 204 may execute the read-protected UEFI variable creation instructions 208 to create the read-protected UEFI variable 212 based on the restricted access data 218. [0055] In some examples, the restricted access data 218 may be passed in a command 214 to create the read-protected UEFI variable 212 as part of the name 216 of the read-protected UEFI variable 212. The restricted access data 218 may be used to control read access to the read-protected UEFI variable 212. In some examples, the restricted access data 218 may include a restricted access label 224 to indicate restricted read access to the read-protected UEFI variable 212 and a first secret 226 to protect read access.

[0056] In some examples, the restricted access data 218 may be appended to an intended name of the read-protected UEFI variable 212. For example, the restricted access data 218 may be extra text added after the intended name of the read-protected UEFI variable 212.

[0057] In an example, the command 214 may be a Set Variable call to an API (e.g., UEFI API, WINDOWS API, etc.). The BIOS may be implemented to recognize a name 216 with a certain format that includes the restricted access data 218. Listing 5 illustrates an example of a format for the name 216 of the read-protected UEFI variable 212.

Listing 5

[0058] In the example of Listing 5, the term “variableX” is the name of the read-protected UEFI variable 212. In other words, “variableX” may be the intended name of the read-protected UEFI variable 212. The term “PROTECTED” is a restricted access label 224 to indicate restricted read access to the read-protected UEFI variable 212. The restricted access label 224 may be an attribute that indicates that the read-protected UEFI variable 212 is to be created with read access protection. The label “PROTECTED” instructs the BIOS that the read-protected UEFI variable 212 named “variableX” is intended for read protection (e.g., using authorization). It should be noted that the restricted access label 224 may be implemented with other terms. Therefore, a term other than “PROTECTED” may be used as long as it is used consistently to store and then control read access at a later stage.

[0059] In Listing 5, the term “secret-key” may be a first secret 226 that is used to protect read access. In some examples, the first secret 226 may include a secret and/or password used to derive a key for encrypting the data of the read-protected UEFI variable 212. Therefore, in the example of Listing 5, the use of the “PROTECTED” label indicates to the BIOS that a variable named “variableX” is to be created and protected by the value identified as “secret-key.” [0060] In some examples, the restricted access data 218 may be passed to the BIOS in a call to create the read-protected UEFI variable 212. For example, the restricted access data 218 may be included in the name field (e.g., VariableName or IpName) of a Set Variable call. The BIOS may detect the restricted access label 224 in the name 216 included in the command 214. In the example of Listing 5, the BIOS may detect the sequence “-PROTECTED” as the restricted access label 224. In this case, the BIOS may save the read- protected UEFI variable 212 using the first secret 226 based on detecting the restricted access label 224. Therefore, the BIOS may restrict read access to the read-protected UEFI variable 212 in response to detecting the restricted access label 224 appended to the name 216 of the read-protected UEFI variable 212. [0061] In some examples, the memory 206 may include and/or store read access instructions 210. The read access instructions 210 may be instructions for providing read access to the read-protected UEFI variable 212 based on a second secret 228 included in a read request 220. For example, the processor 204 may execute the read access instructions 210 to provide read access to the read-protected UEFI variable 212 in response to a read request 220.

[0062] In some examples, the read request 220 may be a Get Variable call. In this case, the caller may include the second secret 228 as part of the name (e.g., VariableName or IpName) of the read-protected UEFI variable 212 in the Get Variable call. In some examples, the name 216 included in the read request 220 may be formatted according to Listing 5.

[0063] In some examples, the second secret 228 may include a secret and/or password used to derive a key for decrypting the data of the stored read- protected UEFI variable 212. For example, upon receiving the read request 220, the BIOS may validate the read request 220 based on the first secret 226 appended to the name 216 of read-protected UEFI variable 212 and the second secret 228 included in the read request 220. The BIOS may decrypt the read- protected UEFI variable 212 using the second secret 228 included in the read request 220. If the second secret 228 matches the first secret 226, then the BIOS may decrypt the read-protected UEFI variable 212 successfully and the value of the read-protected UEFI variable 212 may be passed (e.g., sent) to the caller. Flowever, if the second secret 228 does not match the first secret 226, then the BIOS decryption of the the read-protected UEFI variable 212 may fail, thus restricting read access to the caller.

[0064] In some examples, the first secret 226 (e.g., a secret, password, etc.) may be used to derive a key (e.g., using a Key Derivative Function (KDF)). In some examples, the derived key may be a symmetric key. In some examples, additional SALT information unique to the computing device 202 (e.g., a GUID, the motherboard serial number, a Trusted Platform Module (TPM) Endorsement Key (EK) public key, other unique information about the computing device 202, or a combination thereof) may be used to derive the key.

[0065] The BIOS may encrypt the read-protected UEFI variable using the first secret 226 in response to detecting the restricted access label 224 in the name 216 included in the command 214. For example, the data passed in the command 214 to create the read-protected UEFI variable 212 may be symmetrically encrypted using the derived key. The encrypted read-protected UEFI variable 212 may be stored in the BIOS (e.g., in NVRAM). The first secret 226 (e.g., password) and the derived key may then be deleted from memory 206 in response to encrypting the read-protected UEFI variable 212.

[0066] On subsequent read operations, the caller may pass the same secret (i.e., the second secret 228) to read the read-protected UEFI variable 212. In response to receiving the read request 220, the BIOS may attempt to derive the key using the same scheme described above. Upon deriving the key using the second secret 228, the BIOS may attempt to decrypt the data stored in the read- protected UEFI variable 212. If the data is successfully decrypted, the BIOS may return the data to the caller. If data is not decrypted correctly, an empty buffer may be returned for the value with an error code indicating that the caller does not have authorization to read the read-protected UEFI variable 212.

[0067] It should be noted that with this approach the stored data has confidentially protection. Therefore, even directly reading the flash contents of the memory 206 would not reveal the data of the read-protected UEFI variable 212 to unauthorized users.

[0068] In another example, the first secret 226 may be a password used to ensure that a caller with knowledge of the first secret 226 can read back the data of the read-protected UEFI variable 212. In this example, the BIOS may hash the password (e.g., the first secret 226) and store the associated hash in the read-protected UEFI variable 212. On subsequent read operations, the caller may pass the second secret 228 to the BIOS in the read request 220. The BIOS may first verify the second secret 228 by hashing the second secret 228 and may then match this hash with the stored secret hash. If the hashes match, then the BIOS may return the value of the read-protected UEFI variable 212 back to the caller. In the case that the second secret 228 does not match the first secret 226, the BIOS may return an empty data buffer with an error code that indicates that the caller does not have authorization to read the read- protected UEFI variable 212.

[0069] FIG. 3 is a block diagram illustrating an example of a computer- readable medium 330 for providing read protection for UEFI variables. The computer-readable medium 330 may be a non-transitory, tangible computer- readable medium 330. The computer-readable medium 330 may be, for example, RAM, EEPROM, a storage device, an optical disc, and the like. In some examples, the computer-readable medium 330 may be volatile and/or non-volatile memory, such as DRAM, EEPROM, MRAM, PCRAM, memristor, flash memory, and the like. In some examples, the computer-readable medium 330 described in FIG. 3 may be an example of memory 106 for a computing device 102 described in FIG. 1 or memory 206 for a computing device 202 described in FIG. 2. In some examples, code (e.g., data and/or executable code or instructions) of the computer-readable medium 330 may be transferred and/or loaded to memory or memories of the computing device 102 or computing device 202.

[0070] The computer-readable medium 330 may include code (e.g., data and/or executable code or instructions). For example, the computer-readable medium 330 may include read-protected UEFI variable creation instructions 332, and/or read access instructions 334.

[0071] In some examples, the read-protected UEFI variable creation instructions 332 may be instructions that when executed cause a processor of the computing device to send a command to create a read-protected UEFI variable based on an authenticated read access attribute and first authorization information included in the command. For example, the command may be sent from a calling application. In some examples, the command to create the read- protected UEFI variable may include a Set Variable call to an application programming interface (API). The Set Variable call may include the authenticated read access attribute and the first authorization information. In some examples, this may be accomplished as described in FIGS. 1-2.

[0072] In some examples, the read access instructions 334 may be instructions that when executed cause the processor of the computing device to send a read request that includes second authorization information to access to the read-protected UEFI variable. For example, the command may be sent from a calling application. In some examples, the read request may be a Get Variable call to an API to access the read-protected UEFI variable. The Get Variable call may include the second authorization information. In some examples, this may be accomplished as described in FIGS. 1-2.

[0073] FIG. 4 is a flow diagram illustrating an example of a method 400 for providing read protection for UEFI variables. The method 400 and/or an element or elements of the method 400 may be performed by a computing device. For example, an element or elements of the method 400 may be performed by the computing device 102 described in FIG. 1 , or the processor 104 described in FIG. 1 , any of which may be referred to generally as a “computing device” in FIG. 4. [0074] The computing device may create 402 a read-protected UEFI variable 112 based on an authenticated read access attribute 116 and first authorization information 118 included in a command 114 to create the read-protected UEFI variable 112. A BIOS of the computing device may restrict read access to the read-protected UEFI variable 112 based on the authenticated read access attribute 116 and the first authorization information 118. For example, the authenticated read access attribute 116 may indicate that authorization conditions are to be met before the read-protected UEFI variable 112 can be read. In other words, the authenticated read access attribute 116 may indicate that the read-protected UEFI variable 112 is to have restricted read access. These authorization conditions may include performing a validation of a read request 120 using the first authorization information 118.

[0075] In some examples, the first authorization information 118 may include a first authorization value (e.g., a public key to verify signatures or a secret to use for an FIMAC) used to authorize a read request 120. In some examples, the first authorization information 118 may include an anti-replay value to restrict read replays of a read request 120.

[0076] In some examples, the BIOS may save the read-protected UEFI variable 112 with the authenticated read access attribute 116 and the first authorization information 118 in memory. For example, the BIOS may store the read-protected UEFI variable 112 with the authenticated read access attribute 116 and the first authorization information 118 in NVRAM.

[0077] In some examples, the command 114 to create the read-protected UEFI variable 112 may include a Set Variable call to an API. The Set Variable call may include the authenticated read access attribute 116 and the first authorization information 118.

[0078] The computing device may provide 404 read access to the read- protected UEFI variable 112 based on second authorization information 122 included in a read request 120. For example, the BIOS may validate the read request 120 based on the saved first authorization information 118 and the second authorization information 122 included in the read request 120. [0079] In some examples, the read request 120 may include a Get Variable call to an API to access the read-protected UEFI variable 112. The Get Variable call may include the second authorization information 122.

[0080] FIG. 5 is a flow diagram illustrating another example of a method 500 for providing read protection for UEFI variables. The method 500 and/or an element or elements of the method 500 may be performed by a computing device. For example, an element or elements of the method 500 may be performed by the computing device 202 described in FIG. 2, or the processor 204 described in FIG. 2, any of which may be referred to generally as a “computing device” in FIG. 5.

[0081] The computing device may create 502 a read-protected UEFI variable 212 based on restricted access data 218 included as part of a name 216 included in a command 214 to create the read-protected UEFI variable 212. In some examples, the restricted access data 218 may include a restricted access label 224 to indicate restricted read access to the read-protected UEFI variable 212 and a first secret 226 to protect read access.

[0082] A BIOS of the computing device may restrict read access to the read- protected UEFI variable 112 in response to detecting the restricted access label 224 appended to the name 216 of the read-protected UEFI variable 212. For example, the BIOS may encrypt the read-protected UEFI variable 212 using the first secret 226 in response to detecting the restricted access label 224 in the name 216 included in the command 214. The BIOS may delete the first secret 226 from memory in response to encrypting the read-protected UEFI variable 212.

[0083] The computing device may provide 504 read access to the read- protected UEFI variable 212 based on a second secret 228 included in a read request 220. For example, the BIOS may validate the read request 220 based on the first secret 226 appended to the name 216 of read-protected UEFI variable 212 and the second secret 228 included in a read request 220. In some examples, the BIOS may decrypt the read-protected UEFI variable 212 using the second secret 228 included in the read request 220. [0084] As used herein, the term “and/or” may mean an item or items. For example, the phrase “A, B, and/or C” may mean any of: A (without B and C), B (without A and C), C (without A and B), A and B (but not C), B and C (but not A), A and C (but not B), or all of A, B, and C.

[0085] While various examples are described herein, the disclosure is not limited to the examples. Variations of the examples described herein may be within the scope of the disclosure. For example, operations, functions, aspects, or elements of the examples described herein may be omitted or combined.

Claims

1. A computing device, comprising: a memory; a processor in electronic communication with the memory, wherein the processor is to: create a read-protected unified extensible firmware interface (UEFI) variable based on an authenticated read access attribute and first authorization information included in a command to create the read-protected UEFI variable; and provide read access to the read-protected UEFI variable based on second authorization information included in a read request.

2. The computing device of claim 1 , further comprising a basic input/ouput system (BIOS), wherein the BIOS is to restrict read access to the read-protected UEFI variable based on the authenticated read access attribute and the first authorization information.

3. The computing device of claim 2, wherein the BIOS is to save the read- protected UEFI variable with the authenticated read access attribute and the first authorization information in memory.

4. The computing device of claim 3, wherein the BIOS is to validate the read request based on the saved first authorization information and the second authorization information included in the read request.

5. The computing device of claim 1 , wherein the authenticated read access attribute indicates that authorization conditions are to be met before the read- protected UEFI variable can be read.

6. The computing device of claim 1 , wherein the first authorization information comprises a first authorization value.

7. The computing device of claim 6, wherein the first authorization information further comprises an anti-replay value to restrict read replays.

8. A non-transitory tangible computer-readable medium comprising instructions when executed cause a processor of a computing device to: send a command to create a read-protected unified extensible firmware interface (UEFI) variable based on an authenticated read access attribute and first authorization information included in the command; and send a read request comprising second authorization information to access to the read-protected UEFI variable.

9. The computer-readable medium of claim 8, wherein the command to create the read-protected UEFI variable comprises a Set Variable call to an application programming interface (API), the Set Variable call including the authenticated read access attribute and the first authorization information.

10. The computer-readable medium of claim 8, wherein the read request comprises a Get Variable call to an API to access the read-protected UEFI variable, the Get Variable call including the second authorization information.

11. A computing device, comprising: a memory; a processor in electronic communication with the memory, wherein the processor is to: create a read-protected unified extensible firmware interface

(UEFI) variable based on restricted access data included as part of a name included in a command to create the read- protected UEFI variable, the restricted access data comprising a restricted access label to indicate restricted read access to the read-protected UEFI variable and a first secret to protect read access; and provide read access to the read-protected UEFI variable based on a second secret included in a read request.

12. The computing device of claim 11 , further comprising a basic input/ouput system (BIOS), wherein the BIOS is to restrict read access to the read-protected UEFI variable in response to detecting the restricted access label appended to the name of the read-protected UEFI variable.

13. The computing device of claim 12, wherein the BIOS is to validate the read request based on the first secret appended to the name of the read- protected UEFI variable and the second secret included in the read request.

14. The computing device of claim 11 , wherein the processor is to: encrypt the read-protected UEFI variable using the first secret in response to detecting the restricted access label in the name included in the command; and delete the first secret from memory in response to encrypting the read- protected UEFI variable.

15. The computing device of claim 14, wherein the processor is to decrypt the read-protected UEFI variable using the second secret included in the read request.