A firmware encryption method and device, electronic equipment and storage medium

Abstract

The application is suitable for the technical field of device management, and provides a firmware encryption method and device, electronic equipment and storage medium, the method comprises the following steps: in response to a firmware encryption instruction of a target device, authenticating an encryption device through a server; if the encryption device is identified as legal, sending a response request to the target device; the response request contains a first random number; receiving response information fed back by the target device based on the response request; the response information contains a second random number; if the response information contains the first random number, generating an encryption ciphertext about firmware installed in the target device according to the first device identifier of the target device and the second random number, and sending the encryption ciphertext to the target device. In the above method, since the firmware is bound with the encryption ciphertext, if the first device identifier corresponding to the firmware is inconsistent with the second device identifier locally, it can be determined that the firmware is applied to other devices, and the confidentiality of the firmware is ensured.

Description

Technical Field

[0001] This application belongs to the field of device management technology, and in particular relates to a method, apparatus, electronic device and storage medium for firmware encryption. Background Technology

[0002] With the continuous development of electronic technology, electronic devices are becoming increasingly powerful. Most of the functions of these devices rely on firmware installed locally. Therefore, the confidentiality and non-portability of the firmware directly affect device information security. Improving firmware confidentiality has become a crucial aspect of device information security.

[0003] Existing firmware encryption technologies typically involve adding an external encryption chip to the processor within the electronic device where the firmware is installed. This external chip encrypts the firmware running within the processor, thereby enhancing the security of the firmware. However, this method increases the manufacturing cost of electronic devices due to the need for an additional encryption chip. Furthermore, with the trend towards lighter and more compact electronic devices, adding an extra chip also complicates circuit layout and increases the overall size of the device. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for firmware encryption, which can solve the problems of existing firmware encryption technologies that require additional encryption chips, thus increasing the manufacturing cost of electronic devices. Furthermore, with the trend of electronic devices becoming lighter, adding additional chips also increases the difficulty of circuit layout and the size of the device.

[0005] In a first aspect, embodiments of this application provide a firmware encryption method applied to an encryption device, comprising:

[0006] In response to the firmware encryption command of the target device, the encryption device is authenticated by the server;

[0007] If the encryption device is identified as legitimate, a response request is sent to the target device; the response request contains a first random number.

[0008] The system receives response information from the target device based on the response request; the response information includes a second random number; the second random number is generated when the target device receives the response request.

[0009] If the response information contains the first random number, then an encrypted ciphertext about the firmware installed on the target device is generated based on the first device identifier of the target device and the second random number, and the encrypted ciphertext is sent to the target device; the encrypted ciphertext is used by the target device to authenticate the firmware based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device when the target device starts the device through the firmware.

[0010] In one possible implementation of the first aspect, the authentication of the encryption device by the server in response to the firmware encryption command of the target device includes:

[0011] Obtain the program identifier of the client program installed in the encryption device, and generate a third random number;

[0012] A handshake instruction is generated based on the program identifier and the third random number, and the handshake instruction is sent to the server; the handshake instruction is used by the server to generate a handshake response instruction based on the third random number when the server identifies the encryption device as legitimate based on the handshake instruction, and then sends the handshake response instruction to the encryption device.

[0013] In one possible implementation of the first aspect, after generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server, the method further includes:

[0014] If the handshake response instruction from the server is received within a preset first time period, it is determined whether the handshake response instruction contains the third random number.

[0015] If the handshake response instruction contains the third random number, then the encryption device is deemed legitimate;

[0016] If the handshake response instruction is not received from the server within the first time period, a network error message is generated.

[0017] In one possible implementation of the first aspect, generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server, includes:

[0018] Obtain the handshake communication protocol corresponding to the server;

[0019] The program identifier and the third random number are encapsulated within the handshake communication protocol, and the encapsulated handshake communication protocol is encrypted using a preset first encryption algorithm to obtain the handshake instruction. The server then decrypts the handshake instruction using a first decryption algorithm associated with the first encryption algorithm, compares the handshake communication protocol with the local protocol suite, and identifies whether the program identifier is a valid identifier when the handshake communication protocol matches the protocol suite. If the program identifier is a valid identifier, the server sends the handshake response instruction back to the encryption device.

[0020] In one possible implementation of the first aspect, after sending a response request to the target device if the encryption device is identified as legitimate, the method further includes:

[0021] If the response information from the target device is received within a preset second time period, it is determined whether the response information contains the first random number.

[0022] If the response information contains the first random number, then the process of generating encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number is executed, and the encrypted ciphertext is sent to the target device;

[0023] If no response information is received from the target device within the second time period, a device abnormality prompt message is generated.

[0024] In one possible implementation of the first aspect, sending a response request to the target device if the encryption device is identified as legitimate includes:

[0025] The first random number and the preset random number generation instruction are encapsulated to obtain a random number generation instruction package containing the first random number.

[0026] The random number generation instruction packet is encrypted using a preset second encryption algorithm to obtain the response request. The target device then decrypts the response request using a second decryption algorithm corresponding to the second encryption algorithm, extracts the random number generation instruction, generates the second random number based on the random number generation instruction, and encapsulates the second random number with the response command to obtain the response information. The response information is then sent to the encryption device.

[0027] In one possible implementation of the first aspect, after authenticating the encryption device via a server in response to a firmware encryption command from the target device, the method further includes:

[0028] The system receives an authentication failure instruction from the server; the authentication failure instruction is sent to the encryption device when it is detected that the encryption device is a data leakage device.

[0029] In response to the authentication failure instruction, an encryption abort instruction is generated to stop the firmware encryption operation on the target device.

[0030] Secondly, embodiments of this application provide a firmware encryption device, comprising:

[0031] A firmware encryption response unit is used to authenticate the encryption device through a server in response to a firmware encryption command from the target device.

