Advanced Firmware Lock
Patent Information
- Application Number
- JP2024546401
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-02-07
- Filing Date
- 2023-01-31
- Publication Date
- 2025-02-21
Smart Images
Figure 2025505197000001_ABST
Abstract
Description
[Technical field]
[0001] This disclosure relates to security in mobile electronic devices, and in particular to the use of firmware locks. [Background technology]
[0002]
[0002] Firmware locks are generally considered to be more robust than other types of device locks. However, existing firmware locks can still be circumvented by an experienced intruder.
[0003]
[0003] One existing firmware lock is based on reports, timer expiration, or hacking attempts. A unified extensible firmware interface (UEFI) agent operates during boot (or startup) based on reports stored in the extensible firmware interface (EFI) partition. The reports are periodically stored in the partition by an operating system (OS) agent that receives instructions periodically from a server. Device rules detect non-compliant use, reports of theft or loss, timer expiration, or hacking attempts and automatically lock down the device.
[0004]
[0004] Another solution provides a firmware lock, where a lock command is issued remotely, causing a reboot, and the user must wait for a remote unlock command before being able to log in again with the configured credentials.
[0005]
[0005] Absolute Software currently offers a firmware lock feature with an offline lock feature. Offline locking is a function that locks the firmware by triggering the Absolute Device Freeze feature based on a timer expiration or other condition. TM ) agent can be run offline.
[0006]
[0006] This background is not intended, nor should it be construed, as constituting prior art against the present invention. Summary of the Invention
[0007]
[0007] At each boot or reboot of the electronic device, the firmware agent provides a challenge to the OS agent for the subsequent boot, i.e. the OS agent must respond correctly to the challenge during the current boot session to enable the next boot. During the firmware boot phase, the firmware agent processes the response to the previous challenge: the OS agent provides the prior response to a designated mailbox in the previous boot session, i.e. when the device was last switched on and, if necessary, connected to the monitoring server. If the response is correct, the device boots normally. If the response is incorrect or missing, a firmware lock is set. If the OS agent is tampered with in the previous boot session and fails to provide a response, in the subsequent session the firmware agent can lock the device, so that it will not boot until it is unlocked. If the OS agent is tampered with after it has already provided a response, the device may be able to boot normally once more, but will not boot thereafter. The OS agent can detect tampering attempts and remove previously provided responses before they become inoperable, reducing the likelihood of a redundant normal boot. The OS agent can also choose to write the response at the very end of a session, for example as part of an OS restart or shutdown procedure, to achieve a similar effect.
[0008]
[0008] An analogy would be a room accessed by a door with a deadlatch lock with dogging. The lock or key can be set to not lock the door, corresponding to an electronic device that does not have a lock. The lock can also be set to lock the door when open, so that it locks immediately when closed, and remains open otherwise. This corresponds to the behavior of the electronic device when it has a lock. If the correct response continues to be provided, the door will remain open, but if the correct response is not provided, the device will be locked and cannot be unlocked unless a passcode is entered. A passcode is like a lock on a door.
[0009] The present disclosure is a method for protecting an electronic device, the method comprising: a firmware (FW) agent in the electronic device generating a challenge for an operating system (OS) agent in the electronic device during a boot process of the electronic device; the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is complete; the FW agent checking for a response during a subsequent boot process of the electronic device; and The FW agent then allows or aborts completion of the subsequent boot process depending on whether the response is correct or incorrect, respectively, and the electronic device accepts one or more inputs from the user between the end of the boot process and the beginning of the subsequent boot process.
[0010]
[0010] An electronic device is disclosed that includes a processor and a non-transitory computer readable storage medium, the storage medium storing a firmware (FW) agent and an operating system (OS) agent as computer readable instructions that, when executed by the processor, perform the following: the FW agent generating a challenge for the OS agent during a boot process of the electronic device; the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is complete; the FW agent checking for a response during a subsequent boot process of the electronic device; and the FW agent allowing or halting the completion of the subsequent boot process depending on whether the response is correct or incorrect, respectively; and the electronic device accepts one or more inputs from a user between the end of the boot process and the beginning of a subsequent boot process.
[0011]
[0011] A system is further disclosed that includes a server and an electronic device, the electronic device including a processor and a non-transitory computer readable storage medium, the storage medium storing a firmware (FW) agent and an operating system (OS) agent as computer readable instructions, which when executed by the processor: the FW agent generating a challenge for the OS agent during a boot process of the electronic device; The OS agent gets the response from the server; the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is complete; the FW agent checking for a response during a subsequent boot process of the electronic device; and the FW agent allowing or halting further completion of the boot process depending on whether the response is correct or incorrect, respectively; and the electronic device accepts one or more inputs from a user between the end of the boot process and the beginning of a subsequent boot process.
[0012]
[0012] This summary does not necessarily describe in detail all of the features of the invention and is not intended to, and should not be construed as, limiting the invention. [Brief description of the drawings]
[0013] [Figure 1] FIG. 1 is a schematic block diagram of a system according to an embodiment of the present invention. [Diagram 2]
[0014] FIG. 2 is a flow chart according to an embodiment of the invention for booting with and without a connection to a server. [Diagram 3]
[0015] FIG. 3 is a flow chart according to an embodiment of the invention for setting up a device for offline response generation. [Figure 4]
[0016] FIG. 4 is a flow chart for responding to a challenge offline according to an embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0014] A. Terminology
[0017] BIOS Basic input-output system
[0018] CPU Central processing unit
[0019] Digest - digest, hash
[0020] DPAPI - Data Protection Application Programming Interface
[0021] DXE - Driver execution environment. This is the third phase of the UEFI boot process. During DXE, drivers install boot and runtime services. In DXE, UEFI loads drivers for configured devices, mounts drives, and finds and executes boot code. After control is transferred to the boot OS, runtime services remain resident to handle calls from the OS to UEFI, and boot services exit.
[0015]
[0022] EFI - Extensible firmware interface
[0023] FW - Firmware
[0024] HDD - Hard disk drive
[0025] Lock message - A communication containing the unlock passcode hash and, optionally, the offline lock hash and other parameters. If the offline lock hash is provided in the lock message, it will result in a pre-lock action, otherwise a lock action will occur.
[0016]
[0026] Lock action - The device is locked immediately upon receiving a lock message that does not contain the offline lock hash.
[0017]
[0027] Mailbox - An area in the firmware, like a UEFI variable, that is accessible to both the firmware agent and the OS agent. The contents of the mailbox can be authenticated during the DXE phase of boot.
[0018]
[0028] Module - any component of the present invention relating to any or all of the features of the present invention, without limitation. A module may be a software, firmware, or hardware module.
[0019]
[0029] NVRAM - Non-volatile random access memory
[0030] OEM - Original equipment manufacturer
[0031] Offline lock code - A code that causes a device to be locked. For example, the lock may be a firmware lock that is triggered by the offline lock code. This may occur when instructions cannot be received from the server. The OS agent knows or generates the offline lock code to lock the device.
[0020]
[0032] Offline lock hash - A hash of the offline lock code.
[0021]
[0033] OS - Operating system
[0034] Pre-lock action - An electronic device is prepared to lock, i.e., it is not actually locked, but is prepared to lock after receiving a lock message that contains an offline lock hash. The presence of the offline lock hash instructs the firmware agent to save the message parameters and prepare to apply the lock if certain conditions are met. Thus, the lock itself may be considered prepared.
[0022]
[0035] Response - proof that the responder knows the secret. For example, the hash of the secret is used to calculate the digest of the response message, so that neither the secret nor the hash of the secret is sent to the challenger. The challenger must calculate the hash of the secret and the response digest in the same way as the responder and check if the digests match.
[0023]
[0036] RO - Read-only
[0037] Secret - A code (e.g., a random number or nonce) known only to the challenger and responder.
[0024]
[0038] Session - The period from when the CPU is reset at the beginning of the session until it is switched off or restarted. A session consists of the following phases, in chronological order: Firmware Boot Phase - The period from when the firmware boot begins and the CPU is reset until the firmware hands control over to the OS boot loader. The firmware agent runs during the trusted portion of the firmware boot.
[0025] b. OS Execution Phase - The period from the start of the OS boot loader to the point of OS restart or shutdown. The OS Agent is loaded during the startup portion of the OS Execution Phase and remains active and communicating with the server until the end of the session. A session typically includes a period of use by a user of the electronic device during the OS execution phase. For example, the user may interact with the electronic device to provide input to a product software application on the electronic device or to display a presentation or video on the electronic device. Other inputs may be received by the electronic device from the user, and other outputs may be generated by the electronic device for the user. Thus, the OS execution phase is at least an order of magnitude longer than the firmware boot phase, and often several orders of magnitude longer. A session may include a period during which the electronic device is ready for use by a user, such as by displaying a prompt to enter a user identifier or password. A session may also include a period during which the electronic device automatically downloads software updates from a remote server. A session may include a period during which the electronic device is partially powered off, such as in a sleep or hibernation mode.
[0026]
[0039] Subsequent - When used to refer to a later event in a set of events, this means the event that immediately follows another event.
[0027]
[0040] TLS - Transport Layer Security
[0041] TPM - Trusted platform module
[0042] UEFI - Unified extensible firmware interface
[0043] Unlock passcode - Not a password, this is automatically generated by the server (not the user) and is a random sequence of bytes, i.e. a code, rather than a word or phrase.
[0028]
[0044] Unlock passcode hash - A hash of the unlock passcode that can be used to unlock a device after the firmware lock has been triggered.
[0029] B. Exemplary Embodiments
[0045] The currently disclosed solution uses an active challenge / response mechanism to keep electronic devices unlocked and to automatically lock them otherwise. During setup, which may require one or more boot cycles, the server sends a secure-lock message to the device, which includes an unlock passcode hash and an offline-lock hash. The device is prepared, e.g., in a pre-lock or lock-ready state, and is assumed to operate normally if it has access to a response to the challenge. It is also ready to lock when the OS agent sends a secret offline-lock code to the firmware lock module.
[0030]
[0046] At every boot, the firmware agent generates a challenge, and only the server or OS agent that has the corresponding secret can generate a proper response to that challenge. The challenge is, for example, a single-use challenge based on a high-quality nonce, and the response is the corresponding single-use response. The response is written by the OS agent in a specified mailbox for every session (i.e., period) that the device is switched on, i.e. before the device is reset. The mailbox can be, for example, a regular UEFI variable in NVRAM. For example, the OS agent can write the response to the mailbox as soon as it starts running, if it has it, or it may receive the response from the server and write it to the mailbox afterwards. At subsequent boots (e.g., at CPU reset), the firmware agent verifies the response, and if it is correct, the boot continues normally; otherwise, the firmware lock is applied.
[0031]
[0047] In other embodiments, the mailbox may be replaced by a file in the EFI partition, a hardware register, TPM memory, or any other non-secure non-volatile storage accessible to both the OS and the firmware agent.
[0032]
[0048] When a device is used offline and needs to get a response from the server, there may be a grace number of reboots allowed without a response being provided. This is to avoid locking the device every time it is used offline. A skip counter is used to count the number of times the device is rebooted without a response. However, certain sensitive devices may be required to connect with each session to avoid being locked out. If the device inadvertently locks up due to too many offline reboots without a response, it is possible to unlock the device if you know the unlock passcode, a hash of which is stored in a location accessible to the firmware lock.
[0033]
[0049] During the UEFI DXE phase, the FW Agent loads and generates a nonce (used as a secret), generates a challenge, and the nonce hash is stored in the FW NVRAM for future validation. This is similar to the process described in patent application PCT / CA2018 / 051064, titled Secure Firmware Interface. After that, there may be other FW Agent steps, such as validating previous challenges, other tasks, such as communicating with a server or other FW components, and so on. Typically, at boot time, the OS boots, the OS Agent starts, the OS Agent checks the challenge, the OS Agent communicates with the server, the server generates a response, the OS Agent writes the response to a mailbox, and then the device reboots. All of this happens in that order within a session. Then, at the next boot time, the FW Agent generates a new challenge and validates the result of the previously saved response in the mailbox to decide whether to continue booting or not.
[0034]
[0050] If the boot process does not continue, the device will need to be unlocked, after which a challenge will be generated again by the firmware before the corresponding response will be checked on the next boot.
[0035]
[0051] If the requirement of a challenge / response with the server on every session to keep the device unlocked is too strict, the solution can be improved by using a separate secret between the firmware agent and the OS agent, so that the OS agent can respond without needing to contact the server. This is less secure as it requires the secret to be stored on the device. In one possible protocol, the firmware agent generates a separate key pair, stores the public key as a firmware variable, encrypts the private key, and sends it to the server over Absolute's secure interface (see patent application PCT / CA2018 / 051064). This can be done using a separate mailbox to avoid blocking other secure messages that may be delivered from the server to the device. The server has the encryption key that the firmware agent used to encrypt the private key, uses it to decrypt the private key, and sends the decrypted private key to the OS agent over Transport Layer Security (TLS). The OS Agent stores the private key in the hard disk drive (HDD) or registry, which is protected by the Data Protection Application Programming Interface (DPAPI). From this point on, the firmware agent generates random data challenges, stores their hashes, and encrypts the random data with a public key. The OS Agent then decrypts the encrypted random data with a private key, hashes the random data, and then sends the random data hash as a response, signed with the private key, to the firmware agent. By storing the private key securely in the OS, only the logged in user or the admin user has access to it, and not hackers.The Firmware Agent verifies the signature of the response and compares the stored random data hash with the one received from the OS Agent.
[0036]
[0052] If the private key were stored directly by the firmware agent, and thus accessible to the OS agent, this would be insecure because it would create an opportunity through which channels it could be exposed to hacking.
[0037]
[0053] To further improve security, the aforementioned secrets can be stored in a Trusted Platform Module (TPM).
[0038]
[0054] It is possible to prevent a device from being hacked by a physical attack using a flash programmer. For example, a hacker could try to find and clear lock bits in the firmware flash. TM When implementing the specification, this is not possible, and this is an interface to redirect the writing of firmware variables from the default location (the main BIOS flash) to a secure storage location in the OEM implementation.
[0039]
[0055] FIG. 1 is a schematic block diagram of an exemplary embodiment of a system for providing firmware locking, showing the major modules. A server 20 having a response 22 or the ability to generate a response after receiving a challenge is connectable to a device 30 via one or more communication networks. The device 30 is an electronic device such as, but not limited to, a laptop, tablet, smartphone, or desktop. The device 30 includes one or more processors 32 operatively connected to a firmware 40, an OS 60, and a user interface 70. The firmware 40 includes a FW agent 42 including a challenge generator 44 and lock instructions 46. The challenge generator stores the challenge in a UEFI read only variable 47. The lock instructions 46 activate a FW lock 50. The FW agent is connected to a mailbox 52 capable of receiving a response to the generated challenge. The OS 60 includes an OS agent 62 that is operational when the OS is running. The OS agent 62 has a response 64, access to the response, or the ability to generate a response. The OS agent 62 also includes another lock command 66 that can be sent to the FW lock 50 at any time depending on conditions detected by the OS agent. When the FW lock 50 is triggered, the firmware 40 is prevented from booting to the OS, thereby locking the device 30. The device 30 can be unlocked by the user entering an unlock passcode 72 via a user interface 70 when the device is in the middle of booting. The device 30 can also be unlocked using various means of delivering the unlock passcode to the FW agent, by other means such as the BIOS level network stack, disk, etc.
[0040]
[0056] FIG. 2 is a flow chart of booting with and without connection to a server. Let us start by assuming that the lock system is fully set up and the device has booted. In step 80, the OS agent writes to the mailbox a response to a challenge generated by the firmware agent during the current session, e.g. at the beginning of the current session. This is done with the hope that the firmware agent will verify this response in the next session and allow the OS to boot again. It is assumed that during the current session, the device will be used by a user who provides one or more inputs to the device, which is shown in step 91. Note that the use of the device by the user can continue after step 80 as the session continues. At the end of the current session, in step 82, the device is reset. In other cases, the device is switched off in step 82 because, for example, it is not required for the user's use of the device. It may therefore remain switched off for an extended period of time before a subsequent session begins. Step 82 indicates whether the device is reset or switched off, which is usually done by the user when the user wishes to end the session. The device begins to boot in step 83. In this subsequent session, the firmware agent generates a new challenge in step 84 and requests a new response from the OS agent to ultimately continue operation of the device in another subsequent session.
[0041]
[0057] The FW Agent generates a new nonce / challenge on every boot in step 84, regardless of the outcome of the previous boot. The Firmware Agent passes the challenge to the OS Agent using a read-only UEFI variable so that the challenge is always ready to be read by the OS Agent or the server on the very first boot after setup and after any offline period. If challenge generation was skipped when the device was offline, on the very next online boot the server would not have the challenge and would not be able to generate a response.
[0042]
[0058] In step 85, the FW agent checks the FW lock flag, which indicates whether a FW lock was triggered during the previous boot. If the FW lock flag is not set, the process proceeds to step 86. If the FW lock flag is set, indicating that a FW lock is active, the process jumps to step 98, where a passcode is required to complete the boot.
[0043]
[0059] In step 86, a check is made to see if the device is prepared for locking, i.e., the lock is ready to be used. This assumes that a challenge mechanism has already been set up (keys have been generated and stored, etc.). If the FW is not locked and not prepared for locking, the process proceeds to step 90 and the boot completes normally. After the boot process is finished, in step 91, the device is used by the device user. In step 86, there may be further checks, such as setup steps including advanced FW locking. For example, the lock message may request that offline challenges be disabled. The process may loop through the above steps (80-90) as many times as necessary to set up the lock so that the device is ready to lock.
[0044]
[0060] If the lock is ready or will be ready, the FW agent checks whether the existing response variable is empty in step 87. The response variable is a read-only UEFI variable in the mailbox. If the response variable is empty, then in optional step 88, the skip counter is incremented, which occurs if the device is not connected to the server. Optional step 89 also occurs if the device is not connected to the server, in which the skip counter is checked to determine if the skip count is below a pre-configured level (n). Step 89 may also occur if the OS agent has been removed or disabled and is unable to generate a response. If the skip count is within the limits, the process proceeds to step 90 and the boot is complete. Then, in step 91, the user uses the device. At this point, the device is fully operational without requiring a connection to the server. While this session is active, the process returns to step 80 for the next session.
[0045]
[0061] However, if the skip count in step 89 reaches the limit (n), the FW agent activates the FW lock in step 96. In strict environments where graceful reboots without response are not allowed, the skip count check in step 89 can be omitted (or the limit n can be set to 0). In this case, an empty response (from step 87) will cause the process flow to proceed straight to step 96 to lock the device.
[0046]
[0062] If the response variable is not empty in step 87, i.e., if there is a previous response from the OS agent, then in step 92 the FW agent receives the existing response from the mailbox. This response should be the response that the OS agent provided last time in the latest session. If the response is correct in step 94, the device completes the boot in step 90. If the response is incorrect or not present, then in step 96 the FW agent activates the FW lock. In step 97 the FW agent sets a flag in the FW storage location to indicate that the FW is locked. This is the flag checked in step 85. The device then requests entry of an unlock passcode in step 98 to unlock the device and complete the boot. If the correct unlock passcode is received in step 100, it unlocks the device, i.e., the lock flag is cleared in step 102, the unlock and offline hashes are cleared, the skip count is reset to zero in step 103, etc. in preparation for the next lock message. Once the lock is disabled, the device continues booting at step 104 .
[0047]
[0063] After step 104, in step 106, the FW lock feature is re-enabled after the device has been set up again by receiving a Secure Lock message that prepares the device to lock using the new hash and other parameters. During setup, the server sends a Secure Lock message to the device that contains the unlock passcode hash and the offline lock hash. The device may be assumed to be pre-locked, but will operate normally if it has access to the response to the challenge. It also prepares to lock when the OS agent sends the secret offline lock code to the firmware lock module.
[0048]
[0064] If the passcode is incorrect or not entered at step 100, the process triggers the initiation of a reboot at step 112. Optionally, the device can also increment an attempt counter that counts the number of times an incorrect passcode is entered at step 114. Additionally, the device may optionally introduce a delay at step 116 before requesting that a passcode be entered at step 98, the delay increasing as the counter increments or increasing after a configurable number of attempts is reached.
[0049]
[0065] Locking an online device can be accomplished using a simple signed plaintext lock command from the server, but such a signed command from the server cannot be delivered if the device is offline. FIG. 3 is a flow chart of an exemplary method for setting up a device for offline response generation. In step 200, a public-private key pair is generated by the FW agent. This is after the FW agent receives a secure command to prepare the device for locking, locking / unlocking hashes, configuration settings, etc. during setup. If the lock configuration requires generation of an offline response, this sub-function (offline lock) is enabled. In step 204, the public key is stored in the FW. In step 206, the FW agent encrypts the private key. In step 208, the FW agent sends the encrypted private key to the server. In step 210, the server decrypts the private key. In step 214, the server sends the decrypted private key to the OS agent over an encrypted TLS channel. In step 218, the OS agent receives the decrypted private key over an encrypted TLS channel. In step 220, the OS Agent stores the private key in secure storage provided by the OS. The public / private key pair is stored during the pre-lock setup phase and neither is sent in the challenge / response communication. In this embodiment, there are secure links between the FW Agent and the Server and between the Server and the OS Agent, but there is no initial secure connection between the FW Agent and the OS Agent. Thus, the process of FIG. 3 is for establishing a secure connection between the FW Agent and the OS Agent required for offline communication.
[0050]
[0066] Alternatively, the key pair is generated on the server side, not by the firmware. The server synchronously sends the signed public part to the firmware and the private part to the agent over an encrypted TLS channel as part of the pre-lock procedure. This eliminates the need for the FW to send the private key to the agent via the server. This also helps the server to manage the key pair, since it can periodically refresh expired keys and send new ones to the FW and OS agent. Although possible, key refreshes can be cumbersome if initiated from the firmware side.
[0051]
[0067] FIG. 4 is a flow chart for responding to a challenge when the device is offline. In step 230, the FW agent generates a random number (i.e., a random nonce or secret), hashes it in step 234, stores the hash in step 236 for later verification, and encrypts a challenge blob derived from the random number using a public key in step 238. Adding further status information to the random nonce results in a challenge blob. The FW agent then stores a digest of the challenge blob in step 239. The FW takes a hash of the plaintext challenge blob and stores the hash for future verification of the response. The FW agent sends the encrypted challenge blob (or "challenge") to the OS agent in step 240. If signing a message, the signature is generated from a short message digest (hash). The encrypted challenge blob (or simply challenge) is passed to the OS agent in a read-only variable. The challenge blob may contain additional information that the firmware wants to send to the agent, such as the number of challenges skipped and other status information.
[0052]
[0068] The OS Agent has already received the private key once during the pre-lock setup and will use it until locking / unlocking occurs, the server deactivates (or deactivates) the offline response feature, or the key pair is updated. In step 244, the OS Agent decrypts the encrypted challenge blob with the private key and obtains the plaintext challenge blob. The OS Agent obtains the digest in the same way as the FW Agent did. The OS Agent then generates a response, i.e. some information to return to the FW Agent, e.g. the string “OK”, a timestamp, etc. To sign this message, the message is hashed and the hash of the original challenge blob that contained the secret is added. In this way, it is possible to say that the response digest contains a digest of the secret, or that the secret was used to generate the response digest. In step 248, the OS Agent signs the response using the decrypted secret (i.e. the random number) when generating the digest. In step 250, the OS Agent sends the signed response to the FW Agent.
[0053]
[0069] Steps 230 to 240 are performed in the FW, during which the encrypted challenge is stored in a read-only UEFI variable. Afterwards, the OS is started, the OS agent loads, and the process proceeds to step 244. All steps are in sequence within one boot until step 250, where the response is written to the mailbox. After step 250, there is a reboot 251 to return to operation from the FW, to verify the response and take action. In step 252, the FW agent in the FW verifies the signature of the signed response using the digest of the challenge blob it previously saved. If the FW verifies the signature of the response, it takes the hash of the response message (the “OK” string) and adds the hash of the challenge it previously saved. The resulting digest should be the same as the one calculated when the OS agent generated the signature. Therefore, if the FW agent calculates the signature of this digest using its public key, it should match.
[0054]
[0070] If the signature verification is successful, the device completes the boot, otherwise the device waits for the unlock passcode to be entered. If the signature verification fails, a device lock is triggered, which is a significant state change. Once locked, an unlock passcode or other unlock mechanism is required before the unlock process can take place.
[0055]
[0071] Throughout the description, specific details are set forth to provide a more complete understanding of the invention. However, the invention may be practiced without these details. In other instances, well-known elements have not been shown or described in detail, and repeated steps and features have been omitted to avoid unnecessarily obscuring the invention. In general, unless otherwise indicated, a single element may be a plurality, and vice versa, without loss of generality. Thus, the specification should be interpreted in an illustrative and not a limiting sense.
[0056]
[0072] The detailed description has been presented in part in terms of methods or processes, symbolic representations of operations, functionality and features of the invention. Methods or processes are implemented herein by software and firmware, which are generally understood to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals or values capable of being stored, transferred, combined, compared, and otherwise manipulated. The processes described herein may be controlled by coded instructions, such as microcode, and / or by programming instructions stored in one or more tangible or non-transitory media readable by a computer or processor. The code modules may be stored in any computer storage system or device, such as a hard disk drive, optical drive, solid-state memory, and the like. Alternatively, the methods may be embodied partially or wholly in specialized computer hardware, such as ASIC or FPGA circuitry.
[0057]
[0073] Where a processor is described, the processor may include two or more component processors. A computer-readable memory may be divided into multiple component memories of the same or different types. In some embodiments, steps in the flowcharts and other figures may be performed in a different order, steps may be omitted, or additional steps may be included, without departing from the invention. Modules may be combined or divided into component modules.
[0058]
[0074] It will be apparent to those skilled in the art that further modifications can be made to the specific details disclosed herein, resulting in other embodiments that are within the scope of the disclosed invention. All configurations described herein are merely exemplary, and the actual configuration depends on the specific embodiment. Therefore, the scope of the present invention should be construed according to the contents defined by the following claims.
Claims
1. 1. A method for protecting an electronic device, comprising: a firmware (FW) agent in the electronic device generating a challenge for an operating system (OS) agent in the electronic device during a boot process of the electronic device; the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is completed; the FW agent checking the response during a subsequent boot process of the electronic device; and the FW agent allowing or halting completion of the subsequent boot process depending on whether the response is correct or incorrect, respectively; wherein the electronic device accepts one or more inputs from a user between the end of the boot process and the beginning of the subsequent boot process.
2. 2. The method of claim 1, wherein the OS agent, prior to writing the response, the FW agent checking during the boot process that the previous response in the mailbox is correct; the FW agent allowing the boot process to complete; The method includes:
3. 2. The method of claim 1, after completion of the subsequent boot process: The FW agent verifies that no response is present in the mailbox during another boot process of the electronic device; and the FW agent interrupting completion of another boot process; The method includes:
4. 2. The method of claim 1, after completion of the subsequent boot process: the FW agent determining during another subsequent boot process of the electronic device that no response is present in the mailbox; the FW agent checking the number of consecutive times that the electronic device has initiated a boot without a response in the mailbox; and the FW agent allowing or aborting the completion of the further subsequent boot process depending on whether the number of times has not met or reached a certain limit, respectively; The method includes:
5. 2. The method of claim 1, after completion of the subsequent boot process: the FW agent receiving the correct passcode; and In response, the FW agent allows the subsequent boot process to complete; The method includes:
6. 2. The method of claim 1, further comprising the step of the OS agent obtaining the response from a server.
7. 2. The method of claim 1, wherein the OS agent, prior to initiating the subsequent boot process, comprises: As soon as the OS begins operation; or Upon receiving said response from the server; or At the end of the session; or During the shutdown procedure of said electronic device The method includes the step of writing the response.
8. 13. The method of claim 1 : the FW agent generating a public and private key pair; The FW agent encrypts the private key and transmits it to a server; the OS Agent receiving the decrypted private key from the server; and the OS Agent storing the decrypted private key; The method includes:
9. 9. The method of claim 8, the FW agent encrypting the challenge with the public key; the OS Agent decrypting the challenge using the private key; the OS Agent signing the response with the private key; the electronic device initiating the subsequent boot process; and the FW agent verifying a signature of the signed response during the subsequent boot process; The method includes:
10. 13. The method of claim 1 : The FW agent receives a public key of a key pair from a server; and receiving, by the OS Agent, a private key of the key pair from the server; The method includes:
11. 11. The method of claim 10, the FW agent encrypting the challenge with the public key; the OS Agent decrypting the challenge using the private key; the OS Agent signing the response with the private key; the electronic device initiating the subsequent boot process; and the FW agent verifying a signature of the signed response during the subsequent boot process; The method includes:
12. 2. The method of claim 1, including the step of configuring the electronic device prior to the boot process so that a correct response is in the mailbox.
13. 1. An electronic device including a processor and a non-transitory computer readable storage medium, the storage medium storing a firmware (FW) agent and an operating system (OS) agent as computer readable instructions that, when executed by the processor, perform: the FW agent generating a challenge for the OS agent during a boot process of the electronic device; the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is completed; the FW agent checking the response during a subsequent boot process of the electronic device; and the FW agent allowing or halting completion of the subsequent boot process depending on whether the response is correct or incorrect, respectively; and wherein the electronic device accepts one or more inputs from a user between the end of the boot process and the beginning of the subsequent boot process.
14. 14. The electronic device of claim 13, wherein the mailbox is a Unified Extensible Firmware Interface (UEFI) variable, a file in an Extensible Firmware Interface (EFI) partition, a hardware register, or a Trusted Platform Module (TPM) memory.
15. 14. The electronic device of claim 13, wherein the computer readable instructions, when executed by the processor, obtaining the response from the server; or generating the response using a private key of a key pair, the FW agent having a public key for the key pair; The electronic device causes the OS agent to execute the above.
16. A system including a server and an electronic device, the electronic device including a processor and a non-transitory computer readable storage medium, the storage medium storing a firmware (FW) agent and an operating system (OS) agent as computer readable instructions, the instructions, when executed by the processor, perform: the FW agent generating a challenge for the OS agent during a boot process of the electronic device; the OS Agent obtaining a response from the server; or the OS agent writing a response to the challenge to a mailbox of the electronic device after the boot process is completed; the FW agent checking the response during a subsequent boot process of the electronic device; and the FW agent allowing or halting completion of the subsequent boot process depending on whether the response is correct or incorrect, respectively; and wherein the electronic device accepts one or more inputs from a user between the end of the boot process and the beginning of the subsequent boot process.