CN114417320A

CN114417320A - System starting method and device

Info

Publication number: CN114417320A
Application number: CN202210167079.1A
Authority: CN
Inventors: 张振; 任炜彬; 赵成炜; 周东峰
Original assignee: Hangzhou Ezviz Software Co Ltd
Current assignee: Hangzhou Ezviz Software Co Ltd
Priority date: 2022-02-23
Filing date: 2022-02-23
Publication date: 2022-04-29

Abstract

The embodiment of the application provides a system starting method and a system starting device, which relate to the technical field of data security, and the method comprises the following steps: when the target system needs to be started, acquiring encrypted firmware data corresponding to the firmware of the target system; encrypting the firmware data includes: the method comprises the steps that first encrypted data and second files are obtained by encrypting the first files and the digests of the first files, and second encrypted data is obtained by encrypting the digests of the second files; decrypting the first encrypted data to obtain first decrypted data, and verifying whether the first type of file in the first decrypted data is abnormal or not; decrypting the second encrypted data to obtain second decrypted data, and verifying whether a second type of file in the encrypted firmware data is abnormal or not based on the second decrypted data; and if the first type of file in the first decrypted data and the second type of file in the encrypted firmware data are not abnormal, starting the target system. Therefore, equipment operation errors can be avoided, and the starting speed of the system is improved.

Description

System starting method and device

Technical Field

The present application relates to the field of data security technologies, and in particular, to a method and an apparatus for starting a system.

Background

As embedded devices become more widely used, their requirements for security, especially the security of the firmware of the system, become higher and higher. If the firmware of the system is tampered maliciously, the embedded device can be caused to operate incorrectly.

Therefore, a system boot method is needed to verify the firmware of the system when the embedded device boots the system, so as to avoid the embedded device running error.

Disclosure of Invention

The embodiment of the application aims to provide a system starting method and device, which can avoid equipment operation errors and improve the starting speed of a system. The specific technical scheme is as follows:

in a first aspect, to achieve the above object, an embodiment of the present application discloses a system startup method, where the method includes:

when a target system needs to be started, acquiring encrypted firmware data corresponding to firmware of the target system;

wherein the encrypting firmware data comprises: the method comprises the steps that first encrypted data obtained by encrypting a first type of file in the firmware and a summary of the first type of file, second type of file in the firmware and second encrypted data obtained by encrypting the summary of the second type of file are obtained;

decrypting the first encrypted data to obtain first decrypted data, and verifying whether a first type of file in the first decrypted data is abnormal or not;

decrypting the second encrypted data to obtain second decrypted data, and verifying whether a second type of file in the encrypted firmware data is abnormal or not based on the second decrypted data;

and starting the target system based on the first class file in the first decrypted data and the second class file in the encrypted firmware data under the condition that the verification results show that the target system is not abnormal.

Optionally, the verifying whether the first type of file in the first decrypted data is abnormal includes:

calculating the abstract of the first type of file in the first decrypted data to obtain a first abstract to be verified;

judging whether the first to-be-verified abstract is consistent with the abstract of the first type of file recorded by the first decrypted data;

if yes, determining that the first type of file in the first decrypted data is not abnormal;

if not, determining that the first type of file in the first decrypted data is abnormal.

Optionally, the first encrypted data is obtained by encrypting the first type of file and encrypted data corresponding to the digest of the first type of file;

before the determining whether the first to-be-verified digest is consistent with the digest of the first type of file of the first decrypted data record, the method further includes:

and decrypting the encrypted data part corresponding to the digest of the first type of file in the first decrypted data to obtain the digest of the first type of file recorded by the first decrypted data.

Optionally, the second encrypted data is obtained by encrypting the digest based on the digest recorded data and the digest of the digest recorded data; the abstract of the second type of file is recorded in the abstract recording data;

the verifying whether the second type of file in the encrypted firmware data is abnormal based on the second decryption data comprises:

calculating the abstract of the abstract record data in the second decrypted data to obtain a second abstract to be verified;

judging whether the second digest to be verified is consistent with the digest of the digest record data of the second decrypted data record;

if not, determining that the second type of file in the encrypted firmware data is abnormal;

and if so, verifying whether the second type of file in the encrypted firmware data is abnormal or not based on the summary record data in the second decrypted data.

Optionally, the second encrypted data is obtained by encrypting summary record data and encrypted data corresponding to a summary of the summary record data;

before the determining whether the second to-be-verified digest is consistent with the digest of the digest record data of the second decrypted data record, the method further includes:

and decrypting the encrypted data part corresponding to the abstract of the abstract record data in the second decrypted data to obtain the abstract of the abstract record data of the second decrypted data record.

Optionally, the verifying whether the second type of file in the encrypted firmware data is abnormal based on the digest record data in the second decrypted data includes:

calculating the abstract of the second type of file in the encrypted firmware data to obtain a third abstract to be verified;

