WO2022093254A1

WO2022093254A1 - Hashed function point identifiers for data processing security

Info

Publication number: WO2022093254A1
Application number: PCT/US2020/058098
Authority: WO
Inventors: Tsue-Yi HUANG; Chia-Cheng Lin; Shao-Yu CHIANG; Ming-Chang HUNG
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-10-30
Filing date: 2020-10-30
Publication date: 2022-05-05

Abstract

Methods, systems, devices, and corresponding logical structures for improved security in data processing systems. Methods in accordance with the disclosure enable the installation or storage of hashed function point identifiers, for comparison with hashes of identifiers received with function requests. In cases in which prior hashed function point identifiers do not satisfactorily correspond to hashes made at the time of a function request, incorrect function point identifiers can be replaced with known appropriate identifiers.

Description

HASHED FUNCTION POINT IDENTIFIERS FOR DATA PROCESSING SECURITY BACKGROUND [0001] During boot or launch cycles, computers and other data processors very commonly perform basic component and system set-ups, including for example confirming or assigning identifiers useful in routing requests to resources such as programs, applications, and peripheral devices. In many cases, such processes are performed by firmware adapted to initialize protocols, pointers, and drivers. BRIEF DESCRIPTION OF THE DRAWINGS [0002] Various aspects and examples of the disclosure are illustrated in the accompanying drawings, which are meant to be exemplary and not limiting, and in which like references are intended to refer to like or corresponding parts. [0003] Fig.1 is a schematic diagram showing examples of possible functional relationships between components of a data processing system in accordance with various aspects and examples of the disclosure. [0004] Fig.2 is a schematic diagram showing an example of a protocol interface structure suitable for implementing aspects of the disclosure. [0005] Figs.3 through 5 are schematic diagrams showing examples of functional relationships and process flows during data communications in processes for implementing aspects of the disclosure. DETAILED DESCRIPTION [0006] The disclosure relates to security processes for protecting computers and computer users from malicious redirection intended to divert function calls from the resources for which they are intended to harmful or otherwise undesired substitute functions. [0007] Security remains a critical consideration for those involved in data processing, and including particularly for those who look to multi-function computers and/or networked resources for information and operability. Computers and other data processors remain vulnerable at many points of operation, including for example at the point of system boot or launch. [0008] Hackers and other parties often deliberately or inadvertently attempt to re-direct or mis-direct computer communications, so that requests for processing are received and processed by resources other than those intended by their creators. Even UEFI, BIOS, and other firmware boot or launch components are subject to accidental or malicious redirection attempts, through substitution of pointers and other protocol components. The improper direction of processing requests can result in a very wide variety of harmful consequences, including theft, fraud, loss of privacy, and waste of computing and business resources. [0009] The disclosure herein pertains to systems, methods, and computer readable media for secure operation of data processing systems. Firmware controllers, operating systems, and other control systems and devices of such data processing systems can be adapted to hash and store some or all of either or both of function protocols and function point identifiers associated with the protocols, and on receipt of a call to the function point, hash some or all of the data provided with the call request, compare the newly-hashed information with the stored hash, and at least partly on the basis of the comparison determine whether to authorize the call request. Use of previously and securely-stored pointers and protocol data to check data received with new processing requests can prevent deliberate and/or inadvertent misdirection of such processing requests. [0010] Various aspects of the disclosure are suitable for implementation in any of a very wide examples, and are applicable to a very wide variety of data processing systems and devices, including a variety of firmware, software, and other machine- readable instructions or computer devices and systems. For example, in various aspects and examples, the disclosure is suitable for implementation on firmware interfaces such as the Unified Extensible Firmware Interface (UEFI) used to control launch or boot functions on a wide variety of computing devices through the use of various protocols adapted to facilitate communications and other operations between operating systems, component drivers, and other devices. For example, UEFI and other firmware interfaces can be adapted to enable system or component drivers to install and/or otherwise access their own protocols. [0011] An example of a data processing system 100 suitable for use in implementing various aspects of the disclosure is shown schematically in Fig.1. In the example shown, a data processing system 100 such as a computer includes a firmware interface 101 such as a UEFI configured, among other things, to control system boot or launch processes; a central processor / operating system device 102, a plurality of device or function drivers 110a,b,c, referred to collectively as devices or drivers 110; and internal and or network communications system(s) 115, which can serve as a communications interface between any or all of local and/or wide-area networked devices, such as locally-networked computers and/or public network resources; local peripheral devices such as printers, display screens, keyboards, and/or other input/output devices, and local processors such as location or navigation devices, biometric security devices, etc. In addition, system(s) 100 can include any desired numbers of secure or open-access memory devices 108. [0012] As used herein, basic input/output system (BIOS) and Unified Extensible Firmware Interface (UEFI) refer to specifications defining standards for software interfaces between operating systems 102 and platform firmware 101. Such interfaces can comprise hardware or hardware and instructions to initialize, control, or operate computing devices 100 prior to execution of an operating system (OS) of the computing device. Instructions executed by BIOS or UEFI interfaces may be provided in the form of software, firmware, microcode, or other programming that defines or controls the interface functionality or operation. In some examples, BIOS and/or UEFI interfaces may be implemented using instructions, such as platform firmware of a computing device 100, executable by a processor. A BIOS or UEFI interface may operate or execute prior to the execution of the OS of a computing device. A BIOS or UEFI interface may initialize, control, or operate components such as hardware components 101, 102, 110, 115 of a computing device 100 and may load or boot the OS 102 of such a computing device. [0013] In some examples, a BIOS or UEFI interface may provide or establish an interface between hardware devices 100 or platform firmware 101 of the computing device 100 and an OS 102 of the computing device, via which the OS of the computing device may control or operate hardware devices 110, 115 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. [0014] In various aspects and examples, either or both of controllers 101, 102 can be provided in any forms suitable for use in implementing the systems, devices, and process disclosed or suggested herein. In some examples, controller 101 can be provided in the form of either or both of firmware and hardware boot devices, adapted to initialize a system 100 by setting up and configuring an operating system operated under the control of a central processing unit 101. As will be appreciated by those skilled in the relevant arts, components 101, 102, including boot devices, centralized processors or controllers, and operating systems can be provided in a very wide variety of forms and combinations of hardware, firmware, and/or software. [0015] A function protocol, as used herein, refers to an logical structures, including software, firmware, and/or hardware, used to control communications between devices in a data processing system 100, including for example between a central processing unit 102 and any or all of memory(ies) 108, drivers 110, and communications systems 115. [0016] At boot or launch time and/or at other times, such as at the time of installation of new programs or devices, either or both of controllers 101, 102 be provided, for example by input devices such as local or network communications systems, peripheral systems including local drives, with pointers and identifiers useful for routing communications to various functions, such as applications, routines, and/or other programs, device drivers, etc., as well as protocols for communicating with such functions. [0017] An example of a protocol interface structure 200 used by a system such as the example shown in Fig.1 is provided in Fig.2. It can be seen that a function protocol can be configured as an interface structure with many data and/or function points 204 in the form of stored resource locators or addresses, in addition to header(s) 202 and delimiters 206 suitable for enabling controllers 101, 102, etc., to parse any or all portions of the protocol data set and properly interpret it, and to distinguish it from other data strings or records. [0018] Firmware and other drivers intended for interpretation, installation, and other operations relating to protocols, including function protocols 200, and portions thereof can be configured for reception, acquisition and/or installation of protocol interfaces in accordance with procedures such as those shown in Fig.2. [0019] For example, as shown at 300 in Fig.3, in order to install a function protocol for execution, a firmware controller 101 can execute a process 300. Upon acquiring or receiving a protocol and function point identifier from a memory, e.g., secure data store 108 and/or other source, for example, at 302 the controller 101 can initiate a Secure_InstallProtocol() process by hashing or otherwise encrypting the function point identifier. At 304, the controller 101 can store both the encrypted function point identifier 322a,b,c,…l referred to collectively as encrypted function point identifiers 322 and/or hashed function points 322, and the associated encryption data (e.g. hash data or key) 320 in a secure data store 108 communicatively linked to the controller 101. For example, any or all of the foregoing data types may be included among data stored in the form of a virtual resource register or other logical data structure 108’ in memory(ies) 108 accessible by either or both of controllers 101, 102; and at 306 the firmware controller 101 can install the protocol, for example by invoking suitable UEFI function handler services to appropriately configure some or all of memory 108, operating system 102, and driver(s) 110a,b,c, and can store a corresponding protocol global unique identifier (GUID), which can, for example correspond to or include a function protocol interface 318 in suitably secure storage 108. [0020] Function points and function point identifiers, as used herein, include system communications points and resources identifiable as destinations of data processing requests, and associated machine-interpretable identifiers. Memory, as used herein, includes any persistent, non-volatile, transient, or volatile device suitable for temporarily or indefinitely storing data representing signals or information useful for the purposes disclosed and suggested herein, and can include, for example, read-only memories, random access memories, optical drives, flash drives, buffers, etc. [0021] Upon receipt of a call for function services involving the protocol installed at 300, at 352 the same or another firmware controller 101 can execute a Secure_LocateProtocol () process 350 by retrieving a corresponding function protocol interface 318 from the same or another data store 108. At 354 the controller 101 can hash or otherwise encrypt according to a similar algorithm a function point identifier received or otherwise associated with the protocol interface, and at 356 can retrieve the corresponding hashed function point 322, stored at the time of installation, from secure data store 108 for example by using a corresponding UEFI or other protocol handler service. At 358, the firmware controller can compare the function point hashes generated at 304 and 354. If the hashes are equal, or otherwise satisfy a previously established satisfaction criterion, at 364 the controller 101 can retrieve the requested protocol interface 318 and/or other data, and route it to the requested service, and/or can otherwise authorize the requested access and/or processes. [0022] If at 358 the hashes are not equal, or otherwise suitably equivalent, at 360 the controller 101 can retrieve the previously stored, requested protocol interface 318 and/or other data from the data store 108, as for example by retrieving the protocol interface 318, and at 362 can override the function point requested, and at 364 return the requested protocol interface. [0023] Among the advantages offered by various aspects of the disclosure is the ability to prevent at least some form of malicious or otherwise unintended forms of resource redirection, at least for reasons shown by reference to Figs.4 and 5. [0024] Fig.4 is a schematic representation of processing in accordance with a process 350 of Fig.3 in which no malicious or unintended redirection of functions or resources has occurred, i.e., in which equivalency of the hashes generated at 304 and 354 has been sufficiently established in respect of function calls A and B received from each of drivers 110b,c, and d, such that each driver is provided the proper, intended pointer and protocol information, so that in each case a process 352-354-356-358-364 can be executed by the firmware controller 101. In the example shown, for example, a driver A installs a protocol relating to at least Functions A and B, in accordance with a process 300 described above; subsequently, on receipt of a new processing request comprising a call for either or both of Functions A and B; a driver B can retrieves the previously stored function A, B, process 350 hashes some or all of function point and/or other data received with the new request, and compares it with stored hash data. Upon determining that a sufficient equivalency exists between the new and previously-stored hashes, e.g., that the two are equal, controller 101, 102 can provide or otherwise authorize access to the function interface as described. [0025] In the example shown in Fig.5, a driver 999 has maliciously, unintentionally, or otherwise obtained access to the system 100, and at 598 has introduced a spurious function point identifier in place of a Function B pointer 504 of a Protocol A. In absence of processes 300, 350 in accordance with the disclosure, introduction of the spurious function point identifier can cause a function call from Driver D for Function B to result in redirection to a malicious or otherwise spurious function 599, which might be a malicious software routine on the device 100, or a remote network resource accessed through communications system 150, etc., rather than Function B 502. In other words, Driver D “thinks” that it is using a pointer associated with “Function A” and “Function B”, but actually the pointer is adapted to route communications to “Function A” and “Malicious Function” 599 after locating Protocol A. [0026] When firmware controller 101 is configured to execute processes 300, 350 in processing calls for Function A and Function B, receipt of Driver D’s call intended for function B, which includes or refers to a pointer associated with the malicious or otherwise spurious function 599, can result in hashing of the spurious function identifier 598 at 354 and can result in a determination at 358 that the proper function point identifier for Function B does not match the spurious function pointer 599, with the result that the controller 101 can retrieve the proper function point identifier 322 from memory 108 and use it in overriding the malicious function point identifier 599, so that at 364 the proper function and protocol associated with Function B can be returned, and the malicious or accidental process introduced by driver 999 can be overridden. [0027] Thus it may be seen that, for example, the disclosure provides a mechanism to solve vulnerability problems in UEFI BIOS and/or other firmware controllers 101, applicable not only to UEFI standard protocols, but also OEM feature protocols by storing hashed function point identifiers and comparing hashed values to new values created by hashing identifiers included as part of new driver access requests. [0028] For example, in various aspects and examples, the disclosure provides methods for improving the security and data integrity of data processing systems 100. Such a method can be performed by a platform or other firmware controller 101 comprising one or more logic circuits adapted to execute machine-readable instructions stored in the form of data representing coded electronic signals in memory 108 accessible by the controller 101. The method can comprise, with respect to a firmware interface function protocol associated with at least one function point identifier, at 304 hashing the at least one function point identifier to generate a first hashed function point identifier and storing the firmware interface function protocol and the first hashed function point identifier in secure memory 108 accessible by the platform firmware controller. Upon receiving at 352 data representing a system request to access a firmware interface associated with the at least one function point identifier, the system request comprising data representing the same or another function point, the controller 101 can hash the at least one received function point identifier to generate a second hashed function point identifier, at 356 can retrieve the first hashed function point identifier from memory 108 and at 358 compare the first and second hashed function point identifiers. Conditioned upon comparison of the first and second hashed function point identifiers meeting a satisfaction criterion, at 364 the processor 101 can authorize the system request, as described above with regard to Fig.4. If the satisfaction criterion is not met, at 360 the controller 101 can deny the system request, and optionally override it at 360, 362. [0029] As previously noted, firmware controller(s) 101 can be of any type consistent with the purposes and procedures disclosed herein. They can, for example include one or more of any of UEFI and/or Basic Input/Output System (BIOS)-compliant devices. Moreover, in various examples, operating system controller(s) 102 can provide functionality described in connection with controllers 101 herein, including, for example, processes 300 and 350, alone or in combination with firmware controllers 101. [0030] Optionally, or in addition, in various aspects and examples, the disclosure enables processor(s) 101, in denying the system request when the satisfaction criterion is not satisfied at 358, at 360, 362 to substitute a proper function point identifier and/or protocol interface associated with the system request to access a firmware interface, and return the desired protocol interface at 364. [0031] In further aspects and examples, the disclosure provides firmware controllers 101 in accordance with the foregoing, including controllers or processors comprising logic circuits adapted to execute machine-interpretable or readable instructions to cause the controllers 101 to execute processes 300, 350 as described above, and corresponding persistent, computer-executable logic structures, in the form of hardware, firmware, or stored software configured to cause a controller 101 of a data processor to 100 execute such processes. [0032] Although the present disclosure has been described with reference to example examples, those skilled in the relevant arts will recognize that many variations and modifications may be made without departing from the spirit and scope of the claimed subject matter. For example, although different example examples may have been described as including features providing various benefits, it is contemplated that the described features may be interchanged or combined with one another in various examples. Except to the extent necessary or inherent in the processes themselves, no particular order to steps or stages of methods or processes described in this disclosure, including the Figures, is intended or implied.

