Patent Description:
The document <CIT> discloses a system and method of operating a device to securely update the control firmware controlling the device. The document <CIT> discloses an integrated circuit provisioned for asset protection which has a primary circuit portion that can be selectively disabled and enabled via an operability control input. The document <CIT> discloses a method that persistently locks the platform firmware storage location in response to the platform firmware update mechanism switching to a platform firmware armoring technology. The document <CIT> discloses a secure firmware update method which includes receiving a firmware update image.

Examples are disclosed that relate to securing a firmware installation/update process on a USB input device. One disclosed example provides a method comprising receiving, from a host computing system, an unlock request to change a firmware lock state of a controller of the USB input device from a locked state to an unlocked state, and determining whether the unlock request is valid or invalid. When the unlock request is valid, the method comprises updating the firmware lock state from the locked state to the unlocked state and sending a process completion message to the host computing system. When the unlock request is invalid, the method comprises sending the process completion message to the host computing system without updating the firmware lock state. The method also comprises receiving, from the host computing system, a firmware update request, determining whether the firmware lock state is in the locked state or the unlocked state, receiving, from the host computing system, a firmware payload, authenticating the firmware payload, and when the firmware lock state is determined to be in the unlocked state and when the firmware payload is authenticated, then installing the firmware payload.

Some USB input devices may accept and install a firmware update without performing a security protocol to verify/authenticate the firmware update. This may be acceptable for USB input devices with limited performance and feature capabilities. However, some USB input devices, such as cameras, microphone arrays, and touch sensors, may be used for biometric user authentication via methods such as facial recognition, voice recognition/commands, and/or fingerprint detection. Where the firmware of such input devices is not secured, the input device may be vulnerable to the installation of malicious firmware to access data input via such USB input devices. For example, malicious firmware code may be used to access IR video frames obtained by an IR camera, or voice samples acquired by a microphone. Further, USB input device manufacturers may provide unsecure tools that may be downloaded on public networks for performing firmware updates, thus facilitating such malicious firmware installation.

One potential solution that may help prevent unauthorized firmware updates on a USB input device involves modifying hardware of the USB input device and/or a computing device with which the USB input device is integrated. For example, a dedicated general-purpose input output (GPIO) pin of a central processing unit (CPU) of the computing device may be allocated for connecting to the USB input device. The dedicated GPIO pin may be toggled to lock the Serial Peripheral Interface (SPI) flash, and may thereby disable in-field firmware updates for the controller of the USB input device. However, this design-level hardware change requires an available GPIO pin for a specific processor. Further, implementing this hardware-level change involves a firmware change to the basic input/output system (BIOS) code, as well as additional security around the pin control logic, e.g. such that an end user is unable to toggle the GPIO pin. When different product lines utilize a same USB device but different central processing devices, the same GPIO pin may not be compatible with each processing device. Further, each SoC may write BIOS code in a different manner, resulting in deploying different variants of firmware for each type of processing device. Such changes may increase design and manufacturing costs of a computing device.

Thus, examples are disclosed that relate to securing a firmware installation/update process using techniques that are not specific to the processing hardware of a computing device with which the USB input device is integrated. Briefly, a USB input device controller comprises firmware that includes a lock/unlock state. When the firmware is to be updated (e.g. during manufacturing), the controller receives a lock/unlock request from a host, determines a validity of a lock/unlock request, and updates its firmware lock state-a state indicative of being able or unable to modify firmware code-when the lock/unlock request is determined to be valid. When a firmware update request is received, the USB input device controller verifies its current lock state to determine whether the USB input device controller is in an unlocked state and thus able to accept a firmware update. Further, the USB input device controller verifies/authenticates data that accompanies a firmware payload, to determine whether to write the firmware payload. This may help to prevent accidental or malicious firmware payloads from being installed on a controller of a USB input device, which may help to increase the security of a USB input device used for biometric data sensing. Further, by implementing a firmware/software solution for a controller of a USB input device, the disclosed examples are not dependent upon any specific hardware configuration, and do not entail supporting the UEFI capsule framework and BIOS customization overhead associated with controlling GPIOs on a particular platform.

