CN106295363A - Startup calibration method and device - Google Patents

Abstract

The disclosure discloses a power-on verification method and device, which belong to the field of embedded technology. The method includes: detecting whether the terminal is a non-test terminal, and when it is determined that the terminal is a non-test terminal, verifying the signature through the Kernel layer using a public key, and the signature is a signature generated according to a private key that does not match the public key , when the verification fails, it indicates the end of the verification; solves the problem of low security caused by running the test version of the Rom package in the terminal; by setting a set of matching keys and a set of non-matching keys in the terminal, It achieves the effect that the non-test terminal cannot be successfully started due to verification failure, and the security of the terminal is guaranteed.

Description

Power-on verification method and device

technical field

The present disclosure relates to the field of embedded technology, in particular to a method and device for power-on verification.

Background technique

Android (Android) system is a kind of open source operating system based on Linux, and the system source code of Android system can be packaged into Rom image (ReadOnlyMemory image, read-only memory image), and Romimage is also called Rom package. When the Rom package is written into the Rom of a terminal such as a mobile phone or a tablet computer, the terminal runs the system source code in the Rom package by loading the Rom package.

The current Rom package is mainly divided into two types: official version and test version. The file system of the terminal with the official version of the Rom package stored in the Rom usually does not support root (super user) permissions, and the terminal with the test version of the Rom package stored in the Rom The file system usually supports root privileges, where root has the highest privileges of the system, so when the Rom of the test version is installed in the terminal used by the user, any application in the terminal can obtain root privileges, And use the root authority to read the user's private data stored in the terminal.

Contents of the invention

In order to solve the problem of low security of a terminal caused by running a test version of Rom, the present disclosure provides a method and device for power-on verification. Described technical scheme is as follows:

According to the first aspect of the embodiments of the present disclosure, there is provided a boot-up verification method, the method is used in a terminal, and the terminal at least includes a hardware layer, a Kernel (kernel) layer, a Bootloader (boot loader) layer, and a file system layer, The public key is stored in the Kernel layer, and the Bootloader layer carries a signature. The method includes:

Detect whether the terminal is a non-test terminal;

When it is determined that the terminal is not a test terminal, the signature is verified using the public key through the Kernel layer. The signature is a signature generated based on the private key. The private key does not match the public key. When the verification fails, it is instructed to end the verification .

Optionally, detecting whether the terminal is a non-test terminal includes:

Detecting whether the terminal contains a preset circuit structure, the preset circuit structure is used to indicate that the terminal is a terminal for testing;

If the terminal does not include the preset circuit structure, it is determined that the terminal is not a terminal for testing.

Optionally, detect whether the terminal contains a preset circuit structure, including:

Detect whether a preset circuit structure is included in the trusted area of the hardware layer. The trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications.

Optionally, detecting whether the terminal is a non-test terminal includes:

Detecting whether the terminal contains a preset identifier, where the preset identifier is an identifier used to indicate that the terminal is a terminal for testing;

If the terminal does not contain the preset identifier, it is determined that the terminal is not a terminal for testing.

Optionally, detect whether the terminal contains a preset identifier, including:

Detect whether a preset identifier is included in the trusted storage area of the hardware layer. The trusted storage area is an area in the hardware layer that is prohibited from being directly accessed by applications.

According to the second aspect of the embodiments of the present disclosure, a boot verification device is provided, which is used in a terminal. The terminal includes at least a hardware layer, a Kernel layer, a Bootloader layer, and a file system layer. The Kernel layer stores a public key, and the Bootloader layer Carrying a signature, the device consists of:

a detection module configured to detect whether the terminal is a non-test terminal;

The verification module is configured to use the public key to verify the signature through the Kernel layer when the terminal is not a test terminal. The signature is a signature generated according to the private key. If the private key does not match the public key, the verification fails. , indicating the end of the verification.

Optionally, the detection module includes:

The first detection submodule is configured to detect whether the terminal contains a preset circuit structure, and the preset circuit structure is used to indicate that the terminal is a terminal for testing;

The first determination submodule is configured to determine that the terminal is not a terminal for testing when the preset circuit structure is not included.

Optionally, the first detection submodule is further configured to detect whether a preset circuit structure is included in the trusted area of the hardware layer, where the trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications.

Optionally, the detection module includes:

The second detection submodule detects whether the terminal contains a preset identifier, and the preset identifier is an identifier used to indicate that the terminal is a terminal for testing;