[0032] A response request sending unit is configured to send a response request to the target device if the encryption device is identified as legitimate; the response request contains a first random number.

[0033] A response information receiving unit is configured to receive response information fed back by the target device based on the response request; the response information includes a second random number; the second random number is generated when the target device receives the response request;

[0034] An encrypted ciphertext sending unit is configured to, if the response information contains the first random number, generate encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and send the encrypted ciphertext to the target device; the encrypted ciphertext is used by the target device to authenticate the firmware based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device when the target device boots up through the firmware.

[0035] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method as described in any of the first aspects above.

[0036] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any of the first aspects above.

[0037] Fifthly, embodiments of this application provide a computer program product that, when run on a server, causes the server to execute the method described in any one of the first aspects above.

[0038] The beneficial effects of this application embodiment compared with the prior art are as follows: When encrypting the firmware in the target device, the encryption device performing the encryption operation is first authenticated for legitimacy. If the server identifies the encryption device as legitimate, it sends a response request to the target device. After receiving the response information from the target device, the communication link between the two is confirmed to be reliable, and the encrypted ciphertext is sent to the target device. This allows the target device to compare the device identifier in the encrypted ciphertext with the device identifier corresponding to the local device when it boots up the device through the firmware, in order to determine whether the firmware being run is being applied to other devices, thus achieving the purpose of authentication for the confidentiality of the firmware. Compared with existing firmware encryption technologies, the embodiments of this application do not require configuring an additional encryption chip to encrypt the firmware. Instead, a legitimate encryption device generates encrypted ciphertext containing a first device identifier for uniquely identifying the target device and a random number. Since the firmware is bound to the encrypted ciphertext, if the first device identifier corresponding to the firmware is inconsistent with the second device identifier of the device, it can be determined that the firmware is applied to other devices, thus ensuring the confidentiality of the firmware. On the other hand, the introduction of a second random number into the encrypted ciphertext can further increase the difficulty of deciphering the encrypted ciphertext, thereby improving the confidentiality of the encrypted ciphertext of the firmware. Attached Figure Description

[0039] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0040] Figure 1 This is a schematic diagram of the structure of a firmware encryption system provided in one embodiment of this application;

[0041] Figure 2 This is an interactive flowchart of a firmware encryption method provided in one embodiment of this application;

[0042] Figure 3 This is an interactive flowchart of S201, a firmware encryption method provided in an embodiment of this application;

[0043] Figure 4 This is a schematic diagram illustrating one implementation of a firmware encryption method provided in an embodiment of this application;

[0044] Figure 5 This is a schematic diagram of an implementation of S203 of a firmware encryption method provided in an embodiment of this application;

[0045] Figure 6This is a schematic diagram illustrating one implementation of a firmware encryption method provided in an embodiment of this application;

[0046] Figure 7 This is an interactive flowchart of a firmware encryption method provided in one embodiment of this application;

[0047] Figure 8 This is a schematic diagram of the firmware encryption device provided in the embodiments of this application;

[0048] Figure 9 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0049] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0050] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0051] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0052] The firmware encryption method provided in this application can be applied to electronic devices capable of encrypting device firmware, such as smartphones, servers, tablets, laptops, ultra-mobile personal computers (UMPCs), netbooks, and servers. For ease of distinction, these will be referred to as encryption devices below. This application does not limit the specific type of encryption device. In particular, the encryption device is equipped with a client program for encrypting device firmware, which enables the execution of the firmware encryption process on the target device requiring firmware encryption. The encryption device can establish a communication connection with the server via a wired or wireless network, and can communicate with the target device requiring firmware encryption via a serial port connection.

[0053] For example, Figure 1A schematic diagram of the firmware encryption system provided in one embodiment of this application is shown. See also... Figure 1 As shown, the firmware encryption system includes a server 11, an encryption device 12, and a target device 13 for which firmware encryption is to be performed. The server 11 and the encryption device 12 are connected via Ethernet, while the encryption device 12 and the target device 13 can establish a wired connection via a serial port. In this embodiment, the target device can specifically be a microcontroller unit (MCU), which can boot the device using locally installed firmware.

[0054] Please see Figure 2 , Figure 2 The diagram illustrates an interactive flowchart of a firmware encryption method provided in an embodiment of this application. The method includes the following steps:

[0055] In S201, the encryption device responds to the firmware encryption command of the target device and authenticates the encryption device through the server.

[0056] In this embodiment, the firmware of the target device may be in a state of pending encryption before leaving the factory. To improve the confidentiality and non-portability of the firmware and prevent firmware leakage, an encryption device can be used to encrypt the firmware in the target device before it leaves the factory. Based on this, when it is necessary to encrypt a target device, the encryption device can generate a firmware encryption instruction to execute the firmware encryption process for the target device.

[0057] In one possible implementation, the firmware encryption command can be user-initiated. The encryption device has a client program installed, which the user can launch to generate an encryption operation interface. This interface includes an encryption initiation control. After a communication connection has been established between the target device and the encryption device (e.g., the encryption device and the target device are connected via a serial interface), the user can click the encryption initiation control. When the encryption device detects that the control has been clicked, it can generate the firmware encryption command and execute the firmware encryption process, i.e., perform the operation in S201.

[0058] In one possible implementation, the firmware encryption command can be automatically executed by the encryption device. The implementation process is as follows: When the encryption device detects that a new device has been connected to the serial port, it can obtain the device identifier of the device and determine whether the device identifier is in the list of encrypted devices. If it is, the newly connected device is identified as an encrypted device, and there is no need to execute the firmware encryption process. Otherwise, if the device identifier of the newly connected device is not in the above-mentioned device list, the newly connected device is identified as the target device, a firmware encryption command is generated, and the operation of S201 is executed.

