Light equipment firmware verification method, device, equipment, medium and product

Abstract

The present invention discloses a method, apparatus, device, medium and product for verifying firmware of a light device. The method is executed by a light device and includes: sending a target soft bus connection request to a rich device after the light device is started, so that the rich device establishes a connection with the light device according to the target soft bus connection request; sending a credential application request to the rich device, so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is a credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device; receiving the target credential sent by the rich device; verifying the target credential, and if the verification is successful, controlling the firmware to run. Through the technical solution of the present invention, a connection channel between the rich device and the light device can be established based on the soft bus, the target credential can be securely transferred, and the firmware of the light device can be verified through the target credential, thereby realizing firmware rollback protection for the light device.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular to a method, apparatus, device, medium, and product for verifying firmware of a lightweight device. Background Art

[0002] As devices are updated, even if the update process is completely secure and reliable, attackers can still flash older versions of firmware with security flaws to the device, reboot it, and exploit the flaws to attack the device. Rollback protection is a protective measure to prevent such attacks.

[0003] A common rollback protection solution is to record the latest version of the firmware in a tamper-proof storage space (such as a one-time programming space), compare the running version number with the latest version number when starting the device, and refuse to start if the running version number is lower than the latest version number, thereby achieving the purpose of firmware rollback prevention.

[0004] However, light devices usually have extremely limited hardware resources and no or only limited tamper-proof storage space, which makes it impossible to perform firmware verification on light devices or the number of achievable verifications is small, making it difficult to implement firmware rollback protection. Summary of the Invention

[0005] The embodiments of the present invention provide a method, apparatus, device, medium and product for verifying firmware of a light device, which can solve the problem that firmware verification cannot be performed or the number of achievable verifications is small due to the light device having no or only limited tamper-proof storage space, making it difficult to implement firmware rollback protection.

[0006] According to one aspect of the present invention, a method for verifying firmware of a light device is provided, which is executed by a light device. The method includes:

[0007] After the light device is started, the light device sends a target soft bus connection request to the rich device, so that the rich device establishes a connection with the light device according to the target soft bus connection request;

[0008] Sending a credential application request to the rich device so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device based on the credential update request sent by the light device after the light device completes the update based on the firmware update data sent by the rich device;

[0009] receiving a target credential sent by the rich device;

[0010] The target certificate is verified, and if the verification is successful, the firmware is controlled to run.

[0011] According to one aspect of the present invention, a method for verifying firmware of a light device is provided, which is performed by a rich device. The method includes:

[0012] Receive a target soft bus connection request sent by a light device;

[0013] Establishing a connection with the light device according to the target soft bus connection request;

[0014] Receive a credential application request sent by a light device;

[0015] The target credential is sent to the light device according to the credential application request, so that the light device verifies according to the target credential, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0016] According to another aspect of the present invention, a light device firmware verification apparatus is provided, which is configured in a light device, and the light device firmware verification apparatus includes:

[0017] a connection request sending module, configured to send a target soft bus connection request to the rich device after the light device is started, so that the rich device establishes a connection with the light device according to the target soft bus connection request;

[0018] an application request sending module, configured to send a credential application request to the rich device, so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device;

[0019] a target credential receiving module, configured to receive a target credential sent by a rich device;

[0020] The target credential verification module is used to verify the target credential and control the firmware to run if the verification is successful.

[0021] According to another aspect of the present invention, a light device firmware verification apparatus is provided, which is configured in a rich device, and the light device firmware verification apparatus includes:

[0022] A connection request receiving module, configured to receive a target soft bus connection request sent by a light device;

[0023] A connection request establishing module, configured to establish a connection with the light device according to the target soft bus connection request;

[0024] An application request receiving module, configured to receive a credential application request sent by a light device;

[0025] The target credential sending module is used to send the target credential to the light device according to the credential application request, so that the light device can verify it according to the target credential, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0026] According to another aspect of the present invention, an electronic device is provided, comprising:

[0027] at least one processor; and

[0028] a memory communicatively connected to the at least one processor; wherein,

[0029] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the light device firmware verification method described in any embodiment of the present invention.

[0030] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the light device firmware verification method described in any embodiment of the present invention when executed.

[0031] According to another aspect of the present invention, a computer program product is provided. When the computer program is executed by a processor, the computer program implements the light device firmware verification method as described in any one of the embodiments of the present invention.

[0032] The embodiment of the present invention sends a target soft bus connection request to the rich device after the light device is started, so that the rich device establishes a connection with the light device according to the target soft bus connection request; sends a credential application request to the rich device, so that the rich device obtains the target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update of the firmware update data sent by the rich device; receives the target credential sent by the rich device; verifies the target credential, and if the verification is successful, controls the firmware to run, thereby solving the problem that the light device has no or only limited tamper-proof storage space, resulting in the inability to perform firmware verification or the small number of achievable verifications, making it difficult to implement firmware rollback protection. A connection channel between the rich device and the light device can be established based on the soft bus, and the target credential can be securely transferred between the light device and the rich device through the connection channel. The light device verifies the light device's firmware based on the target credential, and controls the firmware to run after the verification is successful, thereby implementing firmware rollback protection for the light device.

[0033] It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present invention, nor is it intended to limit the scope of the present invention. Other features of the present invention will become readily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments. It should be understood that the following drawings only illustrate certain embodiments of the present invention and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without paying any creative work.

[0035] Figure 1 This is a flowchart of a light device firmware verification method in embodiment 1 of the present invention;

[0036] Figure 2 This is a schematic diagram of a target credential in the first embodiment of the present invention;

[0037] Figure 3 This is a flow chart of a light device verifying a target credential in the first embodiment of the present invention;

[0038] Figure 4 This is a flowchart of a light device firmware verification method in Embodiment 2 of the present invention;

[0039] Figure 5 This is a framework diagram of a light device firmware verification in the second embodiment of the present invention;

[0040] Figure 6 This is a schematic diagram of updating and starting firmware for a light device in the second embodiment of the present invention;

