WO2022019910A1 - Protection de lecture de variables d'uefi - Google Patents

Protection de lecture de variables d'uefi Download PDF

Info

Publication number
WO2022019910A1
WO2022019910A1 PCT/US2020/043207 US2020043207W WO2022019910A1 WO 2022019910 A1 WO2022019910 A1 WO 2022019910A1 US 2020043207 W US2020043207 W US 2020043207W WO 2022019910 A1 WO2022019910 A1 WO 2022019910A1
Authority
WO
WIPO (PCT)
Prior art keywords
read
protected
variable
uefi
computing device
Prior art date
Application number
PCT/US2020/043207
Other languages
English (en)
Inventor
Richard Alden BRAMLEY, Jr.
Valiuddin Ali
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2020/043207 priority Critical patent/WO2022019910A1/fr
Publication of WO2022019910A1 publication Critical patent/WO2022019910A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/575—Secure boot

Definitions

  • 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;
  • UEFI Unified Extensible Firmware Interface
  • FIG. 2 is a block diagram illustrating another example of a computing device that may be utilized for providing read protection for UEFI variables;
  • FIG. 3 is a block diagram illustrating an example of a computer- readable medium for providing read protection for UEFI variables;
  • FIG. 4 is a flow diagram illustrating an example of a method for providing read protection for UEFI variables.
  • FIG. 5 is a flow diagram illustrating another example of a method for providing read protection for UEFI variables.
  • 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.
  • the drawings provide examples in accordance with the description; however, the description is not limited to the examples provided in the drawings.
  • a computing device may be a device that includes electronic circuitry.
  • 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.
  • a computing device may include a Basic Input/Output System (BIOS).
  • BIOS 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.
  • OS operating system
  • Instructions included within a BIOS may be software, firmware, microcode, or other programming that defines or controls functionality or operation of a BIOS.
  • 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.
  • 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.
  • 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.
  • a BIOS may implement the Unified Extensible Firmware Interface (UEFI) specification or another specification or standard for initializing, controlling, or operating a computing device.
  • UEFI Unified Extensible Firmware Interface
  • 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.
  • 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.
  • UEFI Unified Extensible Firmware Interface
  • applications are referred to as applications.
  • the UEFI specification describes a standardized mechanism to read and write variables that can persist across boots of a computing device.
  • 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.
  • API application programming interface
  • 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.
  • the UEFI variables may be protected by a key such that writes made using the key will succeed.
  • the write protection is not bound to a particular entity, but the value being written is itself authorized.
  • 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.
  • the creator e.g., an entity with control of the key
  • OS 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the computing device 102 may include different types of memory 106.
  • 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.
  • 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.
  • 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.
  • 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.
  • the computing device 102 may create a read-protected unified extensible firmware interface (UEFI) variable 112.
  • 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.
  • 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.
  • the processor 104 may implement a BIOS.
  • 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.
  • the command 114 may be sent to the BIOS as an API call.
  • 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.
  • the caller e.g., application, process, service, kernel driver, etc.
  • the caller 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.
  • GUID Globally Unique Identifier
  • 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.
  • 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.
  • the attribute VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS may be included in the Attributes field as a bitmask value (e.g., 0x00000010).
  • 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.
  • the attribute in WINDOWS that supports writing an authenticated variable is VARIABLE_ATTRIBUTE_AUTHENTICATED_WRITE_ACCESS as described above.
  • 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.
  • 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).
  • bitmask value e.g., 0x00000010
  • VARIABLE_ATTRIBUTE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS may be included in the dwAttributes field as a bitmask value (e.g., 0x00000020).
  • bitmask value e.g. 0x00000020.
  • 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.
  • 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.
  • an OS e.g., WINDOWS, LINUX, UNIX, etc.
  • the UEFI specification may include certain authenticated variables that are not supported by other operating systems.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a read-protected UEFI variable 112 e.g., an authenticated variable
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • the data field of the command 114 may include first authorization information 118.
  • 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.
  • 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.
  • the first authorization information 118 may include information used to control read access to the read-protected UEFI variable 112.
  • 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.
  • 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.
  • the first authorization information 118 may include an anti-replay value (e.g., a 64 bit value) to restrict read replays.
  • 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.
  • 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).
  • NVRAM non-volatile random-access memory
  • 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.
  • 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.
  • the read request 120 may be a Get Variable call to an API to access the read-protected UEFI variable 112.
  • the read request 120 may be a GetVariable() call.
  • the read request 120 may be a GetFirmwareEnvironmentVariableExAO call.
  • the Get Variable call may include the second authorization information 122.
  • 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.
  • 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).
  • a second authorization value e.g., a signature or FIMAC
  • the second authorization information 122 may also include an anti-replay counter (e.g., a 64-bit anti-replay counter).
  • 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.
  • the second authorization information 122 e.g., the authorization value, anti-replay counter, etc.
  • the Attributes parameter of the GetVariableO call may be included in the case of the WINDOWS API.
  • the second authorization information 122 e.g., the authorization value, anti-replay counter, etc.
  • the second authorization information 122 may be included in a buffer pointed to by the pdwAttributes parameter of the GetVariableQ call.
  • 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.
  • 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 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.
  • 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.
  • 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).
  • Support for reading and writing UEFI variables may be provided in an OS (e.g., WINDOWS, LINUX, etc.).
  • 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)).
  • WMI Windows Management Instrumentation
  • 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.
  • 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.
  • the computing device 202 may include a processor 204 and memory 206 as described in FIG. 1.
  • 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.
  • the computing device 202 may create a read-protected unified extensible firmware interface (UEFI) variable 212.
  • 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.
  • 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.
  • 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.
  • 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.
  • the restricted access data 218 may be appended to an intended name of the read-protected UEFI variable 212.
  • the restricted access data 218 may be extra text added after the intended name of the read-protected UEFI variable 212.
  • 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.
  • variableX is the name of the read-protected UEFI variable 212.
  • variantX may be the intended name of the read-protected UEFI variable 212.
  • 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.
  • the term “secret-key” may be a first secret 226 that is used to protect read access.
  • 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.”
  • the restricted access data 218 may be passed to the BIOS in a call to create the read-protected UEFI variable 212.
  • 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.
  • the BIOS may detect the sequence “-PROTECTED” as the restricted access label 224.
  • 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.
  • 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.
  • 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.
  • the read request 220 may be a Get Variable call.
  • 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.
  • the name 216 included in the read request 220 may be formatted according to Listing 5.
  • 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.
  • 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.
  • 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.
  • the first secret 226 may be used to derive a key (e.g., using a Key Derivative Function (KDF)).
  • KDF Key Derivative Function
  • the derived key may be a symmetric key.
  • 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
  • TPM Trusted Platform Module
  • EK Endorsement Key
  • 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.
  • 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
  • the derived key may then be deleted from memory 206 in response to encrypting the read-protected UEFI variable 212.
  • the caller may pass the same secret (i.e., the second secret 228) to read the read-protected UEFI variable 212.
  • the BIOS may attempt to derive the key using the same scheme described above.
  • 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.
  • 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.
  • the BIOS may hash the password (e.g., the first secret 226) and store the associated hash in the read-protected UEFI variable 212.
  • 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.
  • 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.
  • 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.
  • 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.
  • the computer-readable medium 330 described in FIG. 3 may be an example of memory 106 for a computing device 102 described in FIG.
  • code e.g., data and/or executable code or instructions
  • code 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.
  • the computer-readable medium 330 may include code (e.g., data and/or executable code or instructions).
  • the computer-readable medium 330 may include read-protected UEFI variable creation instructions 332, and/or read access instructions 334.
  • 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.
  • the command may be sent from a calling application.
  • the command to create the read- protected UEFI variable may include a Set Variable call to an application programming interface (API).
  • API application programming interface
  • 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.
  • 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.
  • the command may be sent from a calling application.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a first authorization value e.g., a public key to verify signatures or a secret to use for an FIMAC
  • the first authorization information 118 may include an anti-replay value to restrict read replays of a read request 120.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the BIOS may decrypt the read-protected UEFI variable 212 using the second secret 228 included in the read request 220.
  • the term “and/or” may mean an item or items.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