[0059] In this embodiment, since the encryption device may also be at risk of being leaked, in order to improve the confidentiality of the entire encryption process, the encryption device needs to be authenticated by the server during the encryption process to determine whether the encryption device is legitimate.

[0060] In S202, if the server detects that the encryption device is legitimate, it will send a legitimate detection result back to the encryption device.

[0061] In this embodiment, the server can receive the authentication request sent by the encryption device, perform authentication and identification operations on the encryption device based on the authentication request, and send the corresponding detection result to the encryption device after the authentication is completed.

[0062] In one possible implementation, the encryption device can add its local device identifier to the authentication request. If the encryption device has a client program paired with the server installed, it can also add the program identifier to the authentication request. The server can determine whether the encryption device is legitimate based on the device identifier and / or program identifier in the authentication request, such as whether the identifier is in the legitimate list, and send the corresponding detection result to the encryption device.

[0063] In one possible implementation, if the server detects that the encryption device is an illegal device, the server can discard the authentication request and not respond to the encryption device; the server can also send an authentication failure detection result to the encryption device, and the encryption device can terminate the encryption process for the target device upon receiving the authentication failure detection result.

[0064] In S203, if the encryption device is valid, the encryption device sends a response request to the target device; the response request contains a first random number.

[0065] In this embodiment, if the server determines that the encryption device is a legitimate device, the encryption device can perform subsequent operations. In order to improve the security of communication with the target device and reduce the risk of leakage during communication with the target device, the target device can generate a random number, namely the first random number mentioned above, and send a response request containing the first random number to the target device to detect whether the communication connection between the encryption device and the target device is valid.

[0066] In S204, the target device generates response information containing a first random number and a second random number based on the response request, and sends the response information to the encryption device.

[0067] In this embodiment, after receiving a response request from the encryption device, the target device can extract a first random number contained in the response request and generate a second random number locally. The first and second random numbers are then encapsulated to generate response information corresponding to the response request, which is then sent to the encryption device. The first random number is used by the encryption device to confirm that the response information is generated based on the aforementioned response request, while the second random number is used by the target device for subsequent authentication of the encrypted ciphertext. Therefore, after generating the second random number, the target device records it locally for subsequent authentication comparison.

[0068] In S205, if the encryption device detects that the response information contains a first random number, it generates encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and sends the encrypted ciphertext to the target device.

[0069] In this embodiment, after receiving the response information from the target device, the encryption device can detect whether the response information contains a first random number. If the response information carries the first random number configured by the encryption device in the preceding operation, the response information is identified as valid and the operation S205 is executed.

[0070] In one possible implementation, if the encryption device detects that the response information does not contain the first random number, or if the encryption device cannot parse the response information, it identifies and generates an encryption failure message and stops the encryption process.

[0071] In this embodiment, when the encryption device detects that the response information contains a first random number, it extracts the second random number contained in the response information and encrypts and encapsulates the first device identifier associated with the target device and the second random number to obtain encrypted ciphertext about the firmware installed in the target device. That is, the firmware is bound to the encrypted ciphertext, and then the firmware based on the encrypted ciphertext and the firmware bound to the encrypted ciphertext is sent to the target device.

[0072] In one possible implementation, to further enhance the confidentiality and decryption difficulty of the encrypted ciphertext, the encryption device can generate another random number, namely a fifth random number, when generating the encrypted ciphertext. The fourth random number, the second random number, and the aforementioned first device identifier are then encrypted and encapsulated to obtain the encrypted ciphertext associated with the firmware. Since both the encryption device and the target device add a random number during each communication process, the encrypted data possesses a certain degree of randomness, thereby improving the security and confidentiality of data transmission and making it more difficult to decrypt.

[0073] In S206, the target device stores encrypted ciphertext corresponding to the firmware, and when the target device starts the device through the firmware, it authenticates the firmware based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device.

[0074] In this embodiment, after receiving the encrypted ciphertext, the target device can store the encrypted ciphertext corresponding to the locally installed firmware in a designated storage area. The address of this storage area can be related to the device type of the target device; that is, different types of devices will store the encrypted ciphertext in different addresses.

[0075] In one possible implementation, after receiving the encrypted ciphertext, the target device can extract a second random number contained in the ciphertext and compare it with a second random number stored locally. If they match, the encrypted ciphertext is considered valid, and the encrypted ciphertext and firmware are associated and stored. Otherwise, if they do not match, an encryption failure message is sent to the encryption device. Upon receiving the encryption failure message, the encryption device can regenerate a new encrypted ciphertext.

[0076] In this embodiment, after the target device stores the encrypted ciphertext of the firmware, it can send an encryption completion command to the encryption device. After receiving the encryption completion command, the encryption device can prompt the user that the encryption has been successful.

[0077] In this embodiment, after encryption is completed, when the target device is subsequently booted via firmware, it will automatically read the encrypted ciphertext associated with the firmware, extract the first device identifier corresponding to the encrypted ciphertext, and compare the first device identifier with the second device identifier stored locally on the device. If the two match, the firmware is identified as legitimate firmware, and the device is booted normally. Conversely, if the first device identifier in the encrypted ciphertext associated with the firmware does not match the second device identifier stored locally on the device, it indicates that the firmware was illegally copied to the device. In this case, an error message is generated, and the target device stops running.

[0078] As can be seen from the above, the firmware encryption method provided in this application first authenticates the encryption device performing the encryption operation when encrypting the firmware in the target device. If the server identifies the encryption device as legitimate, it sends a response request to the target device. After receiving the response information from the target device, it confirms that the communication link between the two is reliable and sends the encrypted ciphertext to the target device. This allows the target device to compare the device identifier in the encrypted ciphertext with the device identifier corresponding to the local device when starting the device through the firmware, in order to determine whether the firmware being run is being applied to other devices, thus achieving the purpose of authentication for the confidentiality of the firmware. Compared with existing firmware encryption technologies, the embodiments of this application do not require configuring an additional encryption chip to encrypt the firmware. Instead, a legitimate encryption device generates encrypted ciphertext containing a first device identifier for uniquely identifying the target device and a random number. Since the firmware is bound to the encrypted ciphertext, if the first device identifier corresponding to the firmware is inconsistent with the second device identifier of the device, it can be determined that the firmware is applied to other devices, thus ensuring the confidentiality of the firmware. On the other hand, the introduction of a second random number into the encrypted ciphertext can further increase the difficulty of deciphering the encrypted ciphertext, thereby improving the confidentiality of the encrypted ciphertext of the firmware.