[0041] Figure 7 This is a flow chart of a verification of a credential to be verified in the second embodiment of the present invention;

[0042] Figure 8 This is a structural diagram of a light device firmware verification device in the third embodiment of the present invention;

[0043] Figure 9 This is a structural diagram of a light device firmware verification device in a fourth embodiment of the present invention;

[0044] Figure 10 It is a structural diagram of an electronic device in embodiment 5 of the present invention. DETAILED DESCRIPTION

[0045] In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the embodiments described are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of the present invention.

[0046] It should be noted that the terms "first", "second", etc. in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the numbers used in this way can be interchanged where appropriate so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0047] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0048] Example 1

[0049] Figure 1 This is a flowchart of a light device firmware verification method in the first embodiment of the present invention. This embodiment is applicable to the case where firmware rollback protection is implemented after firmware verification of a light device. This method can be executed by the light device firmware verification device in the third embodiment of the present invention. The device can be implemented in software and / or hardware. Figure 1 As shown, the method is executed by a light device and specifically includes the following steps:

[0050] S110 , after the light device is started, sends a target soft bus connection request to the rich device, so that the rich device establishes a connection with the light device according to the target soft bus connection request.

[0051] Light devices are those that use microcontroller processors, such as sensor devices using Arm Cortex-M microcontroller processors. These devices typically have extremely limited hardware resources and no or limited tamper-resistant storage. Tamper-resistant storage typically includes OTP / EFuse (One-Time Programmable / Electric-Fuse) and TPM / TCM (Trusted Platform Module / Trusted Cryptography Module). OTP / EFuse is a one-time programmable memory with good tamper-resistant properties, but has limited space for recording data. TPM / TCM is a trusted module that typically provides secure storage and trusted computing capabilities. TPM / TCMs with software tamper-resistant design have good tamper-resistant properties. Rich devices are those that use application processors, such as terminal devices using Arm Cortex-A application processors. These devices typically have abundant hardware resources and ample tamper-resistant storage.

[0052] Among them, the target soft bus connection request is the soft bus connection request sent by the light device to the rich device after startup. The soft bus is the Openharmony distributed soft bus (network cable, WiFi, Bluetooth, Star Flash, etc.), which is used to achieve unified distributed communication management capabilities between near-field devices and provide link-independent device discovery, connection, networking and transmission capabilities.

[0053] Specifically, after the light device is started, a target soft bus connection request is sent to the rich device so that the rich device establishes a connection with the light device according to the target soft bus connection request. The method can be: sending a target soft bus connection request to the rich device when the light device is started, or sending a target soft bus connection request to the rich device when the light device is restarted after updating the firmware. After receiving the target soft bus connection request, the rich device establishes a soft bus connection with the light device according to the light device identifier carried in the target soft bus connection request.

[0054] S120, sending a credential application request to the rich device so that the rich device obtains the target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0055] The target credential is the trusted credential returned by the rich device after receiving the credential application request from the light device. Verification by the target credential can ensure the security of the light device firmware operation.

[0056] Specifically, the method of sending a credential application request to the rich device so that the rich device obtains the target credential corresponding to the light device can be: the light device sends a credential application request to the rich device, and after the rich device receives the credential application request, the rich device queries the credential set stored in the rich device according to the credential application request to obtain the target credential corresponding to the light device, wherein the target credential is the light device that first updates the firmware according to the firmware update data sent by the rich device, and after the update is completed, the light device sends a credential application request to the rich device again, and the rich device determines the target credential according to the credential application request and sends it to the light device.

[0057] S130: Receive the target certificate sent by the rich device.

[0058] Specifically, after sending a credential application request to the rich device, the light device receives the target credential sent by the rich device.

[0059] S140, verify the target certificate, and if the verification is successful, control the firmware to run.

[0060] The target credential may include a target security version number of the firmware corresponding to each firmware identifier in the light device and a target software version number of the firmware corresponding to each firmware identifier.

[0061] Specifically, the target credential is verified. If the verification is successful, the method for controlling the firmware operation can be: if the current security version number of the firmware corresponding to each firmware identifier in the light device is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, and the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, then the verification is successful, the light device controls the firmware operation, and ensures the safe startup of the light device.

[0062] Optionally, after the light device is started and before sending the target soft bus connection request to the rich device, the following steps may also be included:

[0063] After the light device is pre-started, sending an initial soft bus connection request to the rich device, so that the rich device establishes a connection with the light device according to the initial soft bus connection request;

[0064] receiving firmware update data sent by the rich device, and performing firmware update according to the firmware update data;

[0065] After the update is completed, a credential update request is sent to the rich device, so that the rich device determines a target credential according to the credential update request, and generates an update completion instruction after determining the target credential;

[0066] After receiving the update completion instruction, the connection between the light device and the rich device is controlled to be disconnected.

[0067] Among them, light device pre-boot can be understood as the startup of a light device, which is a necessary startup process for a light device to perform a firmware update. The initial soft bus connection request is a soft bus connection request sent by the light device to the rich device during pre-boot to update the firmware. The firmware update data is the data packet of the firmware to be updated in the light device, and the firmware update data may include at least one firmware data packet to be updated. The credential update request is a request generated by the light device after the firmware update is completed, requesting the rich device to update the credentials. The update completion instruction is a completion instruction generated by the rich device after the credential update is completed.

[0068] Specifically, after the light device is pre-started, an initial soft bus connection request is sent to the rich device so that the rich device establishes a connection with the light device according to the initial soft bus connection request. The method can be: after the light device is pre-started, an initial soft bus connection request is sent to the rich device, and after receiving the initial soft bus connection request, the rich device establishes a soft bus connection with the light device according to the light device identifier carried in the initial soft bus connection request.

[0069] Specifically, the method of receiving firmware update data sent by the rich device and performing firmware update according to the firmware update data can be: after the rich device establishes a connection with the light device, the firmware update data is sent to the light device, the light device receives the firmware update data sent by the rich device, and then the light device updates the firmware in the light device according to the firmware update data.

