Techniques for using TPM-based UEFI authenticated variables for providing computer security

Abstract

A method for creating and securely storing a hardware- or software-based asymmetric key pair on a device. The method includes executing with a first processor a first module, which accesses a first variable; creating an asymmetric key pair in a second processor, wherein the private key is sealed by crypto processor; signing a certificate of the public key with the private key sealed by the crypto processor; and storing the sealed private key and certificate as the first variable; and storing the first variable on the device to be accessed in executing the first module.

Description

Att’y Docket No. P75493TECHNIQUES FOR USING TPM-BASED UEFI AUTHENTICATED VARIABLES FOR PROVIDING COMPUTER SECURITYCROSS-REFERENCE TO RELATED APPLICATION

[0001] This International Application claims priority to U.S. Provisional Application No.63 / 749,967 filed lanuary 27, 2025, the disclosure of which is expressly incorporated by reference herein in its entirety.BACKGROUND1. FIELD OF THE INVENTION

[0002] Embodiments are directed to creating, modifying and storing of authenticated unified extensible firmware interface (UEFI) variables on a same client device.2. DISCUSSION OF BACKGROUND INFORMATION

[0003] UEFI authenticated variables are defined in the UEFI specification. A server or agent can write an authenticated variable, provided that they maintain a public certificate and a matching private key that signs the payload. A pre-boot module cannot securely store its state or publish its status as it would have to create a key pair and store the private key on the device itself, which is not secure.

[0004] UEFI variables can also be created as read-only or write-protected during the driver execution environment (DXE) phase of a UEFI boot process, but after DXE, the core services that lock variables become unavailable. In other words, there is no current solution for securely creating write-protected UEFI variables after the DXE phase in a pre-boot environment such as, i.e., transient system load (TSL) phase.

[0005] To the extent there may be solutions where the information can be stored securely, these techniques nevertheless require the server to send a signed request to an OS agent, and after reboot, the data is saved by the persistence module in a locked variable during DXE.SUMMARY

[0006] Embodiments of the present invention include usage of a trusted platform module (TPM) for creating an asymmetric key pair, used as signing key, in a hardware- or softwarebased, so that a private key is then securely sealed by or with the TPM. In other{P7549306940532. DOCX} - 1 -Att’y Docket No. P75493embodiments, a signing key pair can be created outside of TPM, but the created key can be sealed by or with the TPM. Furthermore, a signing key pair created outside of TPM can be encrypted by a symmetric data encryption key, where the encryption key is sealed by the TPM.

[0007] Since the key is bound to the TPM platform configuration registers (PCRs), it is only usable in the predefined condition of the pre-boot module in the boot process. The public certificate needed for writing authenticated variables is created on the fly during the pre-boot module load and is self-signed by the signing key. Then, the pre-boot module can write authenticated variables as necessary, supplying the created public certificate, date / time, and other data into a PKCS#7 (cryptographic message syntax) envelope, signed with the same signing key.

[0008] Embodiments of the present invention also include implementing the above-mentioned process in the UEFI environment. For instance, normally, UEFI core code includes a standard crypto package, such as, e.g., OpenSSL, that implements all the complexity of certificate manipulation, signing, and signature verification. Therefore, a standard UEFI application or module would link with cryptographic library functions or crypto provider functions (e.g., BaseCryptLib), which internally links with OpenSSL. The existing APIs require direct passing of the private key used by OpenSSL for signing, which may be impossible as the key is sealed by the TPM. Embodiments can be configured to use the OpenSSL Engine (or similar capability) that allows for the routing of various crypto primitives to a user-supplied function that redirects crypto operations, such as signing, to the TPM instead of being handled in the software.

[0009] Embodiments can be configured to securely store the signing key for use in extending protection to all pre-boot module data stored in other UEFI authenticated variables. In some examples, variables can be used to store keys encrypting / decrypting the sensitive data of the pre-boot module.

[0010] Moreover, in embodiments, the signing key can also serve as chain of authenticity of the pre-boot module data published to at least one processor, an OS, and a server. This feature can be achieved by publishing the public portion of the signing key to other entities that need to validate the integrity of the data.{P7549306940532. DOCX} -2-Att’y Docket No. P75493