Prior to discussing these examples, <FIG> depicts an example computing device <NUM> in the form of a laptop computer having a camera <NUM>. The computing device <NUM> comprises a lid <NUM> coupled to a main body <NUM> of the computing device <NUM> via a hinge <NUM> or other rotatable/flexible connection. In this configuration, a motherboard of the computing device <NUM> may reside inside the main body <NUM>, whereas the camera <NUM> resides in the lid <NUM> above a display <NUM>. Extending mobile industry processor interface (MIPI) trace lines from the motherboard in the main body <NUM> to the camera <NUM> may be infeasible, e.g. due to the length of the trace lines or the hinge coupling. Thus, the camera <NUM> may take the form of a USB camera that comprises a controller <NUM> connected to the computing device <NUM> via a USB connection.

While described as a USB camera <NUM> in this example, the security examples described herein may be used with any suitable sensor/input device. Examples include image sensors (RGB, IR, depth), touch sensors, and audio sensors (microphones, microphone arrays). Further, while depicted as a laptop computer in <FIG>, any other suitable computing device may be used in other examples. Examples of computing devices include mobile computing devices (tablets, head-mounted devices, smartphones), desktop computing devices, display devices with integrated USB sensors (e.g. monitors, televisions), medical devices, etc..

Controller <NUM> may represent any suitable type of controller. In some examples, the type of controller used may depend upon the type of sensor(s) to which the controller <NUM> is coupled. Examples of controller <NUM> include microcontrollers (MCUs), digital signal processors (DSPs), and image signal processors (ISPs).

When manufacturing the computing device <NUM>, a manufacturer may use a software tool provided by the USB input device manufacturer to install/update firmware on the USB device. <FIG> depicts a method <NUM> of installing/updating firmware using such a firmware update tool. Method <NUM> may be implemented as stored instructions executable by logic residing on a host <NUM> and on a USB input device <NUM>. In some instances, the host <NUM> comprises a computing system local to a manufacturing vendor site (e.g. a PC, a server computer, and/or another computing system). In other examples, the host <NUM> may comprise the computing device (e.g. computing device <NUM> in <FIG>) with which the USB input device is integrated.

At <NUM>, the host <NUM> sends a firmware update request to the USB input device <NUM>. In response, the USB input device <NUM> enters an update mode, as indicated at <NUM>. The USB input device <NUM> may optionally send a message to the host <NUM> indicating that the USB input device <NUM> is in the update mode and ready to receive a firmware update, as indicated by arrow <NUM>. At <NUM>, the host <NUM> begins the firmware installation process by sending new firmware code to the USB input device <NUM>. The USB input device <NUM> writes the firmware code received, as indicated at <NUM>.

In method <NUM>, the USB input device <NUM> automatically accepts the firmware update request received from the host <NUM>, and writes the firmware code received, without determining whether the update request and/or the firmware code are valid. In this manner, the USB input device <NUM> may automatically accept and write a malicious/corrupt firmware binary.

Thus, <FIG> is a flow diagram illustrating an example of a more secure method <NUM> of installing/updating firmware. As indicated by the dashed lines surrounding the host <NUM> and the USB input device <NUM> in <FIG>, aspects of method <NUM> may be implemented as stored instructions executable by logic residing on the host <NUM> and as stored instructions executable by logic residing on the USB input device <NUM>. In some instances, the USB input device <NUM> may leverage capabilities of an existing extension unit (XU) framework to implement the security protocols described herein. In a more specific example, when the USB input device <NUM> comprises a USB camera, an extension to the USB Video Class specification, such as MS_CAMERA_CONTROL_XU available from Microsoft Corp. of Redmond, WA, may be used to implement aspects of method <NUM>. In other examples, rather than leveraging capabilities of an XU, a USB input device may include any other suitable identifier built into the firmware of its controller, and a host-side tool may use that identifier to communicate with the firmware of the controller.

Similar to method <NUM>, method <NUM> begins at <NUM>, where the host <NUM> sends a firmware update request to the USB input device <NUM>. A vendor-provided software tool may be used to perform step <NUM>, but the USB input device does not automatically enter a firmware update mode upon receiving the firmware update request. Rather than automatically entering the firmware update mode, the USB input device <NUM> determines whether its controller is able to receive a firmware update by checking, at <NUM>, its current firmware lock state. In some examples, the USB input device <NUM> utilizes a state machine, and a lock variable configured within non-volatile memory at a predetermined offset is indicative of the current firmware lock state of the USB input device <NUM>. In other examples, a lock variable may be stored in volatile memory and thus may be valid only until a device shutdown.