judging whether the third digest to be verified is consistent with the digest of the second file recorded by the digest recording data in the second decrypted data or not;

if yes, determining that the second type of file in the encrypted firmware data is not abnormal;

if not, determining that the second type of file in the encrypted firmware data is abnormal.

Optionally, the encrypting the firmware data further includes: third encrypted data obtained by encrypting the digest of the third type of file in the firmware;

the method further comprises the following steps:

after the target system is started, when the third type of file needs to be loaded, verifying whether the third type of file recorded in the encrypted firmware data is abnormal or not based on the third encrypted data;

and if not, loading a third type of file recorded in the encrypted firmware data.

Optionally, the method further includes:

and if the verification result indicating the abnormity exists, starting the alternative system corresponding to the target system.

In a second aspect, in order to achieve the above object, an embodiment of the present application discloses a system starting apparatus, including:

the system comprises an encrypted firmware data acquisition module, a data processing module and a data processing module, wherein the encrypted firmware data acquisition module is used for acquiring encrypted firmware data corresponding to firmware of a target system when the target system needs to be started;

the first verification module is used for decrypting the first encrypted data to obtain first decrypted data and verifying whether a first type of file in the first decrypted data is abnormal or not;

the second verification module is used for decrypting the second encrypted data to obtain second decrypted data and verifying whether a second type of file in the encrypted firmware data is abnormal or not based on the second decrypted data;

and the system starting module is used for starting the target system based on the first class file in the first decrypted data and the second class file in the encrypted firmware data under the condition that the verification results show that the abnormality does not exist.

Optionally, the first verification module includes:

the first to-be-verified abstract acquiring submodule is used for calculating the abstract of the first type of file in the first decrypted data to obtain a first to-be-verified abstract;

the first judgment submodule is used for judging whether the first to-be-verified abstract is consistent with the abstract of the first type of file recorded by the first decrypted data; if yes, triggering a first determining submodule, and if not, triggering a second determining submodule;

the first determining submodule is used for determining that the first class of files in the first decrypted data are not abnormal;

the second determining submodule is used for determining that the first type of file in the first decrypted data is abnormal.

the device further comprises:

the first decryption submodule is configured to decrypt an encrypted data portion corresponding to the digest of the first type of file in the first decrypted data to obtain the digest of the first type of file recorded in the first decrypted data before the judgment is made that whether the first to-be-verified digest is consistent with the digest of the first type of file recorded in the first decrypted data.

the second authentication module comprising:

the second to-be-verified abstract acquiring submodule is used for calculating the abstract of the abstract record data in the second decrypted data to obtain a second to-be-verified abstract;

a second judgment submodule, configured to judge whether the second digest to be verified is consistent with the digest of the digest record data of the second decrypted data record; if not, triggering a third determining submodule, and if so, triggering a verification submodule;

the third determining submodule is used for determining that the second type of file in the encrypted firmware data is abnormal;

and the verification sub-module is used for verifying whether the second type of file in the encrypted firmware data is abnormal or not based on the summary record data in the second decrypted data.

the device further comprises:

and the second decryption submodule is used for decrypting an encrypted data part corresponding to the abstract of the abstract record data in the second decrypted data to obtain the abstract of the abstract record data in the second decrypted data record before judging whether the second to-be-verified abstract is consistent with the abstract of the abstract record data in the second decrypted data record.

Optionally, the verification sub-module is specifically configured to calculate an abstract of a second type of file in the encrypted firmware data to obtain a third to-be-verified abstract;

the device further comprises:

a third verification module, configured to verify, based on the third encrypted data, whether a third type of file recorded in the encrypted firmware data is abnormal when the third type of file needs to be loaded after the target system is started; if not, triggering the loading module;

and the loading module is used for loading the third type of file recorded in the encrypted firmware data.

Optionally, the apparatus further comprises:

and the exception handling module is used for starting the alternative system corresponding to the target system if the verification result indicating the exception exists.

In another aspect of this application, in order to achieve the above object, an embodiment of this application further discloses an electronic device, where the electronic device includes a processor, a communication interface, a memory, and a communication bus, where the processor, the communication interface, and the memory complete communication with each other through the communication bus;

the memory is used for storing a computer program;

the processor is configured to implement the system booting method according to any one of the above descriptions when executing the program stored in the memory.

In another aspect of this application, to achieve the above object, this application further discloses an electronic device, including a data verification device and a data decryption device supporting hardware decryption;

wherein, the data decryption device is used for executing the data decryption step consistent with the data decryption algorithm supported by the data decryption device in any one of the methods; the data verification means is arranged to perform steps other than the data decryption step.

In yet another aspect of this application implementation, a computer-readable storage medium is further provided, in which a computer program is stored, and the computer program, when executed by a processor, implements the system startup method as described in any of the above.

The present invention also provides a computer program product containing instructions, which when run on a computer, causes the computer to perform any of the system startup methods described above.