[0011] Other exemplary embodiments and advantages of the present invention may be ascertained by reviewing the present disclosure and the accompanying drawing.BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The present invention is further described in the detailed description which follows, in reference to the noted plurality of drawings by way of non-limiting examples of exemplary embodiments of the present invention, in which like reference numerals represent similar parts throughout the several views of the drawings, and wherein:

[0013] Fig. 1 illustrates exemplary structure of a user device on which the authenticated UEFI variables can be created, modified and stored;

[0014] Fig. 2 illustrates an exemplary flow diagram of an exemplary embodiment of a method of operating the user device; and

[0015] Fig. 3 illustrates an exemplary flow diagram of an exemplary embodiment of a method for creating, modifying and storing authenticated UEFI variables on the user device.

[0016] Fig. 4A illustrated an exemplary flow diagram an embodiment configured for handling scenarios where PCR values can change and require recovery.

[0017] Fig. 4B illustrated an exemplary flow diagram an embodiment executing recovery and provisioning in 425 of Fig. 4A.

[0018] Fig. 4C illustrated an exemplary flow diagram an embodiment executing deprovisioning in 425 of Fig. 4A.DETAILED DESCRIPTION

[0019] The particulars shown herein are by way of example and for purposes of illustrative discussion of the embodiments of the present invention only and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the present invention. In this regard, no attempt is made to show structural details of the present invention in more detail than is necessary for the fundamental understanding of the present invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the present invention may be embodied in practice.{P7549306940532. DOCX} - 3 -Att’y Docket No. P75493

[0020] A TPM is a well-known module in computing devices that can be used to create an asymmetric key pair, with the private key securely sealed within the TPM or to seal a software-based asymmetric key pair. The key is bound to the TPM Platform Configuration Registers (PCRs), so it is only usable in the exact position of the pre-boot module 107 in the boot process. However, as the TPM created key pair cannot be securely stored on the device, the public certificate needed for writing authenticated variables is created on the fly during the pre-boot module 107 load and is self-signed by the loaded key. In this way, the pre-boot module 107 that created the key can write authenticated variables, such as authenticated UEFI variables, as necessary, supplying the created public certificate, date / time, and other data into a PKCS#7 (cryptographic message syntax) envelope, signed with the same TPMbased key.

[0021] In some embodiments, the above-mentioned techniques can be implemented in the UEFI environment. Normally, UEFI core code includes a standard crypto package, such as, e.g., OpenS SL, WolfSSL, that implements all the complexity of encryption, certificate manipulation, signing, and signature verification. Therefore, a standard UEFI application or module would link with crypto provider library functions (e.g., BaseCryptLib), which internally links with OpenSSL. The existing APIs require direct passing of the private key used by OpenSSL for signing, which is impossible as the private key is sealed in the TPM. In some embodiments, the pre-boot module 107 includes the functionality to communicate with an OpenSSL Engine (or similar capability) that allows routing various crypto primitives to a user-supplied function, provided by the pre-boot module 107, that redirects crypto operations, such as signing, to the TPM instead of being handled in software.

[0022] According to embodiments, the creating, writing and storing of the asymmetric key pair is performed on the same client device. While possibly accessible or readable by other applications, modules or devices, the asymmetric key pair is only usable and write accessible by the module that created it, e.g., a pre-boot module, etc. The asymmetric key can be created in a crypto processor (e.g., TPM), or encrypted with a key sealed by the crypto processor, on the client device and stored in an authenticated UEFI variable. In such scenarios, a separate device, i.e., different and / or remote from the client device, may be able to read the asymmetric pair but it cannot use and / or modify the asymmetric key pair.

[0023] Embodiments may utilize a callback feature, e.g., as in OpenSSL or WolfSSL, etc., executed by a processor to send function calls to the crypto processor to create a signature for{P7549306940532. DOCX} - 4 -Att’y Docket No. P75493the authenticated UEFI variable and the asymmetric key pair is stored in the authenticated UEFI variable. The signed authenticated UEFI variable ensures that the variable is write protected. Further, the authenticated UEFI variable system includes flash write protection, which prevents the separate device from write accessing the asymmetric key pair created and stored on the client device.