Claims

CLAIMS Claims: 1. A method for securing a data processing system, the method performed by a platform firmware controller comprising one or more logic circuits adapted to execute machine-readable instructions stored in the form of data representing coded electronic signals in memory accessible by the controller, the method comprising: with respect to a firmware interface function protocol associated with at least one function point identifier, hashing the at least one function point identifier to generate a first hashed function point identifier; storing the firmware interface function protocol and the first hashed function point identifier in secure memory accessible by the platform firmware controller; receiving data representing a system request to access a firmware interface associated with the at least one function point identifier, the system request comprising data representing the same or another function point; hashing the at least one received function point identifier to generate a second hashed function point identifier; comparing the first and second hashed function point identifiers; and conditioned upon comparison of the first and second hashed function point identifiers meeting a satisfaction criterion, authorizing the system request; else, denying the system request.

2. The method of claim 1, wherein the platform firmware is compatible with the Unified Extensible Firmware Interface (UEFI) standard.

3. The method of claim 1, wherein the platform firmware is compatible with a Basic Input/Output System (BIOS) standard.

4. The method of claim 1, comprising, in addition to denying the system request when the satisfaction criterion is not satisfied, returning to the source of the request to access the firmware interface associated with the at least one function point identifier a protocol interface associated with the first hashed function point identifier.