At <NUM>, the USB input device <NUM> determines whether the firmware lock is enabled or not enabled. If firmware lock is not enabled (in unlocked state), then method <NUM> proceeds to <NUM>, where the controller of the USB input device <NUM> is set to a firmware update mode. Method <NUM> then proceeds to <NUM>, where the USB input device <NUM> sends a response message to the host <NUM>. If firmware lock is enabled (in locked state), then process <NUM> proceeds to <NUM>, without setting the USB input device <NUM> to a firmware update mode. In some examples, the response message may take the form of a "process completion" message that indicates, to the host <NUM>, that the firmware update request was received and acknowledged by the USB input device <NUM> but does not necessarily indicate an outcome of the firmware update request. In other examples, the USB input device <NUM> may send information indicating whether the firmware update request is accepted or rejected, and/or whether the firmware is in a locked state or unlocked state, with the process completion message. In some examples, the response message may be abstract in that it is interpretable by an expected host <NUM> but not interpretable by other users/devices.

At <NUM>, the host <NUM> may optionally determine whether the firmware update request was accepted by the USB input device <NUM>, e.g. based upon whether the response message received included such information. When the host <NUM> determines that the request is not accepted, the host <NUM> may report an error, as indicated at <NUM>. When the host <NUM> determines that the request was accepted, or when the host does not perform the determination step <NUM>, method <NUM> may proceed to <NUM>. At <NUM>, the host <NUM> sends, to the USB input device <NUM>, a payload comprising new firmware.

At <NUM>, the USB input device <NUM> authenticates firmware data of the payload received. When the controller is in the locked state and/or when the firmware data cannot be authenticated, the device <NUM> does not write the new firmware. When the controller is in the unlocked state and the firmware data is authenticated, the device <NUM> writes the new firmware, as indicated at <NUM>.

Method <NUM> may be used in a secured manufacturing environment to securely install/update firmware on a controller of a USB input device during assembly of a computing device comprising a USB input device. Method <NUM> also may be used to securely perform in-field firmware updates, where a device manufacturer enables such in-field updates.

<FIG> depicts an example lock/unlock method <NUM> usable to change a lock state of the USB input device <NUM> prior to sending a firmware update request (e.g. step <NUM> in <FIG>). Method <NUM> may be used, for example, during development and testing stages, or during manufacturing, to upgrade or downgrade firmware on a controller to a different version of the firmware. In some instances, when the firmware is production-ready (e.g. no further upgrades/downgrades), the firmware lock state may be set to a default locked state to disable in-field firmware updates. Aspects of method <NUM> may be implemented via a lock/unlock software tool private to a developer or a manufacturer of a computing device with which a USB input device is integrated.

At <NUM>, the host <NUM> sends a lock/unlock request to the USB input device <NUM> using a lock/unlock tool that is private and inaccessible by devices/users other than an authorized host <NUM>. The lock/unlock request may comprise a payload that includes, for example, an identifier of a custom control XU that is private to the manufacturer and/or designer, and a checksum that the firmware can verify.

When the ISP firmware receives the XU request, it validates the request at <NUM>. For example, the lock/unlock request may be encrypted via a key specific to a particular firmware version on the controller (such that key1 corresponds to version1 of the firmware, key2 corresponds to version2, etc.). The USB input device <NUM> may decrypt the request via a key baked into the firmware of its controller based upon the particular firmware version installed. Once the lock/unlock request is decrypted, the custom control XU identifier (or other suitable identifier) may be validated at <NUM>. Further, a hash of lock/unlock request may be computed and compared to an expected hash, as indicated at <NUM>.

At <NUM>, the USB input device <NUM> determines whether to accept the lock/unlock request. When the USB input device <NUM> confirms that the identifier received matches the expected identifier, and the hash check succeeds, then the firmware lock state is updated from the locked state to the unlocked state at <NUM>. In some examples, the USB input device <NUM> stores a lock variable in internal non-volatile memory of the USB input device <NUM>. In other examples, the USB input device <NUM> may store the lock variable in a volatile memory location, such as random-access memory (RAM), such that the lock variable is only valid until a device reset.

After updating the lock state, method <NUM> proceeds to <NUM>, where the USB input device <NUM> returns a request acknowledgement to the host <NUM>. Likewise, when the identifier received does not match an expected identifier, and/or when the hash verification fails, method <NUM> proceeds to <NUM> without updating the lock state.