L'invention divulgue des exemples de dispositifs informatiques. Selon certains exemples, un dispositif informatique comprend une mémoire et un processeur en communication électronique avec la mémoire. Selon certains autres exemples, le processeur est destiné à créer une variable d'interface de micrologiciel extensible unifiée (UEFI) protégée en lecture sur la base d'un attribut d'accès de lecture authentifié et de premières informations d'autorisation comprises dans un ordre pour créer la variable d'UEFI protégée en lecture. Selon encore certains autres exemples, le processeur est destiné à fournir un accès de lecture à la variable d'UEFI protégée en lecture sur la base de secondes informations d'autorisation comprises dans une demande de lecture.
PCT/US2020/043207 2020-07-23 2020-07-23 Protection de lecture de variables d'uefi WO2022019910A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2020/043207 WO2022019910A1 (fr) 2020-07-23 2020-07-23 Protection de lecture de variables d'uefi

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2020/043207 WO2022019910A1 (fr) 2020-07-23 2020-07-23 Protection de lecture de variables d'uefi

Publications (1)

Publication Number Publication Date
WO2022019910A1 true WO2022019910A1 (fr) 2022-01-27

Family

ID=79729788

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/043207 WO2022019910A1 (fr) 2020-07-23 2020-07-23 Protection de lecture de variables d'uefi