[0070] Specifically, after the update is completed, a credential update request is sent to the rich device so that the rich device determines the target credential according to the credential update request, and generates an update completion instruction after determining the target credential. The method can be: after the firmware update of the light device is completed, the light device sends a credential update request to the rich device, and after receiving the credential update request, the rich device determines the target credential according to the credential update request. After determining the target credential, the rich device generates an update completion instruction and sends the update completion instruction to the light device.

[0071] Specifically, after receiving the update completion instruction, the method for controlling the disconnection of the connection between the light device and the rich device can be: the light device receives the update completion instruction sent by the rich device, and disconnects the connection between the light device and the rich device according to the update completion instruction, so that the light device starts after the firmware update is completed and sends a target soft bus connection request to the rich device.

[0072] By establishing a secure connection between the light device and the rich device based on the soft bus before the light device performs a firmware update, and obtaining the firmware update data sent by the rich device to perform a firmware update, the anti-tampering area space of the light device is saved, and after the light device is updated, a credential update request is sent to the rich device, so that the rich device determines the target credential based on the credential update request, and generates an update completion instruction after determining the target credential. When the light device receives the update completion instruction, it disconnects the soft bus connection with the rich device, which facilitates the light device to restart after the update is completed and reconnect to the rich device through the soft bus. Without increasing the hardware cost of the light device, it ensures that the firmware of all light devices in the same distributed soft bus networking environment meets security expectations and is trustworthy.

[0073] Optionally, the firmware update data carries an identifier of the firmware to be updated and a security version number of the firmware to be updated corresponding to the identifier of the firmware to be updated;

[0074] Accordingly, performing firmware update according to the firmware update data includes:

[0075] Obtaining the current security version number of the firmware corresponding to the firmware identifier to be updated according to the firmware identifier to be updated;

[0076] If the security version number to be updated is greater than or equal to the current security version number, the firmware is updated.

[0077] Among them, the current security version number of the firmware corresponding to the firmware identifier is the security version number currently in use in the firmware of the light device, the firmware identifier to be updated is the identification information of the firmware to be updated, and the security version number to be updated of the firmware corresponding to the firmware identifier to be updated is the expected updated security version number corresponding to the firmware to be updated.

[0078] Specifically, the method for obtaining the current security version number of the firmware corresponding to the firmware identifier to be updated based on the firmware identifier to be updated can be: after the light device obtains the firmware update data of the rich device, the firmware update data carries the firmware identifier to be updated, and the light device obtains the current security version number of the firmware corresponding to the firmware identifier to be updated in the light device based on the firmware identifier to be updated.

[0079] Specifically, if the security version number to be updated is greater than or equal to the current security version number, the method for performing the firmware update can be: if the firmware identifier to be updated contains multiple firmware identifiers, and the security version number to be updated of the firmware corresponding to each firmware identifier to be updated is greater than or equal to its current security version number, then the light device performs the firmware update; if the security version number to be updated of the firmware corresponding to at least one firmware identifier to be updated is less than its current security version number, then the light device is prohibited from rolling back the update.

[0080] By obtaining the current security version number of the firmware corresponding to the firmware identifier to be updated based on the firmware identifier to be updated; if the security version number to be updated is greater than or equal to the current security version number, the firmware is updated, which can achieve the purpose of preventing the rollback of the light device firmware, and can ensure that the firmware of the light device is updated to the latest security version number, and can also improve the security of the light device firmware during the update.

[0081] Optionally, the target credential includes: credential version, credential generation timestamp, credential validity period, light device identifier, firmware identifier, target security version number of the firmware corresponding to each firmware identifier, target software version number of the firmware corresponding to each firmware identifier, and target trusted signature.

[0082] Among them, the certificate version is the version information of the certificate, and the content of the certificate version corresponding to different light devices may be different; the certificate generation timestamp is the time when the certificate is generated, which can be the total number of seconds from 00:00:00 Greenwich time on January 1, 1970 to the present; the certificate validity period is the time period during which the certificate is valid, calculated from the certificate generation timestamp, and the unit can be seconds; the light device identification includes the product serial number and device serial number of the light device, and the certificate is only valid for the marked products and devices; the firmware identification is the identification information of each firmware in the light device; the target security version number of the firmware corresponding to each firmware identification and the target software version number of the firmware corresponding to each firmware identification are two version numbers of the firmware corresponding to each firmware identification, which are used to verify the firmware of the light device, update and start the firmware of the light device, among which the security version number is the standard version number of the firmware, and the software version number is the software version number of the firmware. It should be noted that when updating the firmware on a light device, the firmware update data needs to carry the updated security version number of the firmware corresponding to the firmware identifier to be updated. Only the updated security version number needs to be verified, and the verification of the firmware software version number is not limited. This can not only ensure firmware rollback protection, but also meet the user's needs for various firmware software version numbers. When the light device starts the firmware execution, it is necessary to verify the target security version number of the firmware corresponding to each firmware identifier in the target certificate received from the rich device and the target software version number of the firmware corresponding to each firmware identifier, so as to improve the security of the firmware running on the light device. By flexibly setting the dual version numbers, the light device can be updated and started flexibly. The target trusted signature is a signature issued by a server or other means using a universal public and private key.

[0083] Specifically, the target voucher may also include: a voucher serial number and a flag bit, wherein the voucher serial number can be used for post-audit retrieval, and the flag bit can identify the capabilities of the voucher, such as the valid range, valid times, etc. In a specific example, Figure 2 This is a schematic diagram of a target certificate in the first embodiment of the present invention, such as Figure 2As shown, the target credential includes the credential version, credential serial number, credential generation timestamp, credential validity period, flag bit, light device identification (product serial number and device serial number of the light device), firmware identification (for example, firmware 1, firmware N), the target security version number of the firmware corresponding to each firmware identification, the target software version number of the firmware corresponding to each firmware identification, and the target trusted signature.

[0084] Optionally, verifying the target credential, and if the verification is successful, controlling the firmware to run, including:

[0085] Obtain the current security version number of the firmware corresponding to each firmware identifier in the light device and the current software version number of the firmware corresponding to each firmware identifier;

[0086] If the current security version number of the firmware corresponding to each firmware identifier is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, and the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, the verification is successful and the firmware is controlled to run.

[0087] In a specific example, Figure 3 This is a flow chart of a light device verifying a target credential in the first embodiment of the present invention. Figure 3 As shown, after the light device establishes a connection with the rich device, the target credential sent by the rich device is obtained. The target credential includes a firmware identifier, a target security version number of the firmware corresponding to each firmware identifier, and a target software version number of the firmware corresponding to each firmware identifier. The security version number and the software version number of the firmware are verified in sequence according to the order of the firmware identifiers in the target credential. First, the current security version number of the firmware corresponding to each firmware identifier is verified with the target security version number of the firmware. If the current security version number of the firmware corresponding to each firmware identifier is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, the security version number verification is successful. Otherwise, the verification fails. Then, the current software version number of the firmware corresponding to each firmware identifier is verified with the target software version number of the firmware. If the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, the software version number verification is successful. Otherwise, the verification fails. The successful verification of the security version number and the software version number of each firmware indicates that each firmware of the light device has been successfully verified, and the light device is officially started to run the firmware in the light device.

[0088] By obtaining the current security version number of the firmware corresponding to each firmware identifier in the light device and the current software version number of the firmware corresponding to each firmware identifier; if the current security version number of the firmware corresponding to each firmware identifier is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, and the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, the verification is successful, and the firmware operation is controlled. The dual version number authentication mechanism can be implemented through the security version number and software version number in the target credential, thereby improving the security of the firmware running on the light device.

[0089] The technical solution of this embodiment is as follows: after the light device is started, a target soft bus connection request is sent to the rich device, so that the rich device establishes a connection with the light device according to the target soft bus connection request; a credential application request is sent to the rich device, so that the rich device obtains the target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update of the firmware update data sent by the rich device; the target credential sent by the rich device is received; the target credential is verified, and if the verification is successful, the firmware is controlled to run, which solves the problem that the light device has no or only limited tamper-proof storage space, resulting in the inability to perform firmware verification or the small number of achievable verifications, making it difficult to implement firmware rollback protection. A connection channel between the rich device and the light device can be established based on the soft bus, and the target credential can be securely transferred between the light device and the rich device through the connection channel. The light device verifies the light device's firmware based on the target credential, and controls the firmware to run after the verification is successful, thereby implementing firmware rollback protection for the light device.

[0090] Example 2

[0091] Figure 4 This is a flowchart of a light device firmware verification method in the second embodiment of the present invention. This embodiment is applicable to the case where firmware rollback protection is implemented after firmware verification of a light device. This method can be executed by the light device firmware verification device in the fourth embodiment of the present invention. The device can be implemented in software and / or hardware. Figure 4 As shown, the method is executed by the rich device and specifically includes the following steps:

[0092] S210: Receive a target soft bus connection request sent by a light device.

[0093] Specifically, the rich device receives a target soft bus connection request sent by a light device after startup in the same distributed soft bus networking environment.

[0094] S220: Establish a connection with the light device according to the target soft bus connection request.

[0095] Specifically, the rich device establishes a soft bus connection with the light device according to the light device identifier carried in the target soft bus connection request.

[0096] S230: Receive a credential application request sent by the light device.

[0097] Specifically, after establishing a soft bus connection with the light device, the rich device receives a credential application request sent by the light device.

[0098] S240, sending the target credential to the light device according to the credential application request, so that the light device verifies according to the target credential, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0099] Specifically, the target certificate is sent to the light device according to the certificate application request so that the light device can verify according to the target certificate. The method can be: the certificate application request can carry the light device identifier, the rich device queries the certificate set stored in the rich device according to the light device identifier carried in the certificate application request, obtains the target certificate corresponding to the light device, and sends the target certificate to the light device so that the light device can verify according to the target certificate, wherein the target certificate is the certificate determined by the rich device according to the certificate update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0100] Optionally, before receiving the target soft bus connection request sent by the light device, the method further includes:

[0101] receiving an initial soft bus connection request sent by a light device, wherein the initial soft bus connection request carries a light device identifier;

[0102] Establishing a connection with the light device according to the initial soft bus connection request, sending a request to the target server based on the light device identifier, and receiving the firmware update data and the to-be-verified credential sent by the target server;

[0103] Verifying the to-be-verified credential, and if the verification is successful, sending the firmware update data to the light device, so that the light device performs a firmware update according to the firmware update data;

[0104] receiving a credential update request sent after the light device update is completed, and determining the credential to be verified as a target credential according to the credential update request;

[0105] After determining the target credential, an update completion instruction is generated and sent to the light device, so that the light device controls the disconnection between the light device and the rich device according to the update completion instruction.

[0106] The target server is a trusted update server that can establish a connection with the rich device. The target server includes a trusted certificate issuing center and a firmware publishing center. The trusted certificate issuing center can send a to-be-verified certificate to the rich device, and the firmware publishing center can send firmware update data to the rich device. The to-be-verified certificate is a certificate issued by the target server that requires verification by the rich device. The content of the to-be-verified certificate is similar to that of the target certificate and is not further described here.

[0107] Specifically, the method for receiving the initial soft bus connection request sent by the light device can be: when the light device is pre-started, it sends the initial soft bus connection request to the rich device in the same distributed soft bus networking environment, and the rich device receives the initial soft bus connection request.

[0108] Specifically, a connection is established with the light device according to the initial soft bus connection request, and a request is sent to the target server based on the light device identifier. The method for receiving the firmware update data and the certificate to be verified sent by the target server can be: the rich device establishes a soft bus connection with the light device according to the light device identifier carried in the initial soft bus connection request, and then the rich device checks whether the light device needs to be updated with firmware. The rich device can send a firmware update query request to the target server connected to the rich device, wherein the firmware update query request carries the light device identifier, and the target server determines whether the firmware of the light device needs to be updated based on the light device identifier. If the target server determines that the light device needs to be updated, the target server automatically generates the certificate to be verified corresponding to the light device, and sends the firmware update data and the certificate to be verified to the rich device.