The second determination submodule determines that the terminal is not a terminal for testing if the terminal does not contain a preset identifier.

Optionally, the second detection submodule is further configured to detect whether the trusted storage area of the hardware layer contains a preset identifier. The trusted storage area is an area in the hardware layer that is prohibited from being directly accessed by applications.

According to the third aspect of the embodiments of the present disclosure, a boot verification device is provided, which is used in a terminal. The terminal includes at least a hardware layer, a Kernel layer, a Bootloader layer, and a file system layer. The Kernel layer stores a public key, and the Bootloader layer Carrying a signature, the device consists of:

processor;

memory for storing processor-executable instructions;

where the processor is configured as:

Detect whether the terminal is a non-test terminal;

When it is determined that the terminal is not a test terminal, the signature is verified using the public key through the Kernel layer. The signature is a signature generated based on the private key. The private key does not match the public key. When the verification fails, it is instructed to end the verification .

The technical solutions provided by the embodiments of the present disclosure may include the following beneficial effects:

By detecting whether the terminal is a non-test terminal, when it is determined that the terminal is a non-test terminal, the signature is verified using the public key through the Kernel layer. Since the signature is generated based on the private key, the private key does not match the public key. , so the terminal verification fails and cannot be opened; it solves the problem of low security caused by running the test version of the Rom package in the terminal; by setting a set of matching keys and a set of mismatching keys in the terminal, it achieves The non-test terminal cannot be successfully started due to verification failure, which ensures the security effect of the terminal.

It is to be understood that both the foregoing general description and the following detailed description are exemplary only and are not restrictive of the present disclosure.

Description of drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the disclosure and together with the description serve to explain the principles of the disclosure.

Fig. 1 is a schematic structural diagram of a terminal shown according to an exemplary embodiment;

Fig. 2 is a flow chart showing a power-on verification method according to an exemplary embodiment;

Fig. 3 is a flow chart of a power-on verification method according to another exemplary embodiment;

Fig. 4 is a flowchart of a power-on verification method according to another exemplary embodiment;

Fig. 5 is a flow chart of a power-on verification method according to another exemplary embodiment;

Fig. 6 is a flow chart of a power-on verification method according to another exemplary embodiment;

Fig. 7A is a schematic diagram showing a power-on verification method according to an exemplary embodiment;

Fig. 7B is a schematic diagram of a power-on verification method according to another exemplary embodiment;

Fig. 8 is a block diagram of a power-on verification device according to an exemplary embodiment;

Fig. 9A is a block diagram of a power-on verification device according to another exemplary embodiment;

Fig. 9B is a block diagram of a power-on verification device according to another exemplary embodiment;

Fig. 10 is a block diagram of a terminal according to another exemplary embodiment.

detailed description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with aspects of the present disclosure as recited in the appended claims.

The power-on verification method provided by various embodiments of the present disclosure can be implemented by a terminal using an Android operating system, and the terminal can be a terminal such as a smart phone, a smart TV, and a tablet computer.

A schematic structural diagram of the terminal may be shown in FIG. 1 , and the terminal 10 at least includes: a hardware layer 110 , a Kernel layer 120 , a Bootloader layer 130 and a file system layer 140 . The Kernel layer 120 is located on the upper layer of the hardware layer 110 , the Bootloader layer 130 is located on the upper layer of the Kernel layer 120 , and the file system layer 140 is located on the upper layer of the Bootloader layer 130 .

Among them, the hardware layer 110 usually includes hardware devices such as processors, memory, registers, capacitors, diodes, and triodes; the Kernel in the terminal 10 is a Linux-based kernel, and the Kernel layer 120 is usually used to manage memory, processes, files, and system resources. etc.; the Bootloader layer 130 is mainly used to initialize the processor and related hardware; the file system is used to manage and store file information in the terminal.

In this disclosed embodiment, the public key stored in the Kernel layer 120 is the first public key, and the signature carried by the Bootloader layer 130 is the first signature, and the first signature is a signature generated according to the first private key. The bootloader layer 130 also stores a second public key, and the file system layer 140 carries a second signature, which is a signature generated according to the second private key.

Fig. 2 is a flow chart of a power-on verification method shown according to an exemplary embodiment. In this embodiment, the method is used in the terminal shown in Fig. 1 as an example for illustration, and the method may include the following steps:

In step 201, it is detected whether the terminal is a non-test terminal.