Country Status (1)

Country Link
WO (1) WO2022019910A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11416615B2 (en) * 2020-09-02 2022-08-16 Dell Products, L.P. Configuring trusted remote management communications using UEFI

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140281577A1 (en) * 2013-03-15 2014-09-18 Insyde Software Corp. System and method for managing and diagnosing a computing device equipped with unified extensible firmware interface (uefi)-compliant firmware
WO2014168868A1 (fr) * 2013-04-08 2014-10-16 Insyde Software Corp. Détection d'altération de variable sécurisée dans un dispositif informatique équipé d'un micrologiciel compatible uefi
WO2015200581A1 (fr) * 2014-06-27 2015-12-30 Intel Corporation Gestion de variables authentifiées

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140281577A1 (en) * 2013-03-15 2014-09-18 Insyde Software Corp. System and method for managing and diagnosing a computing device equipped with unified extensible firmware interface (uefi)-compliant firmware
WO2014168868A1 (fr) * 2013-04-08 2014-10-16 Insyde Software Corp. Détection d'altération de variable sécurisée dans un dispositif informatique équipé d'un micrologiciel compatible uefi
WO2015200581A1 (fr) * 2014-06-27 2015-12-30 Intel Corporation Gestion de variables authentifiées
US20150379306A1 (en) * 2014-06-27 2015-12-31 Vincent J. Zimmer Management of Authenticated Variables

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11416615B2 (en) * 2020-09-02 2022-08-16 Dell Products, L.P. Configuring trusted remote management communications using UEFI

Similar Documents

Publication Publication Date Title
US10949550B2 (en) Secure processing systems and methods
CN109416720B (zh) 跨重置维护操作系统秘密
AU2012337403B2 (en) Cryptographic system and methodology for securing software cryptography
EP3326105B1 (fr) Technologies de programmation sécurisée d'un moteur cryptographique pour une e/s sécurisée
TWI598814B (zh) 用於管理及診斷配備有統一可延伸韌體介面（ｕｅｆｉ）相容韌體的計算裝置之系統與方法
US8572410B1 (en) Virtualized protected storage
JP4971466B2 (ja) コンピューティング・デバイスの安全なブート
KR101190479B1 (ko) 티켓 인증 보안 설치 및 부트
US10943013B2 (en) Maintaining keys for trusted boot code
KR102030858B1 (ko) 디지털 서명 권한자 의존형 플랫폼 기밀 생성 기법
US20190026471A1 (en) Rollback resistant security
JP2005527019A (ja) マルチトークンのシール及びシール解除
US20080168545A1 (en) Method for Performing Domain Logons to a Secure Computer Network
JP2010510574A (ja) セキュアデバイス・システムにおけるフラッシュメモリ・ブロックの保護と方法
US20030061494A1 (en) Method and system for protecting data on a pc platform using bulk non-volatile storage
KR20090073208A (ko) 영구 보안 시스템 및 영구 보안 방법
CN114402295A (zh) 安全运行时系统和方法
US8972745B2 (en) Secure data handling in a computer system
WO2022019910A1 (fr) Protection de lecture de variables d'uefi
CN108595981B (zh) 加密安卓系统的方法
CN111357003A (zh) 预操作系统环境中的数据保护
US11960737B2 (en) Self-deploying encrypted hard disk, deployment method thereof, self-deploying encrypted hard disk system and boot method thereof
US20210409196A1 (en) Secure Key Storage Systems Methods And Devices
Angelakis Application development in the trusted execution environment
CN115292727A (zh) 基于TrustZone的根文件系统加密方法及装置、设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20945748

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20945748

Country of ref document: EP

Kind code of ref document: A1