[0109] Specifically, the certificate to be verified is verified. If the verification is successful, the firmware update data is sent to the light device, so that the light device performs firmware update according to the firmware update data. The method can be: the rich device stores a historical verification certificate determined after the light device last updated the firmware, and the certificate to be verified is verified with the historical verification certificate. For example, if the trusted signature in the certificate to be verified is verified, the certificate version in the certificate to be verified is greater than or equal to the certificate version in the historical verification certificate, the certificate generation timestamp in the certificate to be verified is greater than or equal to the certificate generation timestamp in the historical verification certificate, the current time is within the validity period of the certificate in the certificate to be verified, the light device identifier in the certificate to be verified matches the light device identifier in the historical verification certificate, and the security version number of the firmware corresponding to each firmware identifier in the certificate to be verified is greater than or equal to the security version number of the firmware corresponding to each firmware identifier in the historical verification certificate, then it is determined that the verification is successful, and the firmware update data is sent to the light device, so that the light device performs firmware update according to the firmware update data.

[0110] Specifically, the method of receiving the credential update request sent after the light device update is completed, and determining the credential to be verified as the target credential according to the credential update request can be: after the light device completes the firmware update according to the firmware update data, the rich device receives the credential update request sent by the light device, and the rich device determines the credential to be verified as the target credential according to the credential update request. At the same time, the historical verification credential of the light device stored in the rich device is deleted, that is, the newly generated target credential will be converted into a new historical verification credential when the credential to be verified is obtained next time.

[0111] Specifically, after determining the target credential, an update completion instruction is generated, and the update completion instruction is sent to the light device, so that the light device controls the disconnection of the connection between the light device and the rich device according to the update completion instruction. The method can be: after the rich device determines the target credential, an update completion instruction is generated, and the update completion instruction is sent to the light device, so that the light device disconnects the connection between the light device and the rich device according to the update completion instruction, and then starts after the firmware update is completed, and sends a target soft bus connection request to the rich device.

[0112] It should be explained that the rich device includes the rich device CA and the rich device TA, wherein the rich device CA mainly plays the role of communication, and the rich device TA provides a trusted execution environment and plays the role of verification. In a specific example, Figure 5 This is a framework diagram of a light device firmware verification in the second embodiment of the present invention, such as Figure 5 As shown, the target server is connected to the rich device, and the target server may include a trusted certificate issuing center and a firmware publishing center, wherein the trusted certificate issuing center sends the certificate to be verified to the rich device, and the firmware publishing center sends the firmware update data to the rich device. The light device and the rich device are connected through a soft bus, and the light device can perform firmware updates and target certificate verification. The rich device CA is mainly responsible for communication, receiving the firmware update data and the certificate to be verified of the light device issued by the target server. The rich device CA has a trusted environment agent service, which is connected to the rich device TA. The rich device TA executes the trusted environment and can verify the certificate to be verified. In another specific example, Figure 6 This is a schematic diagram of updating and starting the firmware of a light device in the second embodiment of the present invention. Figure 6As shown, the light device pre-starts and sends an initial soft bus connection request to the rich device CA. The rich device CA identifies the light device based on the initial soft bus connection request and establishes a connection with the light device. Then, the light device firmware update is checked. The rich device CA sends a firmware update query request to the target server. If the target server determines that the light device needs to be updated (the light device firmware update data can be compared with the current firmware data. If there is a firmware whose firmware update data corresponds to a security version number greater than the security version number corresponding to the current firmware data, it is determined that the light device needs to be updated), the target server automatically generates a to-be-verified credential corresponding to the light device, and sends the firmware update data and the to-be-verified credential to the rich device. If the light device does not need to be updated, the process ends; the rich device CA receives the firmware update data and the to-be-verified credential, and sends a request to the rich device TA to verify the to-be-verified credential. The rich device TA verifies the to-be-verified credential. If the verification is successful, the to-be-verified credential is cached and the rich device CA is informed of the verification success. The rich device CA sends the successfully verified firmware update data to the light device. The light device obtains the to-be-updated firmware identifier carried in the firmware update data. The light device then checks the current security version number of the firmware corresponding to the firmware identifier. If the security version number to be updated carried in the firmware update data is greater than or equal to the current security version number, the firmware update verification is successful and the firmware update is performed. After the light device completes the firmware update, a credential update request is generated and sent to the rich device TA. The rich device TA determines the credential to be verified as the target credential based on the credential update request and deletes the previously cached historical verification credential. After updating the credential, the rich device TA generates an update completion instruction and sends it to the light device. The light device disconnects the previous connection with the rich device based on the update completion instruction, then restarts and sends a target soft bus connection request to the rich device CA again. The rich device CA authenticates the light device based on the target soft bus connection request and establishes a connection with the light device, notifying the light device that the connection has been established. The light device sends a credential application request to the rich device TA. The rich device TA returns the stored target credential to the light device. The light device verifies the security version number and software version number of the firmware in the order of the firmware identifiers in the target credential. If the verification is successful, the light device starts normally and runs the light device's firmware. Otherwise, the light device is prohibited from starting.

[0113] Optionally, verifying the credential to be verified, and if the verification is successful, sending the firmware update data to the light device, including:

[0114] Obtain historical verification credentials, preset public key and current time;

[0115] The trusted signature in the certificate to be verified is verified based on the preset public key. If the verification passes, the certificate version in the certificate to be verified is greater than or equal to the certificate version in the historical verification certificate, the certificate generation timestamp in the certificate to be verified is greater than or equal to the certificate generation timestamp in the historical verification certificate, the current time is within the validity period of the certificate in the certificate to be verified, the light device identifier in the certificate to be verified matches the light device identifier in the historical verification certificate, and the security version number of the firmware corresponding to each firmware identifier in the certificate to be verified is greater than or equal to the security version number of the firmware corresponding to each firmware identifier in the historical verification certificate, then the verification is determined to be successful and the firmware update data is sent to the light device.