In some examples, the request acknowledgement sent at <NUM> may not include an indication as to whether the lock/unlock request was accepted by the USB input device <NUM>, which may help to obfuscate (e.g. to a hacker/malicious actor) whether the lock/unlock request validation failed. In other examples, the USB input device <NUM> may send information indicating success or failure of the lock/unlock request with the request acknowledgement. The information may include a pass/fail indication, and/or may indicate the current lock state. At <NUM>, the host proceeds with device operations, for example, by sending a firmware update request to the USB input device <NUM>, as described above with reference to method <NUM>.

<FIG> depicts an example command sequence <NUM> between the host <NUM> and a USB input device interface <NUM> that is usable to send new firmware to the USB input device (step <NUM> in <FIG>), authenticate firmware data (step <NUM> in <FIG>), and optionally write the new firmware (step <NUM> in <FIG>).

As mentioned above, the host <NUM> initiates a firmware update by sending a firmware update request (e.g. a "begin firmware update" USB command), to the USB input device. The USB input device receives this request and checks its current lock state to determine whether firmware lock is enabled or disabled, e.g. based on a state of a lock variable stored in memory. After determining whether the current lock state is in the unlocked state or the locked state, the USB input device sends a response message to the host <NUM>.

After receiving the response message, the host <NUM> deploys new firmware by sending a firmware payload to the device interface <NUM>, as indicated at <NUM>. In some examples, the firmware payload may take the form of a signed binary blob. As indicated at <NUM>, the USB input device authenticates data of the firmware payload by decrypting the firmware payload, generating a hash of the firmware payload, and comparing the hash to an expected hash, for example, by matching a checksum of the generated hash to the checksum of the expected hash. In addition to verifying a hash of the firmware payload, the USB input device verifies whether the signature of the firmware payload matches an expected/authorized signature, as indicated at <NUM>. In some instances, the USB input device expects the firmware payload to be signed with a trusted root certificate or other private signature accessible by only an authorized/trusted host.

Once the firmware payload is authenticated, the device writes the firmware payload to memory <NUM>. As one example, the USB input device interface <NUM> sends a command to erase flash memory (<NUM>), receives a confirmation of blank data (<NUM>), writes the firmware payload to the flash memory (<NUM>), sends a read request to read the firmware payload (<NUM>), receives payload data from the memory <NUM> (<NUM>), verifies the written payload (<NUM>), and sends a finalizing packet (<NUM>) to the memory <NUM>.

The firmware payload written to memory comprises the lock variable in a locked state. Thus, the writing of the updated firmware to the USB device re-locks the USB device. This prevents any further updates to the firmware of the USB input device until another lock/unlock request is successfully performed. Further, the firmware payload supplies the USB input device with a new key usable to unlock the firmware lock state of the new/current firmware version, as the key usable to unlock the prior version of the firmware (prior to writing the new firmware payload) may not be used to unlock the new/current version of the firmware.

The examples described herein provide multiple layers of security for firmware installation/update on a USB input device, and thereby may help to prevent the installation of malicious firmware on such a device.

The logic machine <NUM> may include one or more processors configured to execute software instructions.

The term "program" may be used to describe an aspect of computing system <NUM> implemented to perform a particular function. In some cases, a program may be instantiated via logic machine <NUM> executing instructions held by storage machine <NUM>. It will be understood that different programs may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same program may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The term "program" may encompass individual or groups of executable files, data files, libraries, drivers, scripts, database records, etc..

Another example provides, on a Universal Serial Bus (USB) input device, a method comprising receiving, from a host computing system, an unlock request to change a firmware lock state of a controller of the USB input device from a locked state to an unlocked state, determining whether the unlock request is valid or invalid, when the unlock request is valid, updating the firmware lock state from the locked state to the unlocked state and sending a process completion message to the host computing system, when the unlock request is invalid, sending the process completion message to the host computing system without updating the firmware lock state, receiving, from the host computing system, a firmware update request, determining whether the firmware lock state is in the locked state or the unlocked state, receiving, from the host computing system, a firmware payload, authenticating data of the firmware payload, and when the firmware lock state is determined to be in the unlocked state, and when the data of the firmware payload is authenticated, then installing the firmware payload. In such an example, determining whether the unlock request is valid or invalid may additionally or alternatively comprise comparing an identifier of the unlock request to an expected identifier. In such an example, determining whether the unlock request is valid or invalid may additionally or alternatively comprise decrypting the unlock request and comparing a hash of the unlock request to an expected hash. In such an example, sending the process completion message to the host computing system may additionally or alternatively comprise sending information indicating the firmware lock state with the process completion message. In such an example, authenticating the data of the firmware payload may additionally or alternatively comprise verifying a hash of the firmware payload. In such an example, installing the firmware payload may additionally or alternatively comprise updating the firmware lock state to the locked state. In such an example, the method may additionally or alternatively comprise, after determining whether the firmware lock state is in the locked state or the unlocked state, sending a response message to the host computing system. In such an example, sending the response message may additionally or alternatively comprise, when the firmware lock state is determined to be in the locked state, sending a response message rejecting the firmware update request.