[0079] Figure 3 A flowchart illustrating a firmware encryption method according to a third embodiment of the present invention is shown. See also... Figure 3 In contrast Figure 2 In the embodiment described herein, firmware encryption method S201 includes: S2011 to S2013, which are detailed below:

[0080] Furthermore, in response to the firmware encryption command of the target device, the encryption device is authenticated by the server, including:

[0081] In S2011, the encryption device obtains the program identifier of the client program installed in the encryption device and generates a third random number.

[0082] In this embodiment, to facilitate the server's authentication of the encryption device, the encryption device can determine the program identifier of the client program used for encryption and generate a third random number through a random algorithm. Specifically, the client program is used to perform encryption operations on the target device. Under normal circumstances, this client program is a program published by the server, meaning its program identifier conforms to the server's encoding rules.

[0083] In one possible implementation, the aforementioned firmware encryption system may contain multiple servers. In this case, each client program corresponds to a designated server. When generating the aforementioned handshake instruction, the handshake instruction is sent to the server associated with that client program so that the corresponding server can authenticate the aforementioned handshake instruction.

[0084] In S2012, a handshake instruction is generated based on the program identifier and the third random number, and the handshake instruction is sent to the server; the handshake instruction is used by the server to generate a handshake response instruction based on the third random number when the server identifies the encryption device as legitimate based on the handshake instruction, and then sends the handshake response instruction to the encryption device.

[0085] In this embodiment, after obtaining the local program identifier and a third random number generated based on a random algorithm, the encryption device can generate a handshake instruction for communication with the server based on these two pieces of information, and send the handshake instruction to the server so that the server can perform a weighted operation on the encryption device according to the handshake instruction. The program identifier is used to determine whether the client program within the encryption device is a legitimate program, thereby determining the legitimacy of the current firmware encryption operation; while the third random number is used to improve the security and confidentiality of the communication process and increase the difficulty of decryption.

[0086] In S2013, the server identifies whether the encryption device is legitimate based on the program identifier in the handshake instruction.

[0087] In S014, when the server detects that the encryption device is legitimate, it generates a handshake response instruction based on the third random number and sends the handshake response instruction to the encryption device.

[0088] In this embodiment, after receiving the handshake instruction sent by the encryption device, the server can extract the program identifier carried in the handshake instruction and determine whether the program identifier is valid. The method for identifying the validity of the program identifier can be: determining whether the program identifier is within a preset list of valid identifiers; if so, the program identifier is considered valid; or, determining whether the encoding rule of the program identifier is within a preset encoding rule; if so, the program identifier is considered valid.

[0089] In this embodiment, if the server determines that the program identifier is valid, it can send a handshake response instruction to the encryption device. This handshake response instruction carries the third random number generated by the encryption device, and the server then sends the handshake response instruction to the encryption device. The encryption device can determine the validity of the handshake response information by checking whether the handshake response instruction carries the third random number.

[0090] In one possible implementation, when generating the handshake response command, the server can also generate a fifth random number. The fifth random number, the third random number, and the handshake response command are then encrypted and encapsulated to generate a ciphertext handshake response, which is then sent to the encryption device. If the encryption device can parse the ciphertext and determine that the handshake response command in the ciphertext is a pre-agreed command, and that the third random number in the ciphertext matches a previously generated third random number, then the subsequent encryption process is executed. Conversely, if the ciphertext cannot be parsed, or the handshake response command does not conform to the communication protocol, or the ciphertext does not carry a third random number, an encryption failure message is displayed, and the encryption process is stopped.

[0091] In this embodiment, the encryption device can encapsulate a program identifier and a randomly generated third random number within a handshake instruction. This allows the server to extract the program identifier carried in the handshake instruction to weight the encryption device and use the third random number to enhance the confidentiality of the communication process, thereby further increasing the difficulty of firmware leakage. Furthermore, performing online authentication of the encryption device before the encryption process prevents offline use due to client program leakage. If the server detects that a client program has been leaked, it can set the program identifier of that client program to an invalid identifier and not respond to handshake instructions initiated by that client program.

[0092] Furthermore, as another embodiment of this application, the above-described S2012 may specifically include the following steps:

[0093] Step 1: The encryption device obtains the handshake communication protocol corresponding to the server.

[0094] Step 2: The encryption device encapsulates the program identifier and the third random number within the handshake communication protocol, and encrypts the encapsulated handshake communication protocol using a preset first encryption algorithm to obtain the handshake instruction.

[0095] In this embodiment, the encryption device can obtain a handshake communication protocol pre-agreed with the server, encapsulate the program identifier and a third random number within the handshake communication protocol, and encrypt the encapsulated encryption communication protocol using a preset encryption algorithm to generate a handshake instruction. The encryption algorithm can be the Advanced Encryption Standard (AES) encryption algorithm.

[0096] Correspondingly, S2013 above specifically refers to: after the server decrypts the handshake instruction using the first decryption algorithm associated with the first encryption algorithm, it compares the handshake communication protocol with the local protocol cluster, and when the handshake communication protocol matches the protocol cluster, it identifies whether the program identifier is a valid identifier, and then when the program identifier is a valid identifier, it sends the handshake response instruction back to the encryption device.