5. The method of claim 1, wherein the function point identifier associated with the second hashed function point identifier is associated with a networked data processing resource.

6. The method of claim 1, wherein the function point identifier associated with the second hashed function point identifier is associated with a local data processing resource.

7. A firmware controller for a data processing system, the controller comprising a logic circuit adapted to execute machine-readable instructions to: with respect to a firmware interface function protocol associated with at least one function point identifier, encrypt the at least one function point identifier to generate a first encrypted function point identifier; store the firmware interface function protocol and the first encrypted function point identifier in secure memory accessible by the platform firmware controller; receive data representing a system request to access a firmware interface associated with the at least one function point identifier, the system request comprising data representing the same or another function point; encrypt the at least one received function point identifier in accordance with an equivalent encryption scheme to generate a second encrypted function point identifier; compare the first and second encrypted function point identifiers; and conditioned upon comparison of the first and second hashed function point identifiers meeting a satisfaction criterion, authorize the system request; else, deny the system request.

8. The controller of claim 7, wherein the firmware controller is compatible with the Unified Extensible Firmware Interface (UEFI) standard.

9. The controller of claim 7, wherein the firmware controller is compatible with a Basic Input/Output System (BIOS) standard.

10. The controller of claim 7, configured to, in addition to denying the system request when the satisfaction criterion is not satisfied, return to the source of the request to access the firmware interface associated with the at least one function point identifier a protocol interface associated with the first hashed function point identifier.