The embodiment of the application has the following beneficial effects:

according to the system starting method provided by the embodiment of the application, when the target system needs to be started, encrypted firmware data corresponding to the firmware of the target system is obtained; wherein encrypting the firmware data comprises: the method comprises the steps that first encrypted data obtained by encrypting a first type of file in firmware and a summary of the first type of file, a second type of file in firmware and second encrypted data obtained by encrypting the summary of the second type of file are obtained; decrypting the first encrypted data to obtain first decrypted data, and verifying whether the first type of file in the first decrypted data is abnormal or not; decrypting the second encrypted data to obtain second decrypted data, and verifying whether a second type of file in the encrypted firmware data is abnormal or not based on the second decrypted data; and starting the target system based on the first class file in the first decrypted data and the second class file in the encrypted firmware data under the condition that the verification results show that the abnormality does not exist.

Based on the above processing, when the target system needs to be started, the encrypted data (i.e. encrypted firmware data) corresponding to the firmware of the target system can be verified, and when the verification is not abnormal, the target system is started based on the encrypted firmware data, so that the device operation error can be avoided. The second type file is recorded in the encrypted firmware data in the clear text, that is, the digest of the second type file is encrypted in the encrypted firmware data, and the second type file is not encrypted. Correspondingly, when the target system needs to be started, the verification of the second type of file can be realized only by decrypting the encrypted data of the abstract of the second type of file, and the encrypted data of the second type of file does not need to be decrypted. Compared with the second type of file, the data volume of the digest of the second type of file is smaller, so that the method provided by the embodiment of the application can reduce the data volume of decryption, shorten the time length of data verification and improve the starting speed of the system.

Of course, not all advantages described above need to be achieved at the same time in the practice of any one product or method of the present application.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and it is also obvious for a person skilled in the art to obtain other embodiments according to the drawings.

Fig. 1 is a flowchart of a system booting method according to an embodiment of the present application;

fig. 2 is a flowchart of another system starting method according to an embodiment of the present application;

fig. 3 is a flowchart of another system starting method provided in the embodiment of the present application;

fig. 4 is a flowchart of another system starting method provided in the embodiment of the present application;

fig. 5 is a flowchart of another system starting method provided in the embodiment of the present application;

fig. 6 is a flowchart of another system starting method according to an embodiment of the present application;

fig. 7 is a schematic diagram of a principle of generating encrypted firmware data according to an embodiment of the present application;

fig. 8 is a flowchart of a system booting method according to an embodiment of the present application;

fig. 9 is a block diagram of a system starting apparatus according to an embodiment of the present application;

fig. 10 is a block diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments that can be derived by one of ordinary skill in the art from the description herein are intended to be within the scope of the present disclosure.

The embodiment of the application provides a system starting method, which can be applied to electronic equipment, and when a target system needs to be started, the electronic equipment can acquire encrypted data (namely encrypted firmware data) corresponding to firmware of the target system, and verify the encrypted firmware data based on the method provided by the embodiment of the application so as to start the target system.

In one implementation, the electronic device may be an embedded device, and the electronic device may include a decryption chip. Specifically, the electronic device may verify the encrypted firmware data through the decryption chip.

Referring to fig. 1, fig. 1 is a flowchart of a system startup method provided in an embodiment of the present application, where the method may include the following steps:

s101: when the target system needs to be started, encrypted firmware data corresponding to the firmware of the target system is obtained.

Wherein encrypting the firmware data comprises: the file encryption method comprises the steps of encrypting first encrypted data obtained by encrypting a first type of file in firmware and a digest of the first type of file, encrypting a second type of file in the firmware, and encrypting second encrypted data obtained by encrypting the digest of the second type of file.

S102: and decrypting the first encrypted data to obtain first decrypted data, and verifying whether the first type of file in the first decrypted data is abnormal or not.

S103: and decrypting the second encrypted data to obtain second decrypted data, and verifying whether the second type of file in the encrypted firmware data is abnormal or not based on the second decrypted data.

S104: and starting the target system based on the first class file in the first decrypted data and the second class file in the encrypted firmware data under the condition that the verification results show that the abnormality does not exist.

The system starting method provided by the embodiment of the application can verify the encrypted data (namely, encrypted firmware data) corresponding to the firmware of the target system when the target system needs to be started, and can avoid equipment operation errors when the target system is started based on the encrypted firmware data under the condition that the verification is not abnormal.

The second type file is recorded in the encrypted firmware data in the clear text, that is, the digest of the second type file is encrypted in the encrypted firmware data, and the second type file is not encrypted. Correspondingly, when the target system needs to be started, the verification of the second type of file can be realized only by decrypting the encrypted data of the abstract of the second type of file, and the encrypted data of the second type of file does not need to be decrypted. Compared with the second type of file, the data volume of the digest of the second type of file is smaller, so that the method provided by the embodiment of the application can reduce the data volume of decryption, shorten the time length of data verification and improve the starting speed of the system.