[0024] The authenticated UEFI variable can be written and modified only by the module that created it. Because the asymmetric key pair is bound to the PCRs of the TPM, the key cannot be loaded before or after the pre-boot module 107 runs.

[0025] UEFI authenticated variables offer a secure method for storing information on a device, ensuring that the data remains tamper-proof. The authenticated variables are created and modified by signing the payload with a private key, accompanied by a matching public certificate. The private key and the certificate required for signing authenticated variables are securely stored on the same device and are only accessible by the pre-boot module 107 that generated them.

[0026] Fig. 1 shows an exemplary a client device 100. According to embodiments, after client device 100’s power is turned on a boot process begins, e.g., by executing a module, such as a pre-boot module 107, which can be stored in one or more storage devices 102. The pre-boot module 107can store and / or modify its state or other data on the client device, e.g., external certificates, passwords, and other sensitive user data. Libraries 108 containing crypto provider library functions (e.g., BaseCryptLib), which internally links with crypto providers, such as OpenSSL, can be stored on the one or more storage devices 102 and accessible by pre-boot module 107

[0027] Any sensitive data stored on client device 100 must be encrypted, and if the encryption keys are stored on the same device, they must be sealed by a crypto processor, such as TPM. One such key is a data encryption key (DEK), which is for encrypting any data used by the pre-boot module. The other one is a signing key (SK), which is for signing data published by the pre-boot module to ensure its authenticity to a processor, an OS, and / or a server. The signing key can also be used to sign / protect integrity of all the other UEFI authenticated variables created by the processor, which store the pre-boot module's state, status, and data. Thus, this signing key is the root of integrity of all the other pre-boot module data stored with this method. Pre-boot module 107, which is executed by a processor 103,{P7549306940532. DOCX} -5 -Att’y Docket No. P75493e.g., a CPU, resident on the client device 100, can securely create, modify or delete authenticated UEFI variables, such as DEK and SK, which include a set of content accessible by pre-boot module 107.

[0028] The client device 100 can include a separate processor, processor 104, which is configured to create or seal symmetric and asymmetric keys, i.e., an encryption key and a signing key, stored as a payload in the authenticated UEFI variables in storage device 102. This separate processor 104, which can be different from the processor 103, may be, e.g., a secure crypto-processor, such as a Trusted Platform Module (TPM) by Trusted Computer Group (TCG). The crypto-processor is configured to create and securely store the encryption and signing keys on the device to prevent access to it by another device. In some embodiments, the crypto-processing includes one or more Platform Configuration Registers (PCRs) 106 to which the keys can be bound. Through PCRs 106, the pre-boot module keys are protected from tampering. Further, client device 100 can be connected to a server 110 through a network connection, e.g., WiFi, cellular, direct or any other known network connection. Server 110 includes a server processor 111 and one or more storage devices 112. A service module for communicating with client device 100, as well as with pre-boot module 107, can be stored in the one or more storage devices 112.

[0029] With slight reference to the client device shown in Fig. 1, an exemplary flow diagram of the operation of the device is depicted in Fig. 2, where the processor 103, e.g., a CPU, residing on the client device 100, executes the pre-boot module, e.g., a pre-boot module 107, stored on the one or more storage devices at 201 and accesses or creates authenticated UEFI variables that comprise first content accessible by the pre-boot module at 202. The separate processor 104, e.g., a crypto processor such as the TPM, resident on the client device can at 203 either create or load the keys from authenticated variables in storage 204, if it already exists. The keys, when created, are sealed in the crypto processor, e.g., bound to the PCRs. The crypto processor then stores the keys in authenticated UEFI variables in the storage device at 204.

[0030] The CPU registers for a callback operation for the crypto processor at 205 to create a signature for an authenticated UEFI variable in which the signing key is stored. Once the authenticated UEFI variable is created and stored, the signing key is usable and write accessible only, e.g., to modify or delete, by the pre-boot module on client device and therefore not usable or write enabled by other applications, modules or devices.{P7549306940532. DOCX} - 6 -Att’y Docket No. P75493