[0097] In this embodiment, after receiving the handshake instruction, the server can decrypt it using an associated decryption algorithm to obtain the handshake communication protocol carried in the handshake instruction. The server then compares the handshake communication protocol with a pre-agreed protocol cluster to determine whether the handshake communication protocol is within the protocol cluster. If the handshake communication protocol is within the protocol cluster, the handshake communication protocol is identified as legitimate. Subsequently, the server performs a legitimate verification of the program identifier of the client program installed in the encryption device. When the program identifier is identified as legitimate, the server responds to the handshake instruction, i.e., generates a handshake response instruction.

[0098] In one possible implementation, the server can obtain the corresponding handshake response protocol within the protocol suite, encapsulate the third random number and the generated fifth random number with the handshake response protocol to obtain a handshake response instruction, and send it to the encryption device. Upon receiving the handshake response instruction, the encryption device can also perform the same process described above: decrypting the handshake response instruction using a decryption algorithm, determining whether the handshake response protocol is within the protocol suite, and if so, checking if the third random number is the same as a locally stored third random number; if so, executing the subsequent encryption process.

[0099] Furthermore, as another embodiment of this application, after S2014, it further includes:

[0100] In S2015, if the encryption device receives the handshake response instruction from the server within a preset first time, it determines whether the handshake response instruction contains the third random number.

[0101] In S2016, if the handshake response instruction contains the third random number, the encryption device is deemed legitimate.

[0102] In this embodiment, the encryption device can be set to a valid time period, namely the aforementioned first time period. After sending the handshake instruction, the encryption device begins calculation. If a handshake response instruction is received from the server within the aforementioned first time period, it is determined whether the encryption response instruction contains a third random number. If the handshake response instruction contains a third random number, it can be determined that the server has determined the encryption device to be legitimate, and the subsequent encryption process can be executed. Conversely, if the handshake response instruction does not contain a third random number, it is possible that the handshake response instruction was sent by another illegal server. In this case, encryption failure can be indicated, and the encryption process can be stopped.

[0103] In S2017, if the encryption device does not receive the handshake response instruction from the server within the first time period, it generates a network error message.

[0104] In this embodiment, if the encryption device does not receive a handshake response instruction from the server within a preset first time, it may be due to an abnormal communication link between the encryption device and the server, and a network abnormality prompt message can be generated at this time.

[0105] In this embodiment of the application, by configuring a first time and detecting whether the encryption device receives a handshake response instruction within the first time, it is possible to identify abnormal situations, which facilitates users to repair abnormal situations when encryption fails and improves the accuracy of abnormal identification.

[0106] Figure 4 A flowchart illustrating a firmware encryption method according to a third embodiment of the present invention is shown. See also... Figure 4 In contrast Figure 2 In the embodiment described herein, after sending a response request to the target device if the encryption device is identified as legitimate, the firmware encryption method further includes steps S401 to S403, which are detailed below:

[0107] In S401, if the encryption device receives the response information from the target device within a preset second time period, it determines whether the response information contains the first random number.

[0108] In S402, if the response information contains the first random number, the encryption device performs the step of generating encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and sends the encrypted ciphertext to the target device.

[0109] In this embodiment, the encryption device can also set a corresponding effective duration during communication with the target device. The timer starts after sending a response request to the target device. If a response is received from the target device based on the response request within the second time period, it is determined whether the response carries a pre-generated first random number. If the first random number is detected, the subsequent encryption process is executed. It should be noted that the response can also be encrypted using a preset encryption algorithm. If the encryption device cannot decrypt the response, or if the response protocol within the response is not within the preset protocol suite, encryption failure can also be identified, and the encryption process can be stopped.

[0110] In S403, if the encryption device does not receive the response information from the target device within the second time period, it generates a device abnormality prompt message.

[0111] In this embodiment, if the encryption device does not receive a response from the target device within the second time, the communication link between the device and the target device may be abnormal. In this case, a device abnormality prompt message can be generated so that the user can handle the abnormal situation.

[0112] In this embodiment of the application, by setting a second time to detect whether the communication between the encryption device and the target device is abnormal, abnormal situations can be identified in a timely manner, thereby improving the accuracy of abnormal identification.

[0113] Figure 5 A flowchart illustrating the specific implementation of firmware encryption method S203 provided in the fourth embodiment of the present invention is shown. See also... Figure 5 In contrast Figure 2-4 In any of the embodiments described above, the firmware encryption method S203 provided in this embodiment includes: S2031 to S2032, which are detailed below:

[0114] Furthermore, the step of sending a response request to the target device if the encryption device is identified as legitimate includes:

[0115] In S2031, the first random number and the preset random number generation instruction are encapsulated to obtain a random number generation instruction package containing the first random number.

[0116] In S2032, the random number generation instruction packet is encrypted using a preset second encryption algorithm to obtain the response request. The target device then decrypts the response request using a second decryption algorithm corresponding to the second encryption algorithm, extracts the random number generation instruction, generates the second random number based on the random number generation instruction, encapsulates the second random number with the response command to obtain the response information, and then sends the response information to the encryption device.

[0117] In this embodiment, the response request is specifically generated based on a random number generation instruction and a first random number generated locally by the encryption device. The encryption device can encapsulate the random number generation instruction and the first random number, and encrypt the encapsulated data to obtain the response request. When the target device receives the response request, it can decrypt it using the corresponding decryption device to obtain the first random number and the random number generation instruction. The target device will execute the random number generation instruction to generate a second random number, and encapsulate the first random number, the second random number, and the response command to obtain response information, which will then be sent to the encryption device.

[0118] In this embodiment of the application, by encapsulating the random number generation instruction with the first random number and then encrypting it, the confidentiality of the response request can be improved. Furthermore, when the target device receives the response request, it can automatically generate the corresponding second random number to complete the response, thereby improving the confidentiality of the firmware encrypted communication process.