For step S101, if the electronic device is an embedded device, the target system may be an embedded system, for example, a Linux system. The firmware in the embodiment of the present application may include program files (e.g., program files such as a file system, a kernel, and a U-Boot (a Boot loader mainly used for an embedded system)) and resource files (e.g., resource files such as a voice package) of a target system. Based on the file in the firmware, the electronic device can boot the target system.

In one implementation, during a production process of the electronic device, encrypted firmware data corresponding to firmware of a target system may be written into the electronic device. For example, the data is written into an Electrically Erasable read only memory (EEPROM) or a Flash chip of the electronic device. Correspondingly, when the target system needs to be started, the electronic device may obtain the written encrypted firmware data and perform processing according to the method provided by the embodiment of the present application. In addition, during the use process of the electronic device, the user can update the encrypted firmware data in the electronic device through a specified firmware upgrading program so as to realize the version upgrading of the firmware.

The first encrypted data is obtained by encrypting the first type of file in the firmware and the digest of the first type of file, that is, when the first encrypted data is generated, the digest of the first type of file may be calculated first, and then the first encrypted data is obtained by encrypting the first type of file and the digest of the first type of file.

The first type of file may be one file or a plurality of files. If the first type of file is multiple, for each first type of file, first encrypted data corresponding to the first type of file may be generated.

In one implementation, the first class of files may be determined based on the importance of each file in the firmware. For example, the first type of file may be a file of higher importance in the firmware that is needed to boot the target system. For example, for a file system, a kernel, a U-Boot and other program files, if a malicious attacker obtains the plaintext of the file, the malicious attacker may analyze vulnerabilities in the file through static state and debugging, and further attack the electronic device in the running process of the electronic device. That is, it is necessary to ensure that the file is not tampered, and it is also necessary to ensure that a malicious attacker cannot obtain the plaintext of the file. Therefore, such files can be regarded as a first type of file, that is, in the encrypted firmware data, the files exist in the form of encrypted data, and thus, the files can be prevented from being disassembled by a malicious attacker. That is, the first type of file may be a file in the encrypted firmware data that needs to exist in the form of encrypted data.

The second encrypted data is obtained by encrypting based on the digest of the second type of file in the firmware, that is, when the second encrypted data is generated, the digest of the second type of file may be calculated first, and then the second encrypted data is obtained by encrypting based on the digest of the second type of file. The second type file may be one or more. If there are a plurality of second-type files, each second-type file may correspond to one second encrypted data, that is, the second encrypted data is generated based on the digest of each second-type file.

In one implementation, the second class of files may be determined based on the importance of each file in the firmware. For example, the second type of file may be a less important file in the firmware that is needed to boot the target system. For example, for resource files such as voice packets, even if a malicious attacker acquires the plaintext of the files, the electronic device is not attacked in the operation process. Therefore, in order to reduce the amount of data that needs to be decrypted when the electronic device starts the target system, such a file may be used as the second type of file, that is, when generating the encrypted firmware data, the file may not be encrypted, but a digest of the file may be encrypted. In the encrypted firmware data, the file of this type exists in the form of plaintext. The second type of file is a file that may exist in the encrypted firmware data in the clear, i.e., a file that does not need to be encrypted.

For step S102, the first encrypted data may be obtained by encrypting in advance based on a key of a symmetric encryption algorithm. For example, the symmetric Encryption algorithm may be an AES (Advanced Encryption Standard) Encryption algorithm, or may be a DES (Data Encryption Standard) Encryption algorithm, but is not limited thereto. Accordingly, the electronic device may decrypt the first encrypted data based on the key to obtain the first decrypted data. The first decryption data includes a data portion (which may be referred to as a first data portion) representing a first type of file, and a data portion (which may be referred to as a second data portion) representing a digest of the first type of file. Since the encrypted firmware data may be tampered with maliciously, the first data portion may be the first type of file, and may also be a tampered file of the first type of file.

In one embodiment, referring to fig. 2, on the basis of fig. 1, the step S102 may include the following steps:

s1021: and decrypting the first encrypted data to obtain first decrypted data, and calculating the abstract of the first class of files in the first decrypted data to obtain a first abstract to be verified.

S1022: judging whether the first to-be-verified abstract is consistent with the abstract of the first type of file recorded by the first decrypted data; if yes, go to step S1023, otherwise go to step S1024.

S1023: it is determined that the first type of file in the first decrypted data is not anomalous.

S1024: it is determined that the first type of file in the first decrypted data is anomalous.

In one implementation, after obtaining the first data portion, the electronic device may calculate a digest (i.e., the first to-be-verified digest) of the first data portion based on a digest algorithm. For example, the Digest Algorithm may be an MD (Message Digest) Algorithm, or may be an SHA (Secure Hash Algorithm), or may be a MAC (Message Authentication Code) Algorithm, but is not limited thereto. It will be appreciated that the electronic device calculates the digest algorithm used by the first digest to be verified, consistent with the digest algorithm used in generating the first encrypted data.