11. The controller of claim 7, wherein the function point identifier associated with the second hashed function point identifier is associated with a networked data processing resource.

12. The controller of claim 7, wherein the function point identifier associated with the second hashed function point identifier is associated with a local data processing resource.

13. A non-transitory computer-readable medium comprising instructions that, when executed by a processor, cause the processor to: with respect to a firmware interface function protocol associated with at least one function point identifier, hash the at least a portion of data associated with the function protocol and the at least one function point identifier to generate a first hashed function point data set; store the firmware interface function protocol and the first hashed function point data set in secure memory accessible by the platform firmware controller; receive data representing a system request to access a firmware interface associated with the at least one function point identifier, the system request comprising data representing the same or another function point; hash at least a portion of data associated with the function protocol and the at least one function point identifier to generate a second hashed function point identifier; compare the first and second hashed function point identifiers; and conditioned upon comparison of the first and second hashed function point identifiers meeting a satisfaction criterion, authorize the system request; else, deny the system request.

14. The computer-readable medium of claim 13, configured to, in addition to denying the system request when the satisfaction criterion is not satisfied, cause the controller to return to the source of the request to access the firmware interface associated with the at least one function point identifier a protocol interface associated with the first hashed function point identifier.

15. The computer-readable medium of claim 13, wherein the function point identifier associated with the second hashed function point identifier is associated with a networked data processing resource.