[0119] Figure 6 A flowchart illustrating a firmware encryption method according to a fifth embodiment of the present invention is shown. See also... Figure 6 In contrast Figure 2-4 In any of the embodiments described herein, after the encryption device is authenticated by the server in response to the firmware encryption command of the target device, the method further includes steps S601 to S602, which are detailed below:

[0120] Furthermore, after authenticating the encryption device via the server in response to the firmware encryption command of the target device, the method further includes:

[0121] In S601, the encryption device receives an authentication failure instruction from the server; the authentication failure instruction is sent to the encryption device when it is detected that the encryption device is a leaking device.

[0122] In S602, in response to the authentication failure instruction, the encryption device generates an encryption abort instruction to stop the firmware encryption operation on the target device.

[0123] In this embodiment, if the server detects that the encryption device has been compromised, it can send an authentication failure command to the encryption device. The compromise scenarios include: the client program of the encryption device logging in from multiple locations simultaneously, in which case the encryption device has been compromised; or the program identifier of the encryption device being on an invalid list, i.e., the ID being invalid, in which case the encryption device has been compromised, the server can also identify the compromised encryption device, send an authentication failure command to the encryption device, and stop encryption operations on the encryption firmware.

[0124] For example, Figure 7 An interactive flowchart of a firmware encryption method provided in one embodiment of this application is shown. See also... Figure 7 As shown, this interaction flowchart combines the above... Figures 2 to 6 The interaction flow obtained by the firmware encryption method provided in multiple embodiments is as follows:

[0125] S71, the encryption device responds to the firmware encryption command, generates random number 1 (i.e. the third random number mentioned above), and encrypts the handshake communication protocol, random number 1, and the program identifier of the client program of the encryption device through the encryption algorithm to obtain the handshake command.

[0126] S72, the encryption device sends the handshake command to the server and times the process to determine whether it receives a handshake response command from the server within the first time.

[0127] S73, if the encryption device does not receive a handshake response command within the first time, the encryption process ends.

[0128] S74: When the server receives the handshake command, it determines whether the decryption was successful.

[0129] S75 If the server fails to decrypt, or if the handshake communication protocol in the handshake command is not within the protocol suite, then the handshake command will be rejected.

[0130] S76, if the server successfully decrypts the handshake command, it generates random number 2 (i.e., the fifth random number mentioned above), and encapsulates and encrypts random number 1, random number 2, and the handshake response command to generate a handshake response command, which is then sent to the encryption device.

[0131] S77, if the encryption device receives the handshake response command in the first time, it will determine whether it contains the random number 1.

[0132] S78. If the encryption device fails to decrypt the handshake response command successfully, or if the handshake response command does not contain the random number 1, it will indicate that the decryption failed and end the encryption process.

[0133] S79, the encryption device successfully decrypts the handshake response command, and the handshake response command contains random number 1, then generates random number 3 (i.e. the first random number mentioned above), and encapsulates and encrypts the random number generation command and random number 3 to obtain the response request, sends it to the target device, and starts timing to determine whether the response information from the target device is received at the second time.

[0134] S710 If the encryption device does not receive a response message within the second time, it generates a device error message and terminates the encryption process.

[0135] S711: When the target device receives a response request, it determines whether the decryption was successful.

[0136] S712 If the target device fails to decrypt, the response request is rejected.

[0137] S713, the target device successfully decrypts and responds to the random number generation command, generating random number 4 (i.e. the second random number mentioned above). Random number 4, random number 3, and the response random number command are encapsulated and encrypted to generate response information, which is then sent to the encryption device.

[0138] S714, if the encryption device receives the response information in the second time, it will determine whether the response information can be successfully decrypted.

[0139] S715, the encryption device cannot decrypt the response information, indicating encryption failure and ending the encryption process.

[0140] S716, the encryption device can decrypt the response information, extract random number 4, generate random number 5 (i.e. the fourth random number mentioned above), encapsulate and encrypt the first device identifier, random number 4 and random number 5 to obtain encrypted ciphertext, bind it with the firmware of the target device, and send the encrypted ciphertext to the target device.

[0141] S717, the target device decrypts the encrypted ciphertext and determines whether the encrypted ciphertext contains the random number 4.

[0142] S718, when the target device recognizes that the encrypted ciphertext does not contain the random number 4, it sends an encryption failure command to the encryption device.

[0143] S719, the encryption device receives an encryption failure instruction and terminates the encryption process.

[0144] S720, the target device recognizes that the encrypted ciphertext contains the random number 4, extracts the random number 4 and the first device identifier, encapsulates and encrypts them, stores them in the target device's memory, and sends an encryption success command to the encryption device.

[0145] S721, the encryption device receives the encryption success instruction and exits the encryption process.

[0146] Figure 8 The diagram illustrates a structural block diagram of a firmware encryption device according to an embodiment of the present invention. The firmware encryption device includes units for performing various operations. Figure 2 The corresponding embodiments illustrate the steps implemented by the encryption device. Please refer to [link / reference] for details. Figure 2 and Figure 2 The relevant descriptions in the corresponding embodiments are shown below. For ease of explanation, only the parts relevant to this embodiment are shown.

[0147] See Figure 8The firmware encryption method apparatus includes:

[0148] Firmware encryption response unit 81 is used to authenticate the encryption device through the server in response to the firmware encryption command of the target device.

[0149] The response request sending unit 82 is configured to send a response request to the target device if the encryption device is identified as legitimate; the response request includes a first random number.

[0150] The response information receiving unit 83 is used to receive response information fed back by the target device based on the response request; the response information includes a second random number; the second random number is generated when the target device receives the response request;

[0151] The encrypted ciphertext sending unit 84 is configured to, if the response information contains the first random number, generate encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and send the encrypted ciphertext to the target device; the encrypted ciphertext is used by the target device to authenticate the firmware based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device when the target device boots up through the firmware.