If the first to-be-verified digest is consistent with the digest of the first type file recorded in the first decrypted data, it is indicated that the first data portion is the first type file and is not tampered, and therefore it can be determined that the first type file in the first decrypted data is not abnormal, and conversely, it is determined that the first type file in the first decrypted data is abnormal.

It is understood that step S103 may not be performed if it is determined that the first type file is abnormal. That is, step S103 may be performed in a case where it is determined that the first-type file is not abnormal.

In one implementation, when the first encrypted data is generated, the first type file and the digest of the first type file may be encrypted, and the encrypted result is the first encrypted data. Correspondingly, the second data portion obtained by decrypting the first encrypted data is a digest of the first type of file (i.e., a digest of the first type of file recorded by the first decrypted data).

In one implementation, in order to further improve the security of the data, the first encrypted data is obtained by encrypting the first type of file and encrypted data corresponding to the digest of the first type of file. Accordingly, referring to fig. 3, on the basis of fig. 2, before the step S1022 described above, the method may further include the steps of:

s105: and decrypting the encrypted data part corresponding to the digest of the first type of file in the first decrypted data to obtain the digest of the first type of file recorded by the first decrypted data.

In one implementation, when generating the first encrypted data, the digest of the first type of file may be encrypted based on a private key of an asymmetric encryption algorithm, and then, an encryption result of the asymmetric encryption (that is, encrypted data corresponding to the digest of the first type of file) and the first type of file may be encrypted, where the encryption result is the first encrypted data. Correspondingly, the second data part obtained by decrypting the first encrypted data is the encrypted data corresponding to the digest of the first type of file. For example, the asymmetric encryption Algorithm may be an RSA encryption Algorithm, or may be a DSA (Digital Signature Algorithm), but is not limited thereto.

Accordingly, the electronic device may decrypt the second data portion based on the public key corresponding to the private key. If the decryption is not successful, the second data part is abnormal, and further the electronic equipment can determine that the first type of file is abnormal.

On the contrary, if the decryption is successful, it is indicated that the second data portion is not abnormal, and the decryption result is the abstract of the first type of file, and further, the electronic device can verify the first data portion by using the decryption result of the second data portion. That is, the electronic device may then verify whether the first type of file in the first decrypted data is abnormal based on the above steps S1022 to S1024.

Based on the processing, whether the second data part is abnormal or not can be verified, and the first data part is verified based on the second data part under the condition that the second data part is not abnormal, so that the data safety can be further improved, and the operation error of equipment can be avoided.

For step S103, the second encrypted data may be obtained by encrypting in advance based on a key of a symmetric encryption algorithm. For example, the symmetric encryption algorithm may be an AES encryption algorithm, or may also be a DES encryption algorithm, but is not limited thereto. Accordingly, the electronic device may decrypt the second encrypted data based on the key to obtain second decrypted data. The second decryption data includes a data portion (which may be referred to as a third data portion) representing a digest of the second type of file.

In one implementation, when generating the second encrypted data, the digest of the second type of file may be calculated based on a digest algorithm, and then the digest of the second type of file is encrypted based on a symmetric encryption algorithm, where the encryption result is the second encrypted data. Correspondingly, the third data part obtained by decrypting the second encrypted data is the abstract of the second type of file. For example, the digest algorithm may be an MD algorithm, or may also be an SHA algorithm, or may also be a MAC algorithm, but is not limited thereto.

Further, after obtaining the third data portion, the electronic device may calculate a digest of the second type of file (i.e., a second to-be-verified digest) in the encrypted firmware data based on a digest algorithm. It will be appreciated that the electronic device calculates the digest algorithm used by the second digest to be verified, consistent with the digest algorithm used in generating the second encrypted data.

If the second digest to be verified is consistent with the digest obtained by decrypting the second encrypted data, the electronic device may determine that the second type of file is not abnormal, otherwise, the electronic device may determine that the second type of file is abnormal.

Step S102 and step S103 may be executed sequentially or simultaneously, that is, the execution order between the two is not limited in this embodiment of the application.

In one implementation, to further improve the security of the data, the second encrypted data is obtained by encrypting based on the digest recorded data and the digest of the digest recorded data. The abstract of the second type file is recorded in the abstract recording data. That is, if there is one second-type file, the digest of the second-type file is recorded in the digest recording data, and if there are a plurality of second-type files, the digest of each second-type file is recorded in the digest recording data. In addition, the summary record data may also record an identifier of the second type file corresponding to each summary, for example, the identifier may be a name of the second type file.

Accordingly, referring to fig. 4, on the basis of fig. 1, the step S103 may include the following steps:

s1031: and calculating the abstract of the abstract record data in the second decrypted data to obtain a second abstract to be verified.