[0031] After powering on the client device, a module, e.g., the pre-boot module, can be executed at 301. The pre-boot module must immediately load its keys if they exist or create them on first run. To distinguish the first run from later runs, a check is performed to find a UEFI variable storing a key, such as DEK, at 304. If DEK exists, DEK, SK, and other keys are loaded from variables in 311, using the TPM as needed to unseal the PCR-bound data. The pre-boot module wants to save its state or other data that only it can modify, which is only possible if the system state hasn't changed since the keys bound to the PCRs were created.

[0032] If, at 304, a UEFI variable storing a key, such as DEK, has not been stored, the process will proceed to create the keys in 305. The created keys are bound to the PCRs at a particular point in time, e.g., the time of creation. In this way, the keys are usable only on the device using the same TPM and when specific hardware conditions are met. Moreover, from the PCR values, it can be confirmed that the client device’s state and other saved data has not changed and therefore that this data was not tampered with between device boots.

[0033] According to an exemplary embodiment, a signing key can be created using the TPM, which is required for writing authenticated UEFI variables by the pre-boot module.

[0034] The functionality to create the asymmetric key pair (public and private key) is built into TPM and the private key can be stored outside of the TPM in a TPM-encrypted form, i.e. sealed by the TPM. However, as existing UEFI APIs require direct passing of the private key used by various libraries, such as OpenSSL, for signing, this signing cannot be performed because the private key is sealed by the TPM. To address this deficiency in the known art, a random temporary key is generated at 306 to be passed to the API to ensure that the API works normally. At the same time, a callback is registered via OpenSSL API at 307, so when the actual signing operation happens, the callback receives control. When the callback is called on the signing operation 308, the temporary key is ignored and instead the TPM is called in 309 to perform signing with the signing key loaded into the TPM.

[0035] An authenticated UEFI variable for the signing key, which includes the TPM-encrypted (sealed) private key as a payload, is written at 310 by supplying the created public certificate, date / time, and other data into a PKCS#7 envelope that is signed with the same TPM-based private key.{P7549306940532. DOCX} - 7 -Att’y Docket No. P75493

[0036] If, at 304, a UEFI variable containing key has been stored or, after the authenticated UEFI variable has been written at 310, the process proceeds to retrieve and load the keys from the variables at 311, using TPM to validate PCR binding. In this way, if the device’s state is different from the state when the keys were created, the keys will not load and TPM will return an “integrity error” or similar reply. Keys that are created or sealed by TPM can only be accessed by the application on the client device because they are encrypted with the TPM internal seed and bound to the PCRs.

[0037] Once the keys are loaded, other UEFI authenticated variables that store pre-boot module state, other keys, and other data, can be decrypted with the DEK, updated, and signed with the SK at 313. In the event of an application or module install (provisioning) at 312, the pre-boot module can receive and securely store configuration data received from the OS agent or the server.

[0038] In the event of an application or module uninstall (deprovisioning) at 312, the keys and other data stored in authenticated UEFI variables are deleted at 314. However, as an preboot module cannot delete an authenticated variable without authorization, the same signing key used to write the variable must be available before the UEFI variable can be deleted.

[0039] Embodiments of the present invention can also be configured to handle scenarios in which PCRs used for key binding change without the possibility of being reverted to a known value. Such scenarios can increase the risk of permanent loss and / or access to sealed keys. As such, embodiments can be configured in a manner that causes a crypto provider (e.g., OpenSSL) to generate one or more authenticated variable signing keys, referred to as soft authenticated variables signing key (SAVSK), that are not sealed by the TPM. In such embodiments, the TPM may still perform procedures, e.g., to seal keys such as DEK, but not the signing key. The DEK is sealed to secure the SAVSK rather than SAVSK being sealed directly by the TPM. In accordance with these embodiments, if the PCRs change and DEK is lost, a rescue key is available.

[0040] For instance, in embodiments, the client device is configured to perform one or more procedures during the first time a client device is setup to account for recovery scenarios.