[0152] Optionally, the firmware encryption response unit 81 includes:

[0153] The program identifier acquisition unit includes acquiring the program identifier of the client program installed in the encryption device and generating a third random number;

[0154] The program identifier encapsulation unit includes generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server; the handshake instruction is used by the server to generate a handshake response instruction based on the third random number when the server identifies the encryption device as legitimate based on the handshake instruction, and then sending the handshake response instruction to the encryption device.

[0155] Optionally, the firmware encryption device further includes:

[0156] The third random number determination unit includes determining whether the handshake response instruction contains the third random number if the handshake response instruction is received from the server within a preset first time period.

[0157] The legitimacy identification unit includes determining that the encryption device is legitimate if the handshake response instruction contains the third random number;

[0158] The network anomaly unit includes generating a network anomaly message if the handshake response instruction is not received from the server within the first time period.

[0159] Optionally, the program label encapsulation unit includes:

[0160] A handshake communication protocol acquisition unit includes acquiring the handshake communication protocol corresponding to the server;

[0161] The handshake communication protocol encapsulation unit includes encapsulating the program identifier and the third random number within the handshake communication protocol, and encrypting the encapsulated handshake communication protocol using a preset first encryption algorithm to obtain the handshake instruction. The server then decrypts the handshake instruction using a first decryption algorithm associated with the first encryption algorithm, compares the handshake communication protocol with its local protocol suite, and identifies whether the program identifier is a valid identifier when the handshake communication protocol matches the protocol suite. If the program identifier is a valid identifier, the server sends the handshake response instruction back to the encryption device.

[0162] Optionally, the firmware encryption device further includes:

[0163] The first random number determination unit includes determining whether the response information received from the target device within a preset second time period contains the first random number.

[0164] The first random number encryption unit includes, if the response information contains the first random number, performing the following steps: generating encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and sending the encrypted ciphertext to the target device;

[0165] The device malfunction notification unit includes generating a device malfunction notification if no response information is received from the target device within the second time period.

[0166] Optionally, the response request sending unit 82 includes:

[0167] The random number generation instruction package generation unit includes encapsulating the first random number and a preset random number generation instruction to obtain a random number generation instruction package encapsulated with the first random number.

[0168] The random number generation instruction packet encryption unit includes encrypting the random number generation instruction packet using a preset second encryption algorithm to obtain the response request. The target device then decrypts the response request using a second decryption algorithm corresponding to the second encryption algorithm, extracts the random number generation instruction, generates a second random number based on the random number generation instruction, encapsulates the second random number and the response command to obtain the response information, and then sends the response information to the encryption device.

[0169] Optionally, the firmware encryption device also includes:

[0170] The authentication failure instruction receiving unit includes receiving the authentication failure instruction fed back by the server; the authentication failure instruction is sent to the encryption device when the encryption device is detected as a data leakage device.

[0171] The encryption abort unit includes generating an encryption abort instruction in response to the authentication failure instruction, thereby stopping the firmware encryption operation on the target device.

[0172] Therefore, the firmware encryption device provided in this embodiment of the invention can also, when encrypting the firmware in the target device, first authenticate the encryption device performing the encryption operation, and if the server identifies the encryption device as legitimate, send a response request to the target device. After receiving the response information from the target device, it confirms that the communication link between the two is reliable, and sends the encrypted ciphertext to the target device. This allows the target device to compare the device identifier in the encrypted ciphertext with the device identifier corresponding to the local device when starting the device through the firmware, in order to determine whether the firmware being run is being applied to other devices, thus achieving the purpose of authentication for the confidentiality of the firmware. Compared with existing firmware encryption technologies, the embodiments of this application do not require configuring an additional encryption chip to encrypt the firmware. Instead, a legitimate encryption device generates encrypted ciphertext containing a first device identifier for uniquely identifying the target device and a random number. Since the firmware is bound to the encrypted ciphertext, if the first device identifier corresponding to the firmware is inconsistent with the second device identifier of the device, it can be determined that the firmware is applied to other devices, thus ensuring the confidentiality of the firmware. On the other hand, the introduction of a second random number into the encrypted ciphertext can further increase the difficulty of deciphering the encrypted ciphertext, thereby improving the confidentiality of the encrypted ciphertext of the firmware.

[0173] It should be understood that, Figure 8 In the structural block diagram of the firmware encryption method apparatus shown, each module is used to perform... Figures 1 to 7 The steps in the corresponding embodiments, and for Figures 1 to 7The steps in the corresponding embodiments have been explained in detail in the above embodiments. Please refer to them for details. Figures 1 to 7 as well as Figures 1 to 7 The relevant descriptions in the corresponding embodiments will not be repeated here.

[0174] Figure 9 This is a structural block diagram of an electronic device provided in another embodiment of this application. For example... Figure 9 As shown, the electronic device 900 of this embodiment includes: a processor 910, a memory 920, and a computer program 930 stored in the memory 920 and executable on the processor 910, such as a firmware encryption method program. When the processor 910 executes the computer program 930, it implements the steps of the various embodiments of the firmware encryption methods described above, for example... Figure 2 S201 to S205 are shown. Alternatively, when the processor 910 executes the computer program 930, it implements the functions of each module in the embodiment corresponding to FIG9 above, for example... Figure 8 For details on the functions of units 81 to 84 shown, please refer to [link / reference]. Figure 8 The relevant descriptions in the corresponding embodiments.

[0175] For example, the computer program 930 may be divided into one or more modules, one or more of which are stored in the memory 920 and executed by the processor 910 to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of the computer program 930 in the electronic device 900. For example, the computer program 930 may be divided into various unit modules, each with the specific functions described above.