S1032: judging whether the second digest to be verified is consistent with the digest of the digest record data of the second decrypted data record; if not, go to step S1033, and if so, go to step S1034.

S1033: a second type of file exception in the encrypted firmware data is determined.

S1034: and verifying whether the second type of file in the encrypted firmware data is abnormal or not based on the summary record data in the second decrypted data.

In the embodiment of the present application, if the second digest to be verified is not consistent with the digest of the digest record data of the second decrypted data record, it is indicated that the second encrypted data may be tampered, and it may be determined that the second type of file is abnormal.

Based on the processing, whether the second encrypted data is abnormal or not can be verified, and under the condition that the second encrypted data is not abnormal, the second type of files in the encrypted firmware data are verified based on the summary record data, so that the data safety can be further improved, and the operation error of equipment can be avoided.

It is understood that step S102 may not be performed if it is determined that the second type file is abnormal. That is, step S102 may be performed in a case where it is determined that the second-class file is not abnormal.

In one implementation, when generating the second encrypted data, the digest of the second type file may be calculated based on a digest algorithm to obtain digest recorded data, then the digest of the digest recorded data may be calculated based on the digest algorithm, and further, the digest of the digest recorded data and the digest of the digest recorded data may be encrypted based on a symmetric encryption algorithm, with the encryption result being the second encrypted data.

Correspondingly, the decryption result of decrypting the second encrypted data includes: a fourth data portion representing summary record data, and a fifth data portion representing a summary of the summary record data.

Then, the electronic device may calculate a digest of the fourth data portion, and if the calculated digest is consistent with the fifth data portion and indicates that the decryption result for decrypting the second encrypted data is not abnormal, the electronic device may verify whether the second type of file in the encrypted firmware data is abnormal based on the digest recorded in the fourth data portion.

In one embodiment, to further improve the security of the data, the second encrypted data is obtained by encrypting the digest record data and the encrypted data corresponding to the digest of the digest record data. Accordingly, referring to fig. 5, on the basis of fig. 4, before the step S1032, the method may further include the steps of:

s106: and decrypting the encrypted data part corresponding to the abstract of the abstract record data in the second decrypted data to obtain the abstract of the abstract record data of the second decrypted data record.

In one implementation, when generating the second encrypted data, the digest of the second type file may be calculated based on a digest algorithm to obtain digest recorded data, then the digest of the digest recorded data may be calculated based on the digest algorithm, further, the digest of the digest recorded data may be encrypted based on an asymmetric encryption algorithm, then, the encrypted data corresponding to the digest of the digest recorded data and the digest of the digest recorded data may be encrypted based on a symmetric encryption algorithm, and the encryption result is the second encrypted data.

Correspondingly, the decryption result of decrypting the second encrypted data includes: a fourth data portion representing digest recorded data, and a sixth data portion representing encrypted data corresponding to the digest of the digest recorded data.

Then, the electronic device may decrypt the sixth data portion, and the decryption result indicates the digest of the digest record data of the second decrypted data record, and further, the electronic device may verify whether the second to-be-verified digest is consistent with the digest of the digest record data of the second decrypted data record based on step S1032, and perform corresponding processing.

Based on the above processing, in the firmware encrypted data, the digest of the digest recorded data can be encrypted, thereby improving the security of the data. Correspondingly, when the target system needs to be started, whether the summary record data in the firmware encrypted data is abnormal or not can be verified, and the second type of files in the encrypted firmware data are verified based on the summary record data under the condition that the summary record data is not abnormal, so that the data safety can be further improved, and the equipment operation error can be avoided.

In one embodiment, referring to fig. 6, on the basis of fig. 4, the step S1034 may include the following steps:

s10341: and calculating the abstract of the second class file in the encrypted firmware data to obtain a third abstract to be verified.

S10342: judging whether the third digest to be verified is consistent with the digest of the second type file recorded by the digest recording data in the second decrypted data or not; if so, step S10343 is performed, and if not, step S10344 is performed.

S10343: determining that the second type of file in the encrypted firmware data is not abnormal.

S10344: a second type of file exception in the encrypted firmware data is determined.

Steps S10341 to S10344 are similar to steps S1021 to S1024 described above, and reference is made to the detailed description of the above embodiments.

In one embodiment, encrypting the firmware data further comprises: and third encrypted data obtained by encrypting the digest of the third type of file in the firmware, wherein correspondingly, the method further comprises the following steps:

the method comprises the following steps: after the target system is started, when a third type of file needs to be loaded, verifying whether the third type of file recorded in the encrypted firmware data is abnormal or not based on third encrypted data; if not, executing the step two.

Step two: and loading the third type file recorded in the encrypted firmware data.

For example, the third type of file may be a file other than a file required in the process of booting the target system. For the files, after the electronic equipment starts the target system and needs to be loaded, verification is performed, so that the data verification duration can be shortened, and the starting speed of the system is increased.