[0041] In these embodiments, the signing key SAVSK is software generated by the system crypto provider, such as OpenSSL, and is encrypted by DEK to be stored on the device. It is{P7549306940532. DOCX} - 8 -Att’y Docket No. P75493an asymmetric key pair used to sign all authenticated variables in the pre-boot module. The private portion is encrypted with DEK and stored as an authenticated variable signed by SAVSK. The public portion is wrapped in a x509 public certificate self-signed with SAVSK and stored as an authenticated UEFI variable. The DEK is a symmetric key used to encrypt all pre-boot module data for confidentiality, and which is TPM sealed with a data encryption wrapping key (DWK) and stored as an authenticated UEFI variable signed by SAVSK.

[0042] In further embodiments, DWK, which is recreated by the TPM on each pre-boot module start, is used to wrap (seal / unseal) DEK. A device decryption key (DDK) is an asymmetric key pair, in which the server uses the public portion to encrypt data sent to the client device and the client device uses the private portion so decrypt server messages. DDK is recreated by the TPM on each pre-boot module start and the public certificate is stored as an authenticated UEFI variable that is write protected.

[0043] In this fashion, the pre-boot module 107, using a crypto provider, can create default symmetric rescue keys, bind it to a crypto processor, and call the crypto provide to encrypt software keys with a bound rescue key.

[0044] Moreover, pre-boot module 107 also includes the functionality to create symmetric de-provisioning keys derived from a rescue key, call a crypto provider, such as OpenSSL to encrypt software keys with the de-provision key which can be saved to one or more authenticated variables.

[0045] In one embodiment, the client device is also configured to perform one or more procedures during the subsequent boot processes after the first time the client device is setup. In this scenario, pre-boot module 107with the help of a crypto provider, such as OpenSSL, creates the keys, reads variables and calls the crypto provider to decrypt data. In this fashion, one or more applications or modules can now read and decrypt all its previously encrypted data.

[0046] Figs. 4A - 4C are flow diagrams that illustrate how embodiments of the present invention can be configured to handle situations when system state and PCR values change as described herein.

[0047] Fig 4A illustrates an exemplary flow diagram of the TPM-based authenticated UEFI variable initialization, in which SK is now encrypted with DEK, additional Rescue and Deprovision keys are created, DEK is sealed with a data encryption wrapping key (DWK).{P7549306940532. DOCX} - 9 -Att’y Docket No. P75493

[0048] After powering on the client device, a module, e.g., a pre-boot module, can be executed at 401. The pre-boot module must immediately load its keys, if they exist, or create them on first run. To distinguish the first run from later runs, a check is performed to find a UEFI variable storing a key, such as DEK, at 402. If DEK exists, initialization has already been performed and setup is exited and a data encryption wrapping key (DWK) is created and DEK is unsealed from the UEFI variable with the created DWK at 421. The pre-boot module can now read and decrypt all of its previously encrypted data. The UEFI variable with the signing key is loaded at 422 and decrypted with DEK to obtain SAVSK and the signing certificate is loaded at 423 and is ready for writing authenticated variables. The pre-boot module can now write or delete any of its authenticated variables, encrypting them with DEK, if necessary, thereby achieving autonomous secure storage at the UEFI level. A device decryption key (DDK) is created in TPM at 424 and the public portion of DDK is saved in a UEFI variable and published to server, which can now send encrypted messages to the client device. After initialization, the server changes the rescue key from the default to a unique value. The process continues to determine whether to proceed with pre-boot module provisioning / deprovisioning at 425. In the event pre-boot module provisioning is to be performed, the process writes updated or modified authenticated UEFI variables signed by SK at 426. If pre-boot module deprovisioning is to be performed, the UEFI variables are deleted at 427.

[0049] If, at 402, DEK does not exist, the process will proceed to create DEK and SAVSK software keys at 405 using a crypto provider, e.g., OpenSSL, and a SAVSK self-signed signing certificate is generated at 406, which can be used for signing authenticated variables, and is saved as an authenticated UEFI variable. The SAVSK private key is encrypted with DEK at 407 and saved as an authenticated UEFI variable. A default rescue key is created at 408, which is bound to TPM, and is used to encrypt DEK. The rescue encrypted copy of DEK is then saved as an authenticated UEFI variable. At 409, a deprovision key is created, which is derived from the rescue key. SAVSK is encrypted with the deprovision key and saved as an authentication UEFI variable. DWK is created at 410 and DEK is sealed with DWK in TPM. Sealed DEK is saved as an authenticated UEFI variable. The process continues to determine whether to proceed with pre-boot module provisioning / deprovisioning at 425, as discussed above.