[0176] Electronic device 900 may include, but is not limited to, processor 910 and memory 920. Those skilled in the art will understand that... Figure 9 This is merely an example of electronic device 900 and does not constitute a limitation on electronic device 900. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0177] The processor 910 can be a central processing unit, or it can be other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays or other programmable logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0178] The memory 920 can be an internal storage unit of the electronic device 900, such as a hard disk or RAM of the electronic device 900. The memory 920 can also be an external storage device of the electronic device 900, such as a plug-in hard disk, smart memory card, flash memory card, etc., equipped on the electronic device 900. Furthermore, the memory 920 can include both internal storage units and external storage devices of the electronic device 900.

[0179] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A firmware encryption method, applied to an encryption device, characterized in that, include: In response to the firmware encryption command of the target device, the encryption device is authenticated by the server; If the encryption device is identified as legitimate, a response request is sent to the target device. The response request contains a first random number; Receive response information from the target device based on the response request; The response information contains a second random number; The second random number is generated when the target device receives the response request; If the response information contains the first random number, then an encrypted ciphertext about the firmware installed on the target device is generated based on the first device identifier of the target device and the second random number, and the encrypted ciphertext is sent to the target device; The encrypted ciphertext is used to authenticate the firmware when the target device boots the device through the firmware, based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device; The step of authenticating the encryption device via a server in response to a firmware encryption command from the target device includes: Obtain the program identifier of the client program installed in the encryption device, and generate a third random number; A handshake instruction is generated based on the program identifier and the third random number, and the handshake instruction is sent to the server; the handshake instruction is used by the server to generate a handshake response instruction based on the third random number when the server identifies the encryption device as legitimate based on the handshake instruction, and then sends the handshake response instruction to the encryption device. The step of generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server, includes: Obtain the handshake communication protocol corresponding to the server; The program identifier and the third random number are encapsulated within the handshake communication protocol, and the encapsulated handshake communication protocol is encrypted using a preset first encryption algorithm to obtain the handshake instruction. The server then decrypts the handshake instruction using a first decryption algorithm associated with the first encryption algorithm, compares the handshake communication protocol with the local protocol suite, and identifies whether the program identifier is a valid identifier when the handshake communication protocol matches the protocol suite. If the program identifier is a valid identifier, the server sends the handshake response instruction back to the encryption device.

2. The method according to claim 1, characterized in that, After generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server, the method further includes: If the handshake response instruction from the server is received within a preset first time period, it is determined whether the handshake response instruction contains the third random number. If the handshake response instruction contains the third random number, then the encryption device is deemed legitimate; If the handshake response instruction is not received from the server within the first time period, a network error message is generated.

3. The method according to claim 1, characterized in that, After sending a response request to the target device if the encryption device is identified as legitimate, the method further includes: If the response information from the target device is received within a preset second time period, it is determined whether the response information contains the first random number. If the response information contains the first random number, then the process of generating encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number is executed, and the encrypted ciphertext is sent to the target device; If no response information is received from the target device within the second time period, a device abnormality prompt message is generated.

4. The method according to any one of claims 1-3, characterized in that, If the encryption device is identified as legitimate, sending a response request to the target device includes: The first random number and the preset random number generation instruction are encapsulated to obtain a random number generation instruction package containing the first random number. The random number generation instruction packet is encrypted using a preset second encryption algorithm to obtain the response request. The target device then decrypts the response request using a second decryption algorithm corresponding to the second encryption algorithm, extracts the random number generation instruction, generates the second random number based on the random number generation instruction, and encapsulates the second random number with the response command to obtain the response information. The response information is then sent to the encryption device.

5. The method according to any one of claims 1-3, characterized in that, After authenticating the encryption device via the server in response to the firmware encryption command of the target device, the method further includes: The system receives an authentication failure instruction from the server; the authentication failure instruction is sent to the encryption device when it is detected that the encryption device is a data leakage device. In response to the authentication failure instruction, an encryption abort instruction is generated to stop the firmware encryption operation on the target device.

6. A firmware encryption device, characterized in that, include: The firmware encryption response unit is used to respond to the firmware encryption command of the target device and authenticate the encryption device through the server. The response request sending unit is configured to send a response request to the target device if the encryption device is identified as legitimate. The response request contains a first random number; A response information receiving unit is used to receive response information fed back by the target device based on the response request; The response information contains a second random number; The second random number is generated when the target device receives the response request; An encrypted ciphertext sending unit is configured to, if the response information contains the first random number, generate encrypted ciphertext about the firmware installed on the target device based on the first device identifier of the target device and the second random number, and send the encrypted ciphertext to the target device; The encrypted ciphertext is used to authenticate the firmware based on the first device identifier in the encrypted ciphertext and the second device identifier stored locally on the target device when the target device boots up using the firmware; The firmware encryption response unit includes: The program identifier acquisition unit includes acquiring the program identifier of the client program installed in the encryption device and generating a third random number; The program identifier encapsulation unit includes generating a handshake instruction based on the program identifier and the third random number, and sending the handshake instruction to the server; the handshake instruction is used by the server to generate a handshake response instruction based on the third random number when the server identifies the encryption device as legitimate based on the handshake instruction, and then sending the handshake response instruction to the encryption device. The program label encapsulation unit includes: A handshake communication protocol acquisition unit includes acquiring the handshake communication protocol corresponding to the server; The handshake communication protocol encapsulation unit includes encapsulating the program identifier and the third random number within the handshake communication protocol, and encrypting the encapsulated handshake communication protocol using a preset first encryption algorithm to obtain the handshake instruction. The server then decrypts the handshake instruction using a first decryption algorithm associated with the first encryption algorithm, compares the handshake communication protocol with its local protocol suite, and identifies whether the program identifier is a valid identifier when the handshake communication protocol matches the protocol suite. If the program identifier is a valid identifier, the server sends the handshake response instruction back to the encryption device.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images