The terminal executes the power-on verification method provided by the embodiment of the present disclosure when loading the Rom package stored in the terminal. The terminal can be a test terminal or a non-test terminal, and the test terminal is a terminal used to test the Rom package. Usually It is the terminal used by the testers of the Rom package; the non-test terminal is the terminal except the test terminal among the terminals running the Rom package, usually the terminal used by ordinary users.

In step 202, when it is determined that the terminal is not a terminal for testing, the signature is verified by using the public key through the Kernel layer, and when the verification fails, an instruction is given to end the verification.

When the terminal fails to verify the signature using the public key pair through the Kernel layer, the terminal indicates that the verification is complete, does not start the Bootloader layer and does not perform other operations during the boot process, and remains in the shutdown state.

Among them, the signature is a signature generated according to the private key, and the private key does not match the public key. The public key and private key are configured in advance by the software developer who develops the Rom package. The public key and private key are carried in the Rom package. When the terminal installs the Rom package, it obtains the public key and private key from the Rom package, and The public key is stored in the Kernel layer and the private key is used to sign the Bootloader layer. Signing the Bootloader layer refers to signing data in the Bootloader layer.

Optionally, both the public key and the private key are strings, the strings include at least one of numbers, letters and symbols, and the strings can be 16-bit strings, 32-bit strings or 64-bit characters String, this embodiment does not limit the format of the public key and private key.

Optionally, the terminal encrypts the data in the Bootloader layer using a private key using a predetermined encryption algorithm to obtain a signature, and the predetermined encryption algorithm is any one of the Schnorr signature algorithm, the elliptic curve digital signature algorithm, and the EIGamal signature algorithm.

To sum up, the power-on verification method provided by the embodiments of the present disclosure detects whether the terminal is a non-test terminal. When it is determined that the terminal is a non-test terminal, the signature is verified by using the public key at the Kernel layer. Since the signature It is a signature generated based on the private key, but the private key does not match the public key, so the terminal verification fails and cannot be opened; it solves the problem of low security caused by running the test version of the Rom package in the terminal; by setting a A set of matching keys and a set of non-matching keys achieve the effect that the non-test terminal cannot be successfully started due to verification failure, and the security of the terminal is guaranteed.

Taking the terminal shown in Figure 1 as an example, when the terminal is a testing terminal, the terminal usually includes the following steps before loading the Rom package, as shown in Figure 3:

In step 301, a generating instruction is received.

Wherein, the generating instruction is used to instruct the terminal to generate a preset circuit structure or generate a preset identifier, and usually only testers have the authority to trigger the generating instruction.

Optionally, the generating instruction is used to instruct the terminal to irreversibly change the original circuit structure by adjusting parameters such as voltage and current to generate a preset circuit structure. The preset circuit structure includes at least one of a predetermined capacitor in a blown state, a predetermined diode in a blown state, and a predetermined triode in a blown state. Optionally, the generating instruction is used to instruct the terminal to generate a preset circuit structure in the trusted area of the hardware layer.

Generally speaking, the terminal hardware layer includes some reserved devices or devices specially used for testing, such as reserved capacitors and reserved diodes. When the terminal operates on these reserved devices, the Normal operation is not affected. Therefore, generating instructions can instruct the terminal to perform irreversible operations on these reserved devices to form a preset circuit structure, for example, instruct the terminal to increase the voltage to break down the predetermined capacitor. Optionally, the instruction is generated to instruct the terminal to write the preset identifier in the trusted storage area. Optionally, the trusted storage area is a memory in the terminal hardware layer. Optionally, the preset identifier is a predetermined field. For example, the preset identifier is field 0 or field 1. In a practical example, the generated instruction can be used to instruct the terminal to write in the storage unit corresponding to address 1 of the memory. Field 1.

In step 302, a preset circuit structure and/or a preset identifier is generated according to the generating instruction.

Optionally, in order to avoid being counterfeited, the terminal generates a preset circuit structure in the trusted area of the terminal hardware layer according to the generated instruction. The trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications.

Optionally, the terminal stores the preset identifier in the trusted storage area of the terminal hardware layer according to the generated instruction, and the trusted storage area is an area in the hardware layer that is prohibited from being directly accessed by applications.

It should be noted that the test terminal can be the preset circuit structure formed through the above steps; or, the test terminal is a terminal specially used for testing the Rom package of the test version, and the test terminal is tested during the production of the test terminal. The preset circuit structure is formed in the terminal.

The flow chart of the terminal when performing power-on verification can be as shown in Figure 4. In this embodiment, the method is used in the terminal shown in Figure 1 as an example for illustration. The method can include the following steps:

In step 401, it is detected whether the terminal includes a preset circuit structure, and the preset circuit structure is used to indicate that the terminal is a terminal for testing.

Optionally, the preset circuit structure generated by the test terminal through the above steps 301 and 302 is located in the trusted area of the hardware layer of the test terminal, or the preset circuit structure formed by the test terminal during production is located in the test terminal In the trusted area of the hardware layer, this step can be implemented as detecting whether the preset circuit structure is included in the trusted area of the hardware layer.

In step 402, if the preset circuit structure is not included, it is determined that the terminal is not a terminal for testing.

In step 403, when it is determined that the terminal is not a terminal for testing, the first signature is verified by using the first public key through the Kernel layer, and when the verification fails, an instruction is given to end the verification.

Wherein, the first signature is a signature generated according to the first private key, and the first private key does not match the first public key.

The first public key and the first private key are carried in the Rom package. When a certain Rom package is written in the Rom of the terminal, the terminal obtains the first public key and the first private key from the Rom package, and stores the first public key The key is stored in the Kernel layer, and the first private key is used to sign the Bootloader layer to generate a first signature. Wherein, signing the Bootloader layer refers to signing files and data included in the Bootloader layer.

For a Rom package of a test version, when the software developer generates the Rom package of the test version, the first public key and the first private key that do not belong to the same key pair are carried in the Rom package, that is, the first The public key and the first private key cannot encrypt and decrypt each other. Therefore, for a terminal that does not contain a preset circuit structure, when the terminal uses the first public key to verify the first signature through the Kernel layer, the verification will fail. Terminal fails to start.

In step 404, if the preset circuit structure is included, it is determined that the terminal is a testing terminal.

In step 405, when it is determined that the terminal is a testing terminal, the second signature is verified by using the second public key through the Bootloader layer, and when the verification is successful, an instruction is given to open the terminal.

Wherein, the second signature is a signature generated according to the second private key, and the second private key matches the second public key.

The second public key and the second private key are also carried in the Rom package. When a certain Rom package is written in the Rom of the terminal, the terminal obtains the second public key and the second private key from the Rom package, and stores the second public key The key is stored in the Bootloader layer, and the second private key is used to sign the file system layer to generate a second signature. Wherein, signing the file system layer refers to signing files and data included in the file system layer.

Optionally, in this embodiment of the present disclosure, the Rom package of the test version is written in the Rom of the terminal. For a Rom package of a test version, the software developer carries the second public key and the second private key belonging to the same key pair in the Rom package when generating the Rom of the test version, that is, the second public key It can be encrypted and decrypted with the second private key. For a test terminal that includes a preset circuit structure, the test terminal does not need to use the first public key to verify the first signature through the Kernel layer, but only needs to directly use the second public key to verify the second signature through the Bootloader layer. At this time, the verification will succeed and the terminal will start successfully.

Optionally, the first public key is the same as the second public key.

Optionally, the same terminal can be a test terminal for testing Rom packages of multiple different test versions, then a preset circuit structure can be included in the terminal, and the Rom packages of different test versions all correspond to the same preset circuit structure; or, the terminal includes a plurality of different preset circuit structures, and Rom packages of different test versions correspond to different preset circuit structures. When Rom of different test versions is written in the terminal, the terminal passes the detection whether Including the preset circuit structure corresponding to the Rom package of the currently loaded test version, it is judged whether it is a testing terminal for testing the Rom package of the test version.

For example, the preset circuit structure corresponding to the Rom package 1 is the preset circuit structure 1, the preset circuit structure corresponding to the Rom package 2 is the preset circuit structure 2, and the terminal includes the preset circuit structure 1. When the Rom package 1 is written in the Rom of the terminal, and the terminal detects that the terminal contains the preset circuit structure 1 during the power-on verification, it is determined that the terminal is a terminal for testing. When the Rom package 2 is written in the Rom of the terminal, and the terminal detects that the terminal does not contain the preset circuit structure 2 during power-on verification, it is determined that the terminal is not a terminal for testing at this time.

