Information Handling Systems And Related Methods For Establishing Trust Between Boot Firmware And Applications Based On User Physical Presence Verification

• US 20190332392A1
• Filed: 04/30/2018
• Published: 10/31/2019
• Est. Priority Date: 04/30/2018
• Status: Active Grant

• Current Assignee: Dell Products LP (Dell Technologies Inc.)
• Original Assignee: Dell Products LP (Dell Technologies Inc.)
• Inventors: Pant, Alok, Martinez, Ricardo L.
• Granted Patent: US 10,853,086 B2
• Time in Patent Office: Days
• CPC Class Codes: G06F 21/31 User authentication
• CPC Class Codes: G06F 21/575 Secure boot
• CPC Class Codes: G06F 9/4406 Loading of operating system
• CPC Class Codes: H04L 9/3213 using tickets or tokens, e.g. Kerberos network architectures or network communication protocols for entities authentication using tickets in a packet data network H04L63/0807
• CPC Class Codes: H04L 9/3271 using challenge-response

Abstract

The present disclosure provides an information handling system (IHS) and related methods that use physical presence verification to establish unique trust relationships between boot firmware and one or more individual applications provided within an IHS. The IHS and methods disclosed herein provide secure verification of user physical presence by verifying the physical presence of a user during a pre-boot phase of the boot firmware (i.e., before an operating system (OS) is loaded and running). After user physical presence is verified during the pre-boot phase, the IHS and methods disclosed herein generate a physical presence (PP) bind token during OS runtime that may be used to establish a unique trust relationship between the boot firmware and one or more individual applications provided within the IHS.

Claims

1. An information handling system (IHS), comprising:

a computer readable storage medium storing an operating system (OS) and at least one application;

a computer readable memory storing boot firmware including boot services and runtime services;

at least one processing device coupled to the computer readable storage medium and to the computer readable memory, wherein the at least one processing device is configured to execute;

a first set of program instructions included within the boot services of the boot firmware to interact with a user of the IHS and receive user input via an input device of the IHS during a pre-boot phase of the boot firmware; and

a second set of program instructions included within the runtime services of the boot firmware to verify a physical presence of the user during OS runtime, wherein the verification of the physical presence of the user is based on at least a subset of the user input received during the pre-boot phase.

2. The information handling system as recited in claim 1, wherein the user input is selected from a group including:

a key press on a keyboard or a touch screen, a swipe across the touch screen, a click/scroll on a mouse, a string of one or more characters entered on the keyboard or the touch screen, and a challenge string entered on the keyboard or the touch screen, wherein the challenge string was previously displayed to the user and included within the application token provided to the boot firmware.

3. The information handling system as recited in claim 1, wherein the first set of program instructions are executed by the at least one processing device during the pre-boot phase to display a text command on a display screen of the IHS requesting the user to enter the user input via the input device of the IHS.

4. The information handling system as recited in claim 3, wherein the second set of program instructions executed by the at least one processing device during OS runtime is configured to verify the physical presence of the user if the user input received during the pre-boot phase matches user input requested in the text command.

5. The information handling system as recited in claim 1, wherein the at least one application includes a third set of program instructions, which is executed by the at least one processing device during OS runtime to:

generate an application token unique to that application; and

provide the application token to the boot firmware.

6. The information handling system as recited in claim 5, wherein the application token includes one or more of the following:

one or more keys associated with the at least one application;

a plain text or hash of a challenge string displayed to the user of the IHS;

a random number generated by the at least one application;

a random number generated by the boot firmware and forwarded to the at least one application; and

one or more access requests associated with the application.

7. The information handling system as recited in claim 5, wherein the runtime services of the boot firmware include a fourth set of program instructions, which is executed by the at least one processing device during OS runtime to generate a boot firmware token if the physical presence of the user is verified.

8. The information handling system as recited in claim 7, wherein the boot firmware token includes one or more of the following:

one or more keys associated with the boot firmware;

a random number generated by the boot firmware;

a random number generated by the at least one application; and

a status of permissions granted and/or denied for one or more access requests associated with the application.

9. The information handling system as recited in claim 7, wherein the at least one application includes a fifth set of program instructions, which is executed by the at least one processing device during OS runtime to:

receive the boot firmware token if the physical presence of the user is verified;

open a secure communication tunnel between the boot firmware and the at least one application;

generate a physical presence (PP) bind token including at least a subset of information included within the application token and the boot firmware token; and

provide the PP bind token to the boot firmware.

10. The information handling system as recited in claim 9, wherein the runtime services of the boot firmware include a sixth set of program instructions, which is executed by the at least one processing device during OS runtime to establish a trust relationship between the boot firmware and the at least one application using the PP bind token.

11. A method for generating a trust relationship between boot firmware and at least one application stored within an information handling system (IHS), the method comprising:

providing an application token unique to the at least one application to the boot firmware;

storing the application token;

subsequently rebooting the IHS to enter a pre-boot phase of the boot firmware, wherein during the pre-boot phase the method further comprises;

prompting the user to provide user input; and

receiving the user input via an input device of the IHS; and

verifying a physical presence of the user based on at least a subset of the user input received during the pre-boot phase.

12. The method as recited in claim 11, wherein prior to providing the application token, the method further comprises generating the application token, wherein the application token includes at least one application access request and a challenge string that was previously displayed to the user.

13. The method as recited in claim 12, wherein said verifying includes comparing the received user input to the challenge string included within the application token to verify the physical presence of the user.

14. The method as recited in claim 12, wherein said prompting the user to provide user input and said receiving user input via an input device of the IHS respectively comprise:

prompting the user to provide the challenge string that was previously displayed to the user and grant permission for the at least one application access request included within the application token; and

receive a user response to the challenge string and any permissions granted by the user.

15. The method as recited in claim 11, further comprising generating a boot firmware token if the physical presence of the user is verified.

16. The method as recited in claim 15, further comprising opening a secure communication tunnel between the boot firmware and the at least one application.

17. The method as recited in claim 15, further comprising generating a physical presence (PP) bind token including at least a subset of information included within the application token and the boot firmware token.

18. The method as recited in claim 17, further comprising establishing a trust relationship between the boot firmware and the at least one application using the PP bind token.

19. The method as recited in claim 17, wherein the PP bind token includes any permissions granted by the user.

20. The method as recited in claim 19, further comprising performing application accesses per the permissions included within the PP bind token.