[0050] Fig. 4B illustrates an exemplary flow diagram for a provisioning and recovery process performed at 425 in Fig. 4A. If any PCR binding the DWK changes, e.g., after a{P7549306940532. DOCX} - 10 -Att’y Docket No. P75493BIOS update, the pre-boot module cannot recover the DEK and thus, cannot recover the SAVSK and its other encrypted data. Without SAVSK, all previously written UEFI authenticated variables cannot be overwritten or deleted. If PCR synchronization was lost before the server provisioned a new unique rescue key, then the system can be recovered manually using the default rescue key from 408 in Fig. 4A. Alternatively, the system can be cleaned with the deprovision key from 409 in Fig. 4A. If PCR synchronization was lost after provisioning the new rescue key, then the system can only be recovered or deprovisioned with a key available on the server side. The rescue key and deprovision key can be administered manually by a pre-boot module user interface or a tool. The server can also initiate automatic recovery without user intervention.

[0051] The exemplary flow in Fig. 4B is directed to the situation in which PCR synchronization was lost after provisioning the new rescue key, and begins on a server connected to the client device. The server reads the status of the service module (e.g., service module 113 from Fig. 1) at 500 to determine at 501 whether the pre-boot module is provisioned with a rescue key. When not provisioned with a rescue key, the server can send configuration data to the pre-boot module at 502 and send a unique rescue key at 503.

[0052] When it is determined at 501 that the pre-boot module is provisioned with a rescue key, the server via OS agent checks if the pre-boot module is in “PCR error” state at 504. If the pre-boot module is not in the error state, the system proceeds to normal operation at 505. In the event a PCR error is reported by the pre-boot module at 504, e.g., the pre-boot module publishes its error status, the server determines that the rescue key is needed. The server locates the unique rescue key for this device in the server database at 506 and a recovery secure message encrypted with DDK is sent to the client device at 507. In particular, the server uses the public portion of DDK to encrypt the rescue key and to send the encrypted rescue key to the client device. Hereafter, the process proceeds on the pre-boot module, where the pre-boot module validates the recovery secure message received at 508 and retrieves the rescue key, which is decrypted with DDK in TPM at 509. The encrypted DEK is read from a UEFI variable and decrypted with the rescue key at 510. Now all authenticated variables used by the pre-boot module can be decrypted and updated. At 511, the recovered DEK is used to decrypt SAVSK and a new DWK is created in TPM, which is bound to different PCR values at 512 to reseal DEK, which is then saved as an authenticated UEFI variable. On the next boot, assuming the PCRs remain the same, DEK will now successfully unseal with the new DWK. In some scenarios, an Internet connection may be unavailable for{P7549306940532. DOCX} - 11 -Att’y Docket No. P75493a server to deliver the rescue key. As such, a client device can receive a passcode during the execution of a boot loading process and determine that a rescue key is required. In this fashion, a rescue key is then derived from the passcode.

[0053] Fig. 4C illustrates an exemplary flow diagram for a deprovisioning performed at 425 in Fig. 4A. In some embodiments, the exemplary flow begins when a client device receives a passcode while a boot loading process is executed and activates a predefined key sequence to generate a deprovisioning key, thereby deprovisioning the pre-boot module instead of generating a rescue key. The exemplary flow begins on a server connected to the client device, e.g., the service module communicates with the pre-boot module, when the server decides at 600 to deprovision the pre-boot module instead of performing its recovery using a rescue key. In this case, the rescue key is located at 601 but the server decides to send a deprovision key instead. A deprovision key is derived from the rescue key at 602. At 603, a deprovision secure message is sent to the client device at 603, the deprovision secure message being encrypted with DDK. The process now proceeds on the client device, where at 604, the deprovision secure message is received by the pre-boot module. The deprovision key is decrypted with DDK in TPM at 605 and used to decrypt SK, SAVSK saved in an authenticated UEFI variable at 606. The recovered SK, SAVSK is used to delete all pre-boot module authenticated UEFI variables at 607.

