BOOT DRIVER VERIFICATION

• US 20140215196A1
• Filed: 01/25/2013
• Published: 07/31/2014
• Est. Priority Date: 01/25/2013
• Status: Active Grant

• Current Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Original Assignee: Hewlett-Packard Development Company, L.P. (HP Inc.)
• Inventors: BERLIN, Kimon
• Granted Patent: US 9,336,395 B2
• Time in Patent Office: Days
• US Class Current: 713/2
• CPC Class Codes: G06F 21/572 Secure firmware programming, e.g. of basic input output system [BIOS]
• CPC Class Codes: G06F 21/575 Secure boot

Abstract

An example system in accordance with the present disclosure includes a secure hash calculation engine to intercept and calculate a secure hash for a pre-boot driver before the pre-boot driver is executed, wherein the pre-boot driver is executed based on the computed secure hash being successfully verified, and wherein the pre-boot driver is not executed based on the computed secure hash not being successfully verified.

Claims

1. A system, comprising:

a secure hash calculation engine to intercept and calculate a secure hash for a pre-boot driver before the pre-boot driver is executed;

wherein the pre-boot driver is executed based on the computed secure hash being successfully verified; and

wherein the pre-boot driver is not executed based on the computed secure hash not being successfully verified.

2. The system of claim 1, further comprising a secure hash verification engine to compare the computed secure hash for the pre-boot driver to a locally stored secure hash for the pre-boot driver.

3. The system of claim 1, wherein the computed secure hash is sent to a remote server that contains a stored secure hash for the pre-boot driver and the remote server is to verify the computed secure hash by comparing the computed secure hash for the pre-boot driver to the stored secure hash for the pre-boot driver.

4. The system of claim 1, wherein the locally stored secure hash is a copy of the remotely stored secure hash.

5. The system of claim 1, wherein the locally stored secure hash is periodically updated.

6. The system of claim 1, where in the secure hash calculation engine also intercepts an image of an operating system (OS) kernel.

7. A method, comprising:

intercepting a pre-boot driver before the pre-boot driver is executed;

computing a secure hash for the pre-boot driver;

executing the pre-boot driver based on the computed secure hash being successfully verified; and

preventing the pre-boot driver from executing based on the computed secure hash not being successfully verified.

8. The method of claim 7, further comprising:

forwarding the computed secure hash to a remote server over the internet, wherein the remote server compares the calculated secure hash against a stored secure hash to verify the pre-boot driver; and

returning, by the remote server, the verification result.

9. The method of claim 7, further comprising:

comparing the computed secure hash to a stored secure hash for the pre-boot driver to verify the pre-boot driver.

10. The method of claim 7, further comprising downloading the stored secure hash from the remote server before comparing the computed secure hash value to a stored secure hash value for that pre-boot driver.

11. The method of claim 7, wherein an Operating System (OS) image is verified.

12. The method of claim 7, wherein images of an OS loader and an OS kernel are verified.

13. The method of claim 7, further comprising:

computing a secure hash for a sector of a mass storage device containing early OS code and data as the early OS code and data is loaded;

comparing the computed secure hash to a stored secure hash for that sector; and

halting the early OS load process based on the computed secure hash and the stored secure hash not being equal.

14. The method of claim 7, wherein the stored secure hash stored locally is periodically updated.

15. A non-transitory computer readable storage device (CRSD) storing code, that when executed, causes a processor to:

intercept a pre-boot driver before the driver is executed;

compute a hash value for the pre-boot driver;

execute the pre-boot driver based on a successful verification of the pre-boot driver; and

consult local security protocol based on an unsuccessful verification of the pre-boot driver;

wherein the security protocol contains rules for handling pre-boot drivers when the verification is unsuccessful.

16. The CRSD of claim 15, wherein the code causes the processor to:

compare the hash value to a stored hash value for that pre-boot driver to verify the pre-boot driver.

17. The CRSD of claim 15, wherein the code causes the processor to:

forward the computed hash value to a remote server over the internet to verify the hash value, wherein the remote server is to compare the hash value to a stored hash value and return the verification result to the processor.

18. The CRSD of claim 15, wherein the security protocol allows the pre-boot driver to execute even though the verification was unsuccessful.

19. The CRSD of claim 15, wherein the security protocol directs the processor to download a new version of the pre-boot driver and update the stored hash value associated with that pre-boot driver.

20. The CRSD of claim 15, wherein the security protocol does not allow the pre-boot driver to be executed when the verification is unsuccessful.