[0116] The historical verification credential is the target credential determined during the previous verification. The preset public key is the public key in the preset public-private key pair used by the target server to generate the trusted signature in the credential. The private key is used to generate the trusted signature, and the preset public key is used to verify the trusted signature. The preset public key is stored in the trusted execution environment of the rich device. The current time is the current time of use of the rich device. The current time is compared with the credential validity period in the credential to be verified. If the current time is within the credential validity period, the credential to be verified is determined to be valid.

[0117] In a specific example, Figure 7 This is a flow chart of a verification of a certificate to be verified in the second embodiment of the present invention, such as Figure 7 As shown, the rich device TA is used to verify the certificate to be verified. The preset public key in the rich device TA is first used to verify the trusted signature in the certificate to be verified. If the verification passes, the certificate version in the certificate to be verified is greater than or equal to the certificate version in the historical verification certificate, the certificate generation timestamp in the certificate to be verified is greater than or equal to the certificate generation timestamp in the historical verification certificate, the current time is within the validity period of the certificate in the certificate to be verified, the light device identifier in the certificate to be verified matches the light device identifier in the historical verification certificate, and the security version number of the firmware corresponding to each firmware identifier in the certificate to be verified is greater than or equal to the security version number of the firmware corresponding to each firmware identifier in the historical verification certificate, then the verification is determined to be successful, otherwise, the verification fails.

[0118] By verifying the trusted signature in the to-be-verified credential, and after the signature verification passes, verifying the contents of the to-be-verified credential and the historical verification credential in turn, if the verification is successful, the rich device will send the firmware update data to the light device, which can ensure the credibility of the to-be-verified credential and ensure the safe operation of the light device.

[0119] The technical solution of this embodiment receives a target soft bus connection request sent by a light device; establishes a connection with the light device according to the target soft bus connection request; receives a credential application request sent by the light device; sends the target credential to the light device according to the credential application request, so that the light device performs verification according to the target credential. This solves the problem that the light device has no or only limited tamper-proof storage space, which makes it impossible to perform firmware verification or the number of achievable verifications is small, making it difficult to implement firmware rollback protection. A connection channel between the rich device and the light device can be established based on the soft bus. Through the connection channel, the target credential can be securely transferred between the light device and the rich device, so that the light device can perform firmware verification of the light device based on the target credential, and control the firmware operation after the verification is successful, thereby implementing firmware rollback protection for the light device.

[0120] Example 3

[0121] Figure 8 This is a schematic diagram of the structure of a light device firmware verification device in the third embodiment of the present invention. This embodiment is applicable to the case where firmware rollback protection is implemented after firmware verification of light devices. The device can be implemented in software and / or hardware. The device can be integrated into any device that provides the function of light device firmware verification, such as Figure 8 As shown, the light device firmware verification apparatus is configured in the light device, and specifically includes: a connection request sending module 310 , an application request sending module 320 , a target credential receiving module 330 and a target credential verification module 340 .

[0122] The connection request sending module 310 is used to send a target soft bus connection request to the rich device after the light device is started, so that the rich device establishes a connection with the light device according to the target soft bus connection request;

[0123] An application request sending module 320 is configured to send a credential application request to the rich device so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is the credential determined by the rich device based on the credential update request sent by the light device after the light device completes the update based on the firmware update data sent by the rich device;

[0124] The target credential receiving module 330 is configured to receive the target credential sent by the rich device;

[0125] The target credential verification module 340 is used to verify the target credential and control the firmware to run if the verification is successful.

[0126] Optionally, also include:

[0127] A pre-start module, configured to send an initial soft bus connection request to the rich device after the light device is pre-started, so that the rich device establishes a connection with the light device according to the initial soft bus connection request;

[0128] An update data receiving module, configured to receive firmware update data sent by a rich device and perform firmware update according to the firmware update data;

[0129] an update request sending module, configured to send a credential update request to the rich device after the update is completed, so that the rich device determines a target credential according to the credential update request and generates an update completion instruction after determining the target credential;

[0130] The connection disconnection module is used to control the disconnection between the light device and the rich device after receiving the update completion instruction.

[0131] Optionally, the firmware update data carries an identifier of the firmware to be updated and a security version number of the firmware to be updated corresponding to the identifier of the firmware to be updated;

[0132] Accordingly, the update data receiving module is specifically used to:

[0133] Obtaining the current security version number of the firmware corresponding to the firmware identifier to be updated according to the firmware identifier to be updated;

[0134] If the security version number to be updated is greater than or equal to the current security version number, the firmware is updated.

[0135] Optionally, the target credential includes: credential version, credential generation timestamp, credential validity period, light device identifier, firmware identifier, target security version number of the firmware corresponding to each firmware identifier, target software version number of the firmware corresponding to each firmware identifier, and target trusted signature.

[0136] Optionally, the target credential verification module is specifically used to:

[0137] Obtain the current security version number of the firmware corresponding to each firmware identifier in the light device and the current software version number of the firmware corresponding to each firmware identifier;

[0138] If the current security version number of the firmware corresponding to each firmware identifier is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, and the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, the verification is successful and the firmware is controlled to run.

[0139] The above-mentioned product can execute the method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0140] Example 4

[0141] Figure 9This is a schematic diagram of the structure of a light device firmware verification device in the fourth embodiment of the present invention. This embodiment is applicable to the case where firmware rollback protection is implemented after firmware verification of light devices. The device can be implemented in software and / or hardware. The device can be integrated into any device that provides light device firmware verification function, such as Figure 9 As shown, the light device firmware verification apparatus is configured in a rich device, and specifically includes: a connection request receiving module 410 , a connection request establishing module 420 , an application request receiving module 430 and a target credential sending module 440 .

[0142] The connection request receiving module 410 is configured to receive a target soft bus connection request sent by a light device;

[0143] A connection request establishing module 420, configured to establish a connection with the light device according to the target soft bus connection request;