[0054] Aspects of embodiments of the present disclosure can be implemented by such special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions and / or software, as described above. In embodiments, the software elements can include firmware, resident software, microcode, etc.

[0055] As will be appreciated by those ordinarily skilled in the art, aspects of the present disclosure may be embodied as a system, a method or a computer program product.Accordingly, aspects of embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present disclosure, such as the pre-boot module, may take the form of a computer program product embodied in any tangible medium of expression having computer-usable program code embodied in the medium.{P7549306940532. DOCX} - 12 -Att’y Docket No. P75493

[0056] In the context of this document, a storage device may be any a computer-usable or computer readable medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. A computer-usable medium may include a propagated data signal with the computer-usable program code embodied therewith, either in baseband or as part of a carrier wave. The computer usable program code may be transmitted using any appropriate non-transitory medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc.

[0057] Computer program code for carrying out operations of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The device may be connected to a destination server or service through a VPN or any other type of network. This may include, for example, firmware level networking, a local area network (LAN) or a wide area network (WAN), cellular and LoT networks, or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). Additionally, in embodiments, the present invention may be embodied in a field programmable gate array (FPGA).

[0058] The device, may be implemented as, or incorporated into, various devices, such as a personal computer, a tablet computer, a set-top box, a personal digital assistant, a mobile device, a palmtop computer, a laptop computer, a desktop computer, a communications device, a wireless telephone, a personal trusted device, a web appliance, or any other machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device.

[0059] The device may include at least one processor, such as, for example, a central processing unit and a crypto processor and preferably both. Moreover, the device may also include a storage device, such as a computer memory, which may include a static memory, a dynamic memory, or both, and may additionally or alternatively include a bootable storage device, including a solid state drive or a hard disk drive, random access memory, a cache, or any combination thereof. Of course, those skilled in the art appreciate that the computer memory may comprise any combination of known memories or a single storage.

[0060] The device may also include a medium reader and a network interface. Furthermore, the client device may include any additional devices, components, parts, peripherals,{P7549306940532. DOCX} - 13 -Att’y Docket No. P75493hardware, software or any combination thereof which are commonly known and understood as being included with or within a computer system, such as, but not limited to, an output device. The output device may be, but is not limited to, a speaker, an audio out, a video out, a remote control output, or any combination thereof. Further, a bus can be provided for communication between the various components of computer system.

[0061] Furthermore, the aspects of the disclosure may take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. The software and / or computer program product can be implemented in the environment of Fig. 1. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer -readable storage medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk -read only memory (CD-ROM), compact disc - read / write (CD-R / W) and DVD. More specific examples (a non-exhaustive list) of the computer-readable medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a bootable storage device, including a solid state drive or hard disk drive, an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, an optical storage device, a transmission media such as those supporting the Internet or an intranet, a magnetic storage device, a USB key, and / or a mobile phone.

[0062] Although the present specification describes components and functions that may be implemented in particular embodiments with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same or similar functions are considered equivalents thereof.

[0063] The illustrations of the embodiments described herein are intended to provide a general understanding of the various embodiments. The illustrations are not intended to serve{P7549306940532. DOCX} - 14 -Att’y Docket No. P75493as a complete description of all of the elements and features of apparatus and systems that utilize the structures or methods described herein. Many other embodiments may be apparent to those of skill in the art upon reviewing the disclosure. Other embodiments may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. Additionally, the illustrations are merely representational and may not be drawn to scale. Certain proportions within the illustrations may be exaggerated, while other proportions may be minimized. Accordingly, the disclosure and the figures are to be regarded as illustrative rather than restrictive.

[0064] Accordingly, the present disclosure provides various systems, structures, methods, and apparatuses. Although the disclosure has been described with reference to several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the disclosure in its aspects. Although the disclosure has been described with reference to particular materials and embodiments, embodiments of the invention are not intended to be limited to the particulars disclosed; rather the invention extends to all functionally equivalent structures, methods, and uses such as are within the scope of the appended claims.