The third type of file may be similar to the first type of file, i.e., the encrypted firmware data may include encrypted data encrypted based on the third type of file and a digest of the third type of file. Accordingly, the way of verifying whether the third type of file recorded in the encrypted firmware data is abnormal is similar to the way of verifying whether the first type of file in the first decrypted data is abnormal.

Alternatively, the third type of file may be similar to the second type of file, that is, the encrypted firmware data includes the third type of file and encrypted data obtained by encrypting the third type of file based on a digest of the third type of file. Accordingly, the way of verifying whether the third type of file recorded in the encrypted firmware data is abnormal is similar to the way of verifying whether the second type of file in the encrypted firmware data is abnormal.

In addition, if the third type file recorded in the encrypted firmware data is determined to be abnormal, a warning may be issued, and an alternative system corresponding to the target system may be started.

In one embodiment, the method may further comprise the steps of:

In the embodiment of the present application, when one of the following preset conditions is met, the electronic device may start an alternative system corresponding to the target system. The preset conditions include: the file exception of the first type in the first decrypted data, the file exception of the second type in the encrypted firmware data, and the file exception of the third type recorded in the encrypted firmware data.

The alternative system may be a backup system of the target system, for example, the backup system may be a system corresponding to a historical version of firmware. Or, the alternative system may be a small system corresponding to the target system, for example, the small system is a system capable of performing data recovery on the firmware of the target system.

In one embodiment, when it is determined that neither the first type file nor the second type file is abnormal, redundant data in the encrypted firmware data may also be deleted. The redundant data may include invalid data, malicious programs, etc. that a malicious attacker adds in the encrypted firmware data. For example, the electronic device can determine that data in the encrypted firmware data that does not conform to the specified encryption format is redundant data. Based on the above processing, the reliability of the operation of the apparatus can be further improved.

Referring to fig. 7, fig. 7 is a schematic diagram of a principle of generating encrypted firmware data according to an embodiment of the present application.

For a first type of file (namely, a file which needs to be encrypted, a key process) and the like in the firmware, the signature of the file and the digest of the file (namely, encrypted data obtained by asymmetrically encrypting the digest) is symmetrically encrypted to obtain first encrypted data (namely, encrypted process and the like).