[0144] The application request receiving module 430 is configured to receive a credential application request sent by a light device;

[0145] The target credential sending module 440 is used to send the target credential to the light device according to the credential application request, so that the light device verifies according to the target credential, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device.

[0146] Optionally, also include:

[0147] An initial request receiving module, configured to receive an initial soft bus connection request sent by a light device, wherein the initial soft bus connection request carries a light device identifier;

[0148] a sending request sending module, configured to establish a connection with the light device according to the initial soft bus connection request, and send a sending request to a target server based on the light device identifier, and receive firmware update data and a to-be-verified credential sent by the target server;

[0149] a credential verification module, configured to verify the credential to be verified, and if the verification is successful, send the firmware update data to the light device, so that the light device performs a firmware update according to the firmware update data;

[0150] An update request receiving module, configured to receive a credential update request sent after the light device update is completed, and determine the credential to be verified as a target credential according to the credential update request;

[0151] The completion instruction sending module is used to generate an update completion instruction after determining the target credential, and send the update completion instruction to the light device, so that the light device controls the disconnection between the light device and the rich device according to the update completion instruction.

[0152] Optionally, the credential verification module is specifically used to:

[0153] Obtain historical verification credentials, preset public key and current time;

[0154] The trusted signature in the certificate to be verified is verified based on the preset public key. If the verification passes, the certificate version in the certificate to be verified is greater than or equal to the certificate version in the historical verification certificate, the certificate generation timestamp in the certificate to be verified is greater than or equal to the certificate generation timestamp in the historical verification certificate, the current time is within the validity period of the certificate in the certificate to be verified, the light device identifier in the certificate to be verified matches the light device identifier in the historical verification certificate, and the security version number of the firmware corresponding to each firmware identifier in the certificate to be verified is greater than or equal to the security version number of the firmware corresponding to each firmware identifier in the historical verification certificate, then the verification is determined to be successful and the firmware update data is sent to the light device.

[0155] The above-mentioned product can execute the method provided by any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0156] Example 5

[0157] Figure 10 : is a structural diagram of an electronic device in embodiment five of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0158] like Figure 10As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., which is communicatively connected to the at least one processor 11. The memory stores a computer program that can be executed by the at least one processor. The processor 11 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 12 or the computer program loaded from the storage unit 18 into the random access memory (RAM) 13. Various programs and data required for the operation of the electronic device 10 can also be stored in the RAM 13. The processor 11, ROM 12, and RAM 13 are connected to each other via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0159] Multiple components in the electronic device 10 are connected to the I / O interface 15, including an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc.; and a communication unit 19, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information / data with other devices via a computer network such as the Internet and / or various telecommunication networks.

[0160] The processor 11 can be any general-purpose and / or specialized processing component with processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various specialized artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes the various methods and processes described above, such as the light device firmware verification method.

[0161] In some embodiments, the light device firmware verification method can be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 10 via the ROM 12 and / or the communication unit 19. When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the light device firmware verification method described above can be performed. Alternatively, in other embodiments, the processor 11 can be configured to perform the light device firmware verification method in any other appropriate manner (for example, by means of firmware).

[0162] Various embodiments of the systems and techniques described herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-chip systems (SOCs), programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments can include being implemented in one or more computer programs that are executable and / or interpreted on a programmable system that includes at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0163] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the computer program is executed by the processor, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The computer program may be executed entirely on the machine, partially on the machine, as a stand-alone software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0164] In the context of the present invention, computer-readable storage media can be tangible media that can contain or store a computer program for use with an instruction execution system, device or equipment or used in combination with an instruction execution system, device or equipment. Computer-readable storage media can include but are not limited to electronic, magnetic, optical, electromagnetic, infrared or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, computer-readable storage media can be machine-readable signal media. More specific examples of machine-readable storage media can include electrical connections based on one or more lines, portable computer disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), optical fibers, portable compact disk read-only memories (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0165] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, the feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including acoustic input, voice input, or tactile input).

[0166] The systems and techniques described herein can be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such back-end components, middleware components, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0167] A computing system may include clients and servers. The clients and servers are typically remote from each other and typically interact via a communication network. This client-server relationship arises through computer programs running on the respective computers, creating a client-server relationship. The server may be a cloud server, also known as a cloud computing server or cloud host. This server is a hosting product within the cloud computing service ecosystem that addresses the management difficulties and limited scalability of traditional physical hosting and VPS services.

[0168] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in the present invention can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of the present invention can be achieved. This is not limited herein.

[0169] An embodiment of the present invention further provides a computer program product, including a computer program, which, when executed by a processor, implements the light device firmware verification method according to any embodiment of the present invention.

[0170] The above specific embodiments do not limit the scope of protection of the present invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention are intended to be included within the scope of protection of the present invention.

Claims

1. A method for verifying firmware of a light device, characterized in that: Executed by light equipment, including: After the light device is started, the light device sends a target soft bus connection request to the rich device, so that the rich device establishes a connection with the light device according to the target soft bus connection request; Sending a credential application request to the rich device so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is a credential determined by the rich device based on the credential update request sent by the light device after the light device completes an update based on the firmware update data sent by the rich device, and the target credential includes a target security version number of the firmware corresponding to each firmware identifier in the light device and a target software version number of the firmware corresponding to each firmware identifier; receiving a target credential sent by the rich device; Verifying the target credential, and if the verification is successful, controlling the firmware to run; After the light device starts, before sending a target soft bus connection request to the rich device, it also includes: After the light device is pre-started, sending an initial soft bus connection request to the rich device, so that the rich device establishes a connection with the light device according to the initial soft bus connection request; receiving firmware update data sent by the rich device, and performing firmware update according to the firmware update data; After the update is completed, a credential update request is sent to the rich device, so that the rich device determines a target credential according to the credential update request, and generates an update completion instruction after determining the target credential; After receiving the update completion instruction, the connection between the light device and the rich device is controlled to be disconnected.