[0065] While the computer-readable medium may be described as a single medium, the term “computer-readable medium” includes a single medium or multiple media, such as a centralized or distributed database, and / or associated caches and servers that store one or more sets of instructions. The term “computer-readable medium” shall also include any medium that is capable of storing, encoding or carrying a set of instructions for execution by a processor or that cause a computer system to perform any one or more of the embodiments disclosed herein.

[0066] While the specification describes particular embodiments of the present disclosure, those of ordinary skill can devise variations of the present disclosure without departing from the inventive concept.

[0067] One or more embodiments of the disclosure may be referred to herein, individually and / or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any particular invention or inventive concept.{P7549306940532. DOCX} - 15 -Att’y Docket No. P75493Moreover, although specific embodiments have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.

[0068] The above disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover all such modifications, enhancements, and other embodiments which fall within the true spirit and scope of the present disclosure. Thus, to the maximum extent allowed by law, the scope of the present disclosure is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.

[0069] Accordingly, the novel architecture is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.

[0070] While the disclosure has been described with reference to specific embodiments, those skilled in the art will understand that various changes may be made and equivalents may be substituted for elements thereof without departing from the true spirit and scope of the disclosure. While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the embodiments of the disclosure. Rather, the words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the disclosure. In addition, modifications may be made without departing from the essential teachings of the disclosure. Furthermore, the features of various implementing embodiments may be combined to form further embodiments of the disclosure.

[0071] While the specification describes particular embodiments of the present disclosure, those of ordinary skill can devise variations of the present disclosure without departing from the inventive concept.{P7549306940532. DOCX} - 16 -Att’y Docket No. P75493

[0072] Insofar as the description above and the accompanying drawing disclose any additional subject matter that is not within the scope of the claims below, the embodiments are not dedicated to the public and the right to file one or more applications to claim such additional embodiments is reserved.{P7549306940532. DOCX} - 17 -

Claims

Att’y Docket No. P75493PATENT CLAIMSWhat is Claimed:

1. A method for creating and securely storing a hardware- or software-based asymmetric key pair on a device, the method comprising:executing with a first processor a first module, which accesses a first variable;creating an asymmetric key pair in a second processor, wherein the private key is sealed by crypto processor;signing a certificate of the public key with the private key sealed by the crypto processor; andstoring the sealed private key and certificate as the first variable; andstoring the first variable on the device to be accessed in executing the first module.

2. The method according to claim 1, wherein the first processor is a CPU and the second processor is a crypto processor.

3. The method according to claim 2, wherein the first variable is an authenticated unified extensible firmware interface (UEFI) variable.

4. The method according to claim 3, wherein the first module is a pre- boot module.

5. The method according to claim 2, wherein the crypto processor comprises a trusted platform module (TPM).

6. A method for using an authenticated variable created and securely stored on a device, the method comprising:executing with a first processor a first module, which stores a signing key in a first variable;loading the signing key into a second processor;determining whether the state of the device is different from when the first variable was created; and{P7549306940532. DOCX} - 18 -Att’y Docket No. P75493instructing the second processor to perform operations involving the private key.

7. The method according to claim 6, wherein the first processor is a CPU and the second processor is a crypto processor.

8. The method according to claim 7, wherein the first variable is an authenticated unified extensible firmware interface (UEFI) variable.

9. The method according to claim 8, wherein the first module is a pre-boot module.

10. The method according to claim 7, wherein the crypto processor comprises a trusted platform module (TPM).

11. The method according to claim 6, wherein the signing key is securely stored in one or more storage devices on the device.

12. The method according to claim 11, wherein the signing key protects application data stored in other UEFI authenticated variables.

14. The method according to claim 12, wherein the other UEFI authenticated variables are configured to encrypt / decrypt sensitive data of the first application.

15. The method according to claim 11, wherein the device is operable in a clientserver environment, in which the device is coupled to a server, and the signing key is configured for confirming a chain of authenticity of module data published to the first processor, to an operating system of the device, and to the Server.

16. The method according to claim 15, wherein a public portion of the signing key is published to other entities that need to validate the integrity of the module data.{P7549306940532. DOCX} - 19 -

Images