To sum up, the power-on verification method provided by the embodiments of the present disclosure detects whether the terminal is a non-test terminal, and when it is determined that the terminal is a non-test terminal, uses the first public key to verify the first signature through the Kernel layer. verification, because the first signature is generated according to the first private key, and the first private key does not match the first public key, so the verification of the terminal fails and cannot be opened; when the terminal is determined to be a test terminal, it directly passes The Bootloader layer uses the second public key to verify the second signature carried by the file system layer. The second signature is generated by the second private key. At this time, because the second public key matches the second private key, the test terminal verifies the signature. The test was successful and successfully opened; the problem of low security caused by running the Rom package of the test version of the terminal was solved; by setting a set of matching keys and a set of non-matching keys in the terminal, the non-testing terminal was achieved Due to the failure of the verification, it cannot be successfully started, so the Rom package of the test version cannot be run, which ensures the security effect of the terminal.

In the power-on verification method provided by the embodiments of the present disclosure, the preset circuit structure is set in the trusted area of the terminal hardware layer, so that the user cannot directly access the preset circuit structure through the application program, avoiding the forgery of the preset circuit structure, and improving The reliability of the preset circuit structure is improved.

The flow chart of the terminal when performing power-on verification can also be shown in Figure 5. This embodiment uses the method in the terminal shown in Figure 1 as an example for illustration. The method can include the following steps:

In step 501, it is detected whether the terminal contains a preset identifier, and the preset identifier is an identifier used to indicate that the terminal is a terminal for testing.

Optionally, this step can be implemented as detecting whether the trusted storage area of the hardware layer contains a preset identifier.

In step 502, if the terminal does not contain the preset identifier, it is determined that the terminal is not a terminal for testing.

In step 503, when it is determined that the terminal is not a terminal for testing, the first signature is verified by using the first public key through the Kernel layer, and when the verification fails, it is instructed to end the verification.

The first signature is a signature generated according to the first private key, and the first private key does not match the first public key.

In step 504, if the terminal contains the preset identifier, it is determined that the terminal is a terminal for testing.

In step 505, when it is determined that the terminal is a testing terminal, the second signature is verified by using the second public key through the Bootloader layer, and when the verification is successful, an instruction is given to open the terminal.

Wherein, the second signature is a signature generated according to the second private key, and the second private key matches the second public key.

The specific implementation manners of the above steps 501 to 505 may be combined with the above embodiment shown in FIG. 4 , which will not be repeated in this embodiment.

In the power-on verification method provided by the embodiments of the present disclosure, the preset identifier is set in the trusted storage area of the terminal hardware layer, so that the user cannot directly access the preset identifier through the application program, avoiding the forgery of the preset circuit, and improving the predictability. Set the reliability of the identification.

In actual implementation, the Rom package loaded by the terminal can be the Rom package of the test version or the official version of the Rom package, and for the official version of the Rom package, since all terminals loaded with the official version of the Rom package can be verified The verification is successful and the Rom package is run, so the terminal loading the Rom package does not include the preset circuit structure or preset logo. And for the Rom package of the official version, the first public key carried in the Rom matches the first private key, and the second public key also matches the second private key.

Then when the terminal is loading the official version of the Rom package, the above step 403 or step 503 can be replaced by the following steps, as shown in Figure 6:

In step 601, when it is determined that the terminal is not a terminal for testing, the first signature is verified by using the first public key through the Kernel layer, and the terminal verifies the first signature by using the first public key through the Kernel layer.

Wherein, the first signature is a signature generated according to the first private key, and the first private key matches the first public key.

In step 602, when the verification is successful, the second signature is verified by using the second public key through the Bootloader layer, and when the verification is successful, it is instructed to open the terminal.

Wherein, the second signature is a signature generated according to the second private key, and the second private key matches the second public key.

In this embodiment, the first public key may be the same as the second public key, and the first private key may also be the same as the second private key.

To sum up, in the power-on verification method provided by the embodiment of the present disclosure, for the official version of the Rom package, the first public key and the first private key carried in the Rom package match, and the second public key and the second private key carried in the Rom package match. The keys also match, ensuring that all terminals can successfully start and run the official version of the Rom package normally.

In an illustrative example, when the test version of the Rom package is written in the Rom of the terminal, it is assumed that the first public key and the second public key obtained by the terminal from the Rom package are both public key A, and the first private key The key is private key B, the first signature is generated according to private key B, the second private key is private key A, the second signature is generated according to private key A, private key B does not match public key A, private key A and public key A match. Then when the terminal is a testing terminal, and the terminal detects that the hardware area contains a preset identifier, the schematic diagram of the terminal’s power-on verification can be shown in (a) in Figure 7A, and the terminal does not use the public key A through the Kernel layer to pair The first signature is verified, and the second signature is verified directly through the Bootloader layer using the public key A; when the terminal is not a test terminal, the terminal detects that the hardware area does not contain the preset logo, and the schematic diagram of the terminal’s power-on verification As shown in (b) in FIG. 7A , the terminal uses the public key A to verify the first signature through the Kernel layer, and the verification fails.