Another example provides a USB input device comprising a controller configured to receive, from a host computing system, an unlock request to change a firmware lock state from a locked state to an unlocked state, determine whether the unlock request is valid or invalid, when the unlock request is valid, update the firmware lock state from the locked state to the unlocked state and send a process completion message to the host computing system, when the unlock request is invalid, send the process completion message to the host computing system without updating the firmware lock state, receive, from the host computing system, a firmware update request, determine whether the firmware lock state is in the locked state or the unlocked state, receive, from the host computing system, a firmware payload, authenticate data of the firmware payload, and when the firmware lock state is determined to be in the unlocked state, and when the data of the firmware payload is authenticated, then install the firmware payload. In such an example, the USB input device may additionally or alternatively comprise a biometric input device. In such an example, the USB input device may additionally or alternatively be configured to, after determining whether the firmware lock state is in the locked state or the unlocked state, send a response message to the host computing system. In such an example, the USB input device may additionally or alternatively be configured to, when the firmware lock state is determined to be in the locked state, send, to the host computing system, a response message rejecting the firmware update request. In such an example, the USB input device may additionally or alternatively be configured to determine whether the unlock request is valid or invalid by comparing an identifier of the unlock request to an expected identifier. In such an example, the USB input device may additionally or alternatively be configured to determine whether the unlock request is valid or invalid by decrypting the unlock request and comparing a hash of the unlock request to an expected hash. In such an example, the USB input device may additionally or alternatively be configured to send the process completion message to the host computing system by sending information indicating the firmware lock state with the process completion message. In such an example, the USB input device may additionally or alternatively be configured to authenticate the data of the firmware payload by verifying a hash of the firmware payload. In such an example, the USB input device may additionally or alternatively be configured to, after installing the firmware payload, update the firmware lock state to the locked state. In such an example, the USB input device may additionally or alternatively be connected to a motherboard of a laptop computer via a USB connection.

Another example provides a method for installing firmware on a controller of a USB input device, the method comprising sending, to the controller, an unlock request for changing a firmware lock state of the controller from a locked state to an unlocked state, receiving, from the controller, a process completion message, sending, to the controller, a request to install the firmware on the controller, receiving, from the controller, a message responsive to the request to install the firmware, sending, to the controller, a firmware payload, when the unlock request and a verification of the firmware payload are successful, then receiving a confirmation of firmware installation, and when the unlock request is not successful and/or when the verification of the firmware payload is not successful, then receiving a message regarding a failure to complete the firmware installation. In such an example, sending the firmware payload may additionally or alternatively comprise sending a signed binary.

Claim 1:
On a Universal Serial Bus ,USB, input device comprising a controller, a method (<NUM>, <NUM>) for securely updating firmware of the controller comprising:
receiving, from a host computing system (<NUM>; <NUM>, <NUM>) separate from the USB device and coupled to the USB device for providing a firmware update thereto, an unlock request to change a firmware lock state of the controller (<NUM>) of the USB input device (<NUM>, <NUM>) from a locked state to an unlocked state;
determining (<NUM>; <NUM>, <NUM>, <NUM>) whether the unlock request is valid or invalid; when the unlock request is valid, updating the firmware lock state from the locked state to the unlocked state and sending (<NUM>) a process completion message to the host computing system;
when the unlock request is invalid (<NUM>), sending (<NUM>) the process completion message to the host computing system without updating the firmware lock state;
receiving, from the host computing system, a firmware update request (<NUM>);
determining (<NUM>, <NUM>) whether the firmware lock state is in the locked state or the unlocked state;
receiving (<NUM>), from the host computing system (<NUM>, <NUM>), a firmware payload;
authenticating (<NUM>, <NUM>, <NUM>) data of the firmware payload; and
when the firmware lock state is determined to be in the unlocked state, and when the data of the firmware payload is authenticated, installing (<NUM>, <NUM>) the firmware payload.