2. The method according to claim 1, characterized in that The firmware update data carries an identifier of the firmware to be updated and a security version number of the firmware to be updated corresponding to the identifier of the firmware to be updated; Accordingly, performing firmware update according to the firmware update data includes: Obtaining the current security version number of the firmware corresponding to the firmware identifier to be updated according to the firmware identifier to be updated; If the security version number to be updated is greater than or equal to the current security version number, the firmware is updated.

3. The method according to claim 1, characterized in that The target credential includes: credential version, credential generation timestamp, credential validity period, light device identification, firmware identification, target security version number of the firmware corresponding to each firmware identification, target software version number of the firmware corresponding to each firmware identification, and target trusted signature.

4. The method according to claim 3, characterized in that Verify the target credential. If the verification is successful, control the firmware to run, including: Obtain the current security version number of the firmware corresponding to each firmware identifier in the light device and the current software version number of the firmware corresponding to each firmware identifier; If the current security version number of the firmware corresponding to each firmware identifier is greater than or equal to the target security version number of the firmware corresponding to each firmware identifier, and the current software version number of the firmware corresponding to each firmware identifier is greater than or equal to the target software version number of the firmware corresponding to each firmware identifier, the verification is successful and the firmware is controlled to run.

5. A light device firmware verification method, characterized in that: Executed by rich devices, including: Receive a target soft bus connection request sent by a light device; Establishing a connection with the light device according to the target soft bus connection request; Receive a credential application request sent by a light device; sending the target credential to the light device according to the credential application request, so that the light device performs verification according to the target credential, wherein the target credential is the credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device; Before receiving the target soft bus connection request sent by the light device, it also includes: receiving an initial soft bus connection request sent by a light device, wherein the initial soft bus connection request carries a light device identifier; Establishing a connection with the light device according to the initial soft bus connection request, sending a request to the target server based on the light device identifier, and receiving the firmware update data and the to-be-verified credential sent by the target server; Verifying the to-be-verified credential, and if the verification is successful, sending the firmware update data to the light device, so that the light device performs a firmware update according to the firmware update data; receiving a credential update request sent after the light device update is completed, and determining the credential to be verified as a target credential according to the credential update request; After determining the target credential, an update completion instruction is generated and sent to the light device, so that the light device controls the disconnection between the light device and the rich device according to the update completion instruction.

6. The method according to claim 5, characterized in that Verifying the credential to be verified, and if the verification is successful, sending the firmware update data to the light device, including: Obtain historical verification credentials, preset public key and current time; The trusted signature in the certificate to be verified is verified based on the preset public key. If the verification passes, the certificate version in the certificate to be verified is greater than or equal to the certificate version in the historical verification certificate, the certificate generation timestamp in the certificate to be verified is greater than or equal to the certificate generation timestamp in the historical verification certificate, the current time is within the validity period of the certificate in the certificate to be verified, the light device identifier in the certificate to be verified matches the light device identifier in the historical verification certificate, and the security version number of the firmware corresponding to each firmware identifier in the certificate to be verified is greater than or equal to the security version number of the firmware corresponding to each firmware identifier in the historical verification certificate, then the verification is determined to be successful and the firmware update data is sent to the light device.

7. A light device firmware verification device, characterized in that: Configuration in light equipment, including: a connection request sending module, configured to send a target soft bus connection request to the rich device after the light device is started, so that the rich device establishes a connection with the light device according to the target soft bus connection request; an application request sending module, configured to send a credential application request to the rich device, so that the rich device obtains a target credential corresponding to the light device, wherein the target credential is a credential determined by the rich device according to the credential update request sent by the light device after the light device completes an update based on the firmware update data sent by the rich device, and the target credential includes a target security version number of the firmware corresponding to each firmware identifier in the light device and a target software version number of the firmware corresponding to each firmware identifier; a target credential receiving module, configured to receive a target credential sent by a rich device; A target credential verification module is used to verify the target credential and control the firmware to run if the verification is successful; A pre-start module, configured to send an initial soft bus connection request to the rich device after the light device is pre-started, so that the rich device establishes a connection with the light device according to the initial soft bus connection request; An update data receiving module, configured to receive firmware update data sent by a rich device and perform firmware update according to the firmware update data; an update request sending module, configured to send a credential update request to the rich device after the update is completed, so that the rich device determines a target credential according to the credential update request and generates an update completion instruction after determining the target credential; The connection disconnection module is used to control the disconnection between the light device and the rich device after receiving the update completion instruction.

8. A light device firmware verification device, characterized in that: Configuration in rich devices, including: A connection request receiving module, configured to receive a target soft bus connection request sent by a light device; A connection request establishing module, configured to establish a connection with the light device according to the target soft bus connection request; An application request receiving module, configured to receive a credential application request sent by a light device; a target credential sending module, configured to send a target credential to the light device according to the credential application request, so that the light device performs verification according to the target credential, wherein the target credential is a credential determined by the rich device according to the credential update request sent by the light device after the light device completes the update according to the firmware update data sent by the rich device; An initial request receiving module, configured to receive an initial soft bus connection request sent by a light device, wherein the initial soft bus connection request carries a light device identifier; a sending request sending module, configured to establish a connection with the light device according to the initial soft bus connection request, and send a sending request to a target server based on the light device identifier, and receive firmware update data and a to-be-verified credential sent by the target server; a credential verification module, configured to verify the credential to be verified, and if the verification is successful, send the firmware update data to the light device, so that the light device performs a firmware update according to the firmware update data; An update request receiving module, configured to receive a credential update request sent after the light device update is completed, and determine the credential to be verified as a target credential according to the credential update request; The completion instruction sending module is used to generate an update completion instruction after determining the target credential, and send the update completion instruction to the light device, so that the light device controls the disconnection between the light device and the rich device according to the update completion instruction.

9. An electronic device, characterized in that: The electronic device comprises: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the light device firmware verification method according to any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the light device firmware verification method according to any one of claims 1 to 6 when executed.

11. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the computer program implements the light device firmware verification method according to any one of claims 1 to 6.

Images