For the second type of files in the firmware (i.e. files without encryption, file 1, file 2 …, file n), the signature of the digest of each second type of file is calculated and recorded in the filelist. And calculating the abstract of the abstract record data, carrying out asymmetric encryption on the abstract, and then, carrying out symmetric encryption on the encrypted result of the asymmetric encryption and the abstract record data to obtain second encrypted data (namely, filelist.

And then, carrying out application program packaging (Pack Appimg) on the first encrypted data, each second type of file and the second encrypted data to obtain encrypted firmware data (app.

Based on the encrypted firmware data generated in fig. 7, referring to fig. 8, fig. 8 is a flowchart of a system boot method according to an embodiment of the present application.

The electronic device may load a Filelist file (i.e., the second encrypted data) in the encrypted firmware data, and then determine whether the Filelist decryption check is successful. That is, the second encrypted data is decrypted to obtain second decrypted data. Then, calculating the abstract of the abstract record data in the second decrypted data, decrypting the encrypted data part corresponding to the abstract of the abstract record data in the second decrypted data, and verifying whether the calculated abstract is consistent with the decrypted result. If the two are consistent, the decryption and the verification are successful, otherwise, the decryption and the verification are failed.

And if the decryption and the signature verification are determined to be failed, stopping starting the target system, and switching to a small system/a backup system.

And if the decryption and the verification are determined to be successful, traversing all files under the file partition according to the Filelist, calculating the abstract, and skipping over the encrypted files. Namely, calculating the digest of the second type file in the encrypted firmware data, and acquiring the digest of the second type file recorded in the digest recording data.

Then, whether the files are all matched is judged, namely, whether the calculated abstract of the second type file is consistent with the abstract recorded in the abstract recording data (namely, filelist. If the parts are not completely consistent, the target system is stopped to be started and the small system/backup system is switched to when the parts are not completely matched.

If all the files are consistent, all the files are determined to be matched, and whether the encrypted files are decrypted successfully is judged. The method comprises the steps of decrypting first encrypted data in encrypted firmware data to obtain first decrypted data, calculating the digest of a first type of file in the first decrypted data, and decrypting an encrypted data part corresponding to the digest of the first type of file in the first decrypted data. If the calculated abstract is consistent with the decryption result, the encrypted file is determined to be decrypted successfully, the redundant data can be deleted, and the target system is started based on the first type of file and the second type of file in the encrypted firmware data. And if the calculated abstract is inconsistent with the decryption result, determining that the decryption of the encrypted file fails, stopping starting the target system, and switching to a small system/backup system.

Based on the same inventive concept, the embodiment of the application also provides the electronic equipment, and the electronic equipment comprises a data verification device and a data decryption device supporting hardware decryption.

The data decryption device is used for executing the data decryption step consistent with the data decryption algorithm supported by the data decryption device in the embodiment; the data verification means is arranged to perform steps other than the data decryption step.

In the embodiment of the present application, if the electronic device supports hardware decryption, when the target system needs to be started, the processing of data decryption may be executed by a device (i.e., a data decryption device, such as a decryption chip) that supports hardware decryption in the electronic device, so that the speed of data verification can be increased, and the starting speed of the system can be further increased.

For example, if the decryption chip in the electronic device supports hardware RSA, the processing of performing decryption based on the RSA algorithm in the above steps may be performed by the decryption chip, and the rest of the processing steps may be performed by software. If the decryption chip in the electronic device supports the hardware RSA and the hardware AES, the processing of decrypting based on the RSA algorithm and the AES algorithm in the above steps may be performed by the decryption chip, and the rest of the processing steps may be completed by software. If the decryption chip in the electronic device supports hardware AES, the decryption chip can perform decryption based on the AES algorithm in the above steps, and the rest of the processing steps can be completed through software. For example, if a decryption chip in the electronic device supports hardware AES, a key corresponding to an AES algorithm may be written in an OTP (One Time Programmable) area of the electronic device in advance, and subsequently, the electronic device may obtain the key from the OTP area and decrypt the key. Therefore, the system starting method provided by the embodiment of the application can be suitable for electronic equipment with different configurations, and the application range of the method is improved.

Based on the same inventive concept, the present application further provides a system starting apparatus, referring to fig. 9, where fig. 9 is a structural diagram of the system starting apparatus provided in the present application, and the apparatus may include:

an encrypted firmware data obtaining module 901, configured to obtain, when a target system needs to be started, encrypted firmware data corresponding to firmware of the target system;

a first verification module 902, configured to decrypt the first encrypted data to obtain first decrypted data, and verify whether a first type of file in the first decrypted data is abnormal;

a second verification module 903, configured to decrypt the second encrypted data to obtain second decrypted data, and verify whether a second type of file in the encrypted firmware data is abnormal based on the second decrypted data;

a system starting module 904, configured to start the target system based on the first class of file in the first decrypted data and the second class of file in the encrypted firmware data when both the verification results indicate that no exception exists.

Optionally, the first verification module 902 includes:

the device further comprises:

the second verification module 903 includes:

the device further comprises:

Optionally, the apparatus further comprises:

The embodiment of the present application further provides an electronic device, as shown in fig. 10, which includes a processor 1001, a communication interface 1002, a memory 1003 and a communication bus 1004, wherein the processor 1001, the communication interface 1002 and the memory 1003 complete mutual communication through the communication bus 1004,

a memory 1003 for storing a computer program;

the processor 1001 is configured to implement the following steps when executing the program stored in the memory 1003:

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.

The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

In yet another embodiment provided by the present application, a computer-readable storage medium is further provided, in which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any of the above-mentioned system startup methods.

In yet another embodiment provided by the present application, there is also provided a computer program product containing instructions which, when run on a computer, cause the computer to perform any of the system startup methods of the above embodiments.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the application to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus, the electronic device, the computer-readable storage medium, and the computer program product embodiments, since they are substantially similar to the method embodiments, the description is relatively simple, and for the relevant points, reference may be made to the partial description of the method embodiments.

The above description is only for the preferred embodiment of the present application and is not intended to limit the scope of the present application. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application are included in the protection scope of the present application.

Claims

1. A method for system startup, the method comprising:

2. The method according to claim 1, wherein said verifying whether the first type of file in the first decrypted data is abnormal comprises:

3. The method according to claim 2, wherein the first encrypted data is obtained by encrypting the first type of file and encrypted data corresponding to the digest of the first type of file;

4. The method according to claim 1, wherein the second encrypted data is encrypted based on digest recorded data and a digest of the digest recorded data; the abstract of the second type of file is recorded in the abstract recording data;

5. The method according to claim 4, wherein the second encrypted data is obtained by encrypting the digest recording data and encrypted data corresponding to the digest of the digest recording data;

6. The method of claim 4, wherein verifying whether the second type of file in the encrypted firmware data is abnormal based on the digest record data in the second decrypted data comprises:

7. The method of claim 1, wherein encrypting the firmware data further comprises: third encrypted data obtained by encrypting the digest of the third type of file in the firmware;

the method further comprises the following steps:

8. The method of claim 1, further comprising:

9. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;

a memory for storing a computer program;

a processor for implementing the method steps of any of claims 1 to 8 when executing a program stored in the memory.

10. An electronic device, comprising data verification means and data decryption means supporting hardware decryption;

wherein the data decryption device is configured to perform the data decryption step in accordance with the data decryption algorithm supported by the data decryption device in the method according to any one of claims 1 to 8; the data verification means is arranged to perform steps other than the data decryption step.

11. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method steps of any one of the claims 1-8.