Trusted security zone enhanced with trusted hardware drivers

Patent metadata

Field	Value
Publication number	US-9613208-B1
Application number	US-201313802404-A
Country	US
Kind code	B1
Filing date	Mar 13, 2013
Priority date	Mar 13, 2013
Publication date	Apr 4, 2017
Grant date	Apr 4, 2017

Abstract

An electronic device comprises a processor, a permissive sector, a trusted security zone that is separate from the permissive sector, a hardware driver, a first trusted application, stored in the trusted security zone, that is configured to invoke the hardware driver in response to activation instructions, and a second trusted application, stored in the trusted security zone, that when executed on the processor, configures the processor to: amass information about an uncompromised state of the hardware driver, store the information about the uncompromised state of the hardware driver in the trusted security zone, and compare, in response to receipt of activation instructions by the first trusted application, the information about the uncompromised state of the hardware driver with a current state of the hardware driver, and perform an action in response to a result of the comparison.

First claim

What is claimed is:

1. An electronic device, comprising:
at least one processor that includes:
a normal partition of the at least one processor that is associated with a permissive sector, and
a secure partition of the at least one processor that is associated with a trusted security zone, the trusted security zone providing a hardware root of trust and an operating system for the secure partition that runs separate from a normal partition operating system, wherein the trusted security zone ceases execution of non-trusted applications in the permissive sector during execution of at least one trusted application in the secure partition;
a non-transitory memory that includes:
a normal partition of the non-transitory memory that is associated with the permissive sector, the permissive sector allowing non-trusted applications to invoke hardware drivers stored in the normal partition, and
a secure partition of the non-transitory memory that is associated with the trusted security zone and comprises a trusted version of a hardware driver that provides information about an uncompromised state associated with the hardware driver, wherein the trusted security zone is separate from the permissive sector;
the hardware driver associated with a version that is stored in the non-transitory memory and comprises a current state, wherein the hardware driver is at least initially stored in the normal partition of the non-transitory memory;
a first trusted application, stored in the secure partition of the non-transitory memory associated with the trusted security zone, configured to invoke the hardware driver in response to activation instructions; and
a second trusted application, stored in the secure partition of the non-transitory memory associated with the trusted security zone, that when executed by the secure partition of the at least one processor, configures the secure partition of the at least one processor to:
amass the information about the uncompromised state associated with the hardware driver,
store, in the secure partition of the non-transitory memory, the information about the uncompromised state associated with the hardware driver,
perform, in response to receipt of the activation instructions by the first trusted application, a confidence check on the version of the hardware driver stored in the permissive sector and compare, in response to receipt of the activation instructions by the first trusted application, the trusted version of the hardware driver with the version of the hardware driver stored in the permissive sector and the information about the uncompromised state associated with the hardware driver with the current state of the hardware driver, and
enable, based on the confidence check and in response to a result of the comparison indicating that the version of the hardware driver stored in the permissive sector corresponds with the trusted version of the hardware driver and the current state of the hardware driver corresponds to the uncompromised state associated with the hardware driver, the first trusted application stored and executed in the secure partition of the trusted security zone to invoke the hardware driver, wherein the hardware driver is invoked by the first trusted application responsive to the enablement by the second trusted application.

2. The electronic device of claim 1 ,
wherein the information about the uncompromised state of the hardware driver is associated with an error detection action, and
wherein the information associated with the error detection action comprises at least one of: a checksum, a bit count of the driver, information about a cyclic redundancy check, information about a repetition code, information about a horizontal redundancy check, information about a vertical redundancy check, information about a parity bit, a digital signature, or information about a cryptographic hash function.

3. The electronic device of claim 1 , wherein the uncompromised state is associated with the hardware driver being free from sniffers, malware, Trojans, spyware, viruses, or other nefarious programs.

4. The electronic device of claim 1 , wherein the second trusted application further configures the secure partition of the at least one processor to: perform a confidence check on the current state of the driver prior to the comparison of the uncompromised state of the driver with the current state of the driver.

5. The electronic device of claim 1 , wherein the current state of the hardware driver corresponds with the uncompromised state responsive to the comparison indicating that the current state is unaltered from the uncompromised state.

6. The electronic device of claim 1 , wherein responsive to the comparison indicating that the current state of the hardware driver does not correspond with the uncompromised state, the second trusted application:
replace the hardware driver with another hardware driver that is in the uncompromised state,
prevent the first trusted application from invoking the hardware driver, or
prompt a display of the electronic device with options for user input to authorize invocation of the hardware driver by the first trusted application.

7. The electronic device of claim 1 , wherein the hardware driver stored in the normal partition of the non-transitory memory is a copy of the trusted version of the hardware driver.

8. The electronic device of claim 1 , wherein the version of the hardware driver is accessible to applications stored in the secure partition of the non-transitory memory and to applications stored in the normal partition of the non-transitory memory associated with the permissive sector.

9. The electronic device of claim 1 , wherein the first trusted application invokes at least one of the trusted version of the hardware driver or the version of the hardware driver.

10. The electronic device of claim 1 , wherein responsive to the results indicating that the version of the hardware driver stored in the permissive sector does not correspond with the trusted version of the hardware driver, the electronic device:
replaces the hardware driver with the trusted version of the hardware driver,
prevents the first trusted application from invoking the hardware driver, or
configures a display of the electronic device that presents options to receive user input corresponding to authorization that invokes the hardware driver by the first trusted application.

11. The electronic device of claim 1 , wherein the second trusted application is further configured to determine whether the trusted version of the hardware driver corresponds with the version of the hardware driver stored in the normal partition of the non-transitory memory in response to powering on the electronic device.

12. The electronic device of claim 1 , wherein a non-trusted application in the permissive sector invokes the hardware driver stored in the normal partition without the second trusted application verifying the integrity of the hardware driver.

13. A method for invoking a hardware driver on an electronic device, comprising:
storing, by an electronic device in a secure partition of a non-transitory memory of an electronic device, a trusted version of a hardware driver that provides information about an uncompromised state associated with the hardware driver, wherein the secure partition is associated with a trusted security zone providing a hardware root of trust to the electronic device and an operating system for the secure partition that runs separate from a normal partition operating system;
activating, by at least one processor of the electronic device, a first trusted application stored in the secure parti

Assignees

• Sprint Communications Co Lp

Inventors

• Paczkowski Lyle W
• Parsel William M
• Persson Carl J
• Schlesener Matthew C

Classifications

• 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 · CPC title

• G06F21/56

  Computer malware detection or handling, e.g. anti-virus arrangements · CPC title

• G06F21/53 Primary

  by executing in a restricted environment, e.g. sandbox or secure virtual machine · CPC title

• G06F21/00

  Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity · CPC title

• G06F21/64

  Protecting data integrity, e.g. using checksums, certificates or signatures · CPC title