In another illustrative example, when the official version of the Rom package is written in the Rom of the terminal, assuming that the first public key and the second public key obtained by the terminal from the Rom package are both public key A, the obtained Both the first private key and the second private key are private key A, the first signature and the second signature are both generated according to private key A, and private key A matches private key B. Then for any terminal that loads the Rom package, the terminal may not contain the preset logo and the preset circuit structure, and when the terminal detects that the preset logo or the preset circuit structure is not included, the terminal’s power-on verification 7B, the terminal uses the public key A to verify the first signature through the Kernel layer, and when the verification is successful, uses the public key A to verify the second signature through the Bootloader layer.

The following are device embodiments of the present disclosure, which can be used to implement the method embodiments of the present disclosure. For details not disclosed in the disclosed device embodiments, please refer to the disclosed method embodiments.

Fig. 8 is a block diagram of a power-on verification device according to an exemplary embodiment. As shown in Fig. 8, the device can be implemented as a terminal as shown in Fig. 1 through software, hardware or a combination of the two. Including but not limited to: detection module 810 and verification module 820 .

The detection module 810 is configured to detect whether the terminal is not a terminal for testing.

The verification module 820 is configured to verify the signature using the public key through the Kernel layer when the detection module 810 detects that the terminal is not a test terminal. The signature is a signature generated according to the private key, and the private key and the public key The keys do not match, and when the verification fails, it indicates the end of the verification.

To sum up, the power-on verification device provided by the embodiments of the present disclosure detects whether the terminal is a non-test terminal, and when it is determined that the terminal is a non-test terminal, uses the public key to verify the signature through the Kernel layer. Since the signature It is a signature generated based on the private key, but the private key does not match the public key, so the terminal verification fails and cannot be opened; it solves the problem of low security caused by running the test version of the Rom package in the terminal; by setting a A set of matching keys and a set of non-matching keys achieve the effect that the non-test terminal cannot be successfully started due to verification failure, and the security of the terminal is guaranteed.

Figures 9A and 9B are block diagrams of a power-on verification device according to another exemplary embodiment. The device can be implemented as the terminal shown in Figure 1 through software, hardware or a combination of the two. The device includes but not limited to:

The detection module 910 is configured to detect whether the terminal is not a terminal for testing.

Optionally, the detection module 910 includes the following submodules, as shown in FIG. 9A:

The first detection sub-module 911 is configured to detect whether the terminal contains a preset circuit structure, and the preset circuit structure is used to indicate that the terminal is a terminal for testing.

The first detection sub-module 911 is further configured to detect whether a preset circuit structure is included in the trusted area of the hardware layer. The trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications.

The first determination submodule 912 is configured to determine that the terminal is not a terminal for testing when it is detected by the first detection submodule 911 that the terminal does not contain a preset circuit structure.

Or, optionally, the detection module 910 includes the following submodules, as shown in FIG. 9B:

The second detection submodule 913 is configured to detect whether the terminal contains a preset identifier, where the preset identifier is an identifier used to indicate that the terminal is a terminal for testing.

The second detection submodule 913 is further configured to detect whether a preset identifier is contained in the trusted storage area of the hardware layer. The trusted storage area is an area in the hardware layer that is prohibited from being directly accessed by applications.

The second determination submodule 914 is configured to determine that the terminal is not a terminal for testing when it is detected by the second detection submodule 911 that the terminal does not contain a preset identifier.

The verification module 920 is configured to verify the signature using the public key through the Kernel layer when the terminal is determined to be a non-test terminal by the first determination submodule 912 or the second determination submodule 914, and the signature is based on the private key. The signature generated by the key, the private key does not match the public key, and when the verification fails, it indicates the end of the verification.

To sum up, the power-on verification device provided by the embodiments of the present disclosure detects whether the terminal is a non-test terminal, and when it is determined that the terminal is a non-test terminal, uses the public key to verify the signature through the Kernel layer. Since the signature It is a signature generated based on the private key, but the private key does not match the public key, so the terminal verification fails and cannot be opened; it solves the problem of low security caused by running the test version of the Rom package in the terminal; by setting a A set of matching keys and a set of non-matching keys achieve the effect that the non-test terminal cannot be successfully started due to verification failure, and the security of the terminal is guaranteed.

Regarding the apparatus in the foregoing embodiments, the specific manner in which each module executes operations has been described in detail in the embodiments related to the method, and will not be described in detail here.

An exemplary embodiment of the present disclosure provides a power-on verification device capable of realizing what is provided in the present disclosure. A power-on verification method, the device comprising: a processor, a memory for storing instructions executable by the processor;

where the processor is configured as:

Detect whether the terminal is a non-test terminal;

When it is determined that the terminal is not a test terminal, the signature is verified using the public key through the Kernel layer. The signature is a signature generated based on the private key. The private key does not match the public key. When the verification fails, it is instructed to end the verification .

Fig. 10 is a block diagram of a power-on verification device according to an exemplary embodiment. For example, the apparatus 1000 may be a mobile phone, a computer, a digital broadcast terminal, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, and the like.

10, device 1000 may include one or more of the following components: processing component 1002, memory 1004, power supply component 1006, multimedia component 1008, audio component 1010, input/output (I/O) interface 1012, sensor component 1014, and communication component 1016 .

The processing component 1002 generally controls the overall operations of the device 1000, such as those associated with display, telephone calls, data communications, camera operations, and recording operations. The processing component 1002 may include one or more processors 1018 to execute instructions to complete all or part of the steps of the above method. Additionally, processing component 1002 may include one or more modules that facilitate interaction between processing component 1002 and other components. For example, processing component 1002 may include a multimedia module to facilitate interaction between multimedia component 1008 and processing component 1002 .

The memory 1004 is configured to store various types of data to support operations at the device 1000 . Examples of such data include instructions for any application or method operating on device 1000, contact data, phonebook data, messages, pictures, videos, and the like. The memory 1004 can be realized by any type of volatile or non-volatile storage device or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Magnetic Memory, Flash Memory, Magnetic or Optical Disk.

The power supply component 1006 provides power to various components of the device 1000 . Power components 1006 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for device 1000 .

The multimedia component 1008 includes a screen that provides an output interface between the device 1000 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensor may not only sense a boundary of a touch or a swipe action, but also detect duration and pressure associated with the touch or swipe operation. In some embodiments, the multimedia component 1008 includes a front camera and/or a rear camera. When the device 1000 is in an operation mode, such as a shooting mode or a video mode, the front camera and/or the rear camera can receive external multimedia data. Each front camera and rear camera can be a fixed optical lens system or have focal length and optical zoom capability.

The audio component 1010 is configured to output and/or input audio signals. For example, the audio component 1010 includes a microphone (MIC), which is configured to receive external audio signals when the device 1000 is in operation modes, such as call mode, recording mode and voice recognition mode. Received audio signals may be further stored in memory 1004 or sent via communication component 1016 . In some embodiments, the audio component 1010 also includes a speaker for outputting audio signals.

The I/O interface 1012 provides an interface between the processing component 1002 and a peripheral interface module, which may be a keyboard, a click wheel, a button, and the like. These buttons may include, but are not limited to: a home button, volume buttons, start button, and lock button.

Sensor assembly 1014 includes one or more sensors for providing status assessments of various aspects of device 1000 . For example, the sensor component 1014 can detect the open/closed state of the device 1000, the relative positioning of components, such as the display and keypad of the device 1000, the sensor component 1014 can also detect a change in the position of the device 1000 or a component of the device 1000, the user The presence or absence of contact with the device 1000, the device 1000 orientation or acceleration/deceleration and the temperature change of the device 1000. The sensor assembly 1014 may include a proximity sensor configured to detect the presence of nearby objects in the absence of any physical contact. The sensor assembly 1014 may also include an optical sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, the sensor component 1014 may also include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor or a temperature sensor.

The communication component 1016 is configured to facilitate wired or wireless communication between the apparatus 1000 and other devices. The device 1000 can access wireless networks based on communication standards, such as Wi-Fi, 2G or 3G, or a combination thereof. In an exemplary embodiment, the communication component 1016 receives broadcast signals or broadcast related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 1016 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID) technology, Infrared Data Association (IrDA) technology, Ultra Wide Band (UWB) technology, Bluetooth (BT) technology and other technologies.

In an exemplary embodiment, apparatus 1000 may be programmed by one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable Realized by a gate array (FPGA), controller, microcontroller, microprocessor or other electronic components, it is used to execute the above power-on verification method.

In an exemplary embodiment, there is also provided a non-transitory computer-readable storage medium including instructions, such as the memory 1004 including instructions, which can be executed by the processor 1018 of the device 1000 to complete the above power-on verification method. For example, the non-transitory computer readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, among others.

Other embodiments of the present disclosure will be readily apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any modification, use or adaptation of the present disclosure, and these modifications, uses or adaptations follow the general principles of the present disclosure and include common knowledge or conventional technical means in the technical field not disclosed in the present disclosure . The specification and examples are to be considered exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

It should be understood that the present disclosure is not limited to the precise constructions which have been described above and shown in the drawings, and various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.

Claims (11)

1. a boot checking method, it is characterized in that, be used in the terminal, at least comprise hardware layer, kernel Kernel layer, start loading Bootloader layer and file system layer in the described terminal, public key is stored in the described Kernel layer, Described Bootloader layer carries signature, and described method comprises: Detecting whether the terminal is a non-test terminal; When it is determined that the terminal is the non-test terminal, the signature is verified using the public key through the Kernel layer, the signature is a signature generated according to a private key, and the private key is the same as the public key. If the above public key does not match, when the verification fails, it indicates to end the verification. 2. The method according to claim 1, wherein the detecting whether the terminal is a non-test terminal comprises: Detecting whether the terminal includes a preset circuit structure, the preset circuit structure is used to indicate that the terminal is a terminal for testing; If the terminal does not include the preset circuit structure, then determine that the terminal is the non-test terminal. 3. The method according to claim 2, wherein the detecting whether a preset circuit structure is included in the terminal comprises: Detecting whether the preset circuit structure is included in the trusted area of the hardware layer, where the trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications. 4. The method according to claim 1, wherein the detecting whether the terminal is a non-test terminal comprises: Detecting whether the terminal contains a preset identifier, where the preset identifier is an identifier indicating that the terminal is a terminal for testing; If the terminal does not contain the preset identifier, determine that the terminal is the non-test terminal. 5. The method according to claim 4, wherein the detecting whether a preset identifier is included in the terminal comprises: Detecting whether the preset identifier is included in the trusted storage area of the hardware layer, where the trusted storage area is an area in the hardware layer that is prohibited from being directly accessed by applications. 6. A boot checking device is characterized in that, it is used in a terminal, and the terminal includes at least a hardware layer, a kernel Kernel layer, a startup loading Bootloader layer and a file system layer, and a public key is stored in the Kernel layer, The Bootloader layer carries a signature, and the device includes: a detection module configured to detect whether the terminal is a non-test terminal; A verification module configured to verify the signature using the public key through the Kernel layer when the terminal is determined to be the non-test terminal, the signature is a signature generated according to the private key , the private key does not match the public key, and when the verification fails, it indicates to end the verification. 7. The device according to claim 6, wherein the detection module comprises: The first detection submodule is configured to detect whether the terminal includes a preset circuit structure, and the preset circuit structure is used to indicate that the terminal is a terminal for testing; The first determination submodule is configured to determine that the terminal is the non-test terminal when the terminal does not contain the preset circuit structure. 8. The device of claim 7, wherein: The first detection submodule is further configured to detect whether the preset circuit structure is included in the trusted area of the hardware layer, and the trusted area is an area in the hardware layer that is prohibited from being directly accessed by applications . 9. The device according to claim 6, wherein the detection module comprises: The second detection submodule is configured to detect whether the terminal contains a preset identifier, and the preset identifier is an identifier used to indicate that the terminal is a terminal for testing; The second determination submodule is configured to determine that the terminal is the non-test terminal when the terminal does not contain the preset identifier. 10. The apparatus of claim 9, wherein: The second detection submodule is further configured to detect whether the preset identifier is contained in the trusted storage area of the hardware layer, and the trusted storage area is prohibited from being directly accessed by applications in the hardware layer. area. 11. A power-on verification device, characterized in that it is used in a terminal, and the terminal at least includes a hardware layer, a kernel Kernel layer, a boot loader layer and a file system layer, and a public key is stored in the Kernel layer, The Bootloader layer carries a signature, and the device includes: processor; memory for storing said processor-executable instructions; Wherein, the processor is configured as: Detecting whether the terminal is a non-test terminal; When it is determined that the terminal is the non-test terminal, the signature is verified using the public key through the Kernel layer, the signature is a signature generated according to a private key, and the private key is the same as the public key. If the above public keys do not match, when the verification fails, it indicates to end the verification.