Debugging permission control method based on security certificate and security chip

Abstract

The application provides a debugging permission control method based on a security certificate and a security chip. The method comprises the following steps: obtaining the security certificate through a preset debugging interface; decrypting the security certificate by using a decryption module; obtaining at least one security authentication information of the security certificate; verifying the security authentication information by using a security certificate authentication module; if the security authentication information all passes the verification, obtaining the debugging mode information in the security certificate; and setting the hardware channel and / or the debugging permission of the security chip according to the debugging mode information by using a debugging permission control module. The decryption module, the security certificate authentication module and the debugging permission control module are all hardware circuit modules arranged in the security chip. The security chip comprises a memory, a decryption module, a security certificate authentication module and a debugging permission control module. The application can improve the convenience of the security chip in the security debugging and reduce the cost of the security debugging.

Description

Technical Field

[0001] This invention relates to the field of debugging security chips, specifically to a debugging permission control method based on security certificates and a security chip that implements this method. Background Technology

[0002] Electronic devices often require security chips, which are trusted modules, typically devices capable of independently generating and decrypting keys, and possessing their own processors and storage units. After purchasing security chips, companies often need to use them for debugging, a process known as "security debugging." Security debugging is currently an important topic in the application of security chips. With the rapid development of internet technology, applications such as user privacy, data security, and secure payments are placing higher demands on security debugging.

[0003] Secure debugging ensures that when a security chip is in debug mode, its internal resources and content remain secure, preventing attackers from exploiting the debug interface. The main technical challenge of secure debugging lies in balancing security and debugging requirements. This is because the debug interface is designed to meet the debugging needs of the chip at various stages, and determining the permissions of the debug interface based on the chip's current state is a significant challenge.

[0004] During secure debugging, efficient and secure protection must be implemented at the data initiation point, transmission path, storage path, and destination. Secure debugging acts as a backdoor protection mechanism for this system; if this backdoor has a significant security vulnerability, the entire security system will be compromised. Therefore, debugging permissions must be set before secure debugging, such as access permissions for various hardware resources in the security chip and the access paths of the transmission paths.

[0005] Existing secure debugging methods rely on cloud servers. For example, they obtain debugging permissions from the cloud server or control these permissions using security certificates. This involves generating a security certificate using a pre-defined tool and setting debugging permissions based on that certificate. Typically, these certificates have a fixed lifespan, meaning they have a limited validity period; once that period expires, they are no longer valid. However, this approach is inconvenient for secure debugging, which often requires multiple runs. Setting a fixed expiration date discourages repeated debugging.

[0006] Furthermore, existing security debugging settings often involve numerous participants when setting debugging permissions, leading to high costs. Additionally, many existing security certificates rely on software embedded within the security chip, requiring cloud involvement, further increasing debugging costs. Security certificates also require significant resources, typically several megabytes in size. Moreover, if software-based authentication is used, there is a risk of software leakage if the security chip's authentication software is uploaded to a cloud server, compromising the security of the debugging process. Summary of the Invention

[0007] The first objective of this invention is to provide a low-cost and highly secure debugging permission control method based on security certificates.

[0008] The second objective of this invention is to provide a security chip that is suitable for safe debugging, low in cost, and flexible in debugging.

[0009] To achieve the first objective of this invention, the security certificate-based debugging access control method provided by this invention includes obtaining a security certificate through a preset debugging interface, decrypting the security certificate using an encryption / decryption module to obtain at least one security authentication information of the security certificate, verifying the security authentication information using a security certificate authentication module, and if all security authentication information passes verification, obtaining the debugging mode information in the security certificate, and setting the hardware path and / or debugging access of the security chip according to the debugging mode information; wherein, the encryption / decryption module, the security certificate authentication module, and the debugging access control module are all hardware circuit modules set within the security chip.

[0010] As can be seen from the above scheme, the encryption / decryption module, security certificate authentication module, and debug access control module within the security chip are all hardware modules. Furthermore, the security certificate authentication process does not require an internet connection, achieving offline authentication. This eliminates the risk of software program transmission to the internet leading to security certificate leaks. Moreover, because security certificate authentication is performed through hardware, the data size of the security certificate is very small, and the resources used for the security certificate are minimal.

[0011] On the other hand, since security debugging does not involve a large number of participants, the creation of security certificates also does not require a large number of participants, which reduces the cost of security certificate creation and thus the cost of security debugging. Furthermore, security certificates occupy relatively few storage resources, which also reduces the cost of security chips.

[0012] A preferred approach is to obtain the security certificate's identifier before decrypting it, and determine whether the identifier meets the preset requirements. If not, the security certificate is not decrypted.

[0013] Therefore, by writing a compliant identifier when generating a security certificate, the authentication process can quickly determine whether the security certificate meets the most basic requirements by judging whether the identifier of the security certificate meets the preset requirements. If not, the authentication process can be exited directly to reduce the computational load of subsequent authentication.

[0014] A further approach is to exit the authentication process and increment the recorded number of authentication failures by one if at least one security authentication information of the security certificate fails verification.

[0015] A further proposed solution is to increment the recorded number of authentication failures by one, and then perform the following: determine whether the number of authentication failures has reached a preset threshold; if so, reset the security chip.

[0016] It is evident that if a security chip fails to authenticate multiple times, it indicates that the security chip may be subject to malicious debugging. In order to ensure the data security of the security chip, the security chip should be reset, thereby effectively ensuring the data security of the security chip.

[0017] A preferred approach is to generate the security certificate using a pre-defined security certificate generation device. When generating the security certificate, the security certificate generation device obtains the target security authentication information recorded by the security chip and generates the security certificate based on the target security authentication information.

[0018] Therefore, when creating a security certificate, the corresponding target security authentication information is obtained from the security chip and written into the security certificate. When authenticating the security certificate, the consistency between the security authentication information in the security certificate and the target security authentication information can be compared, thereby quickly confirming the authenticity of the security certificate.

[0019] A further approach is to include at least one of the following in the security authentication information: the chip's unique identifier, the counter's count value, or the debug mode.

[0020] A further approach is to specify the debug mode information as at least one of several pre-defined debug modes.

[0021] Therefore, by pre-setting multiple debugging modes, when generating a security chip, one or more of the preset debugging modes are selected and written to the security chip, thereby ensuring that the debugging mode recorded by the security chip is one or more of the preset debugging modes, so that the security chip can meet the requirements of debugging permission control.

[0022] To achieve the second objective mentioned above, the security chip provided by the present invention includes a memory, an encryption / decryption module, a security certificate authentication module, and a debugging access control module. The memory stores security certificates obtained through a preset debugging interface. The encryption / decryption module decrypts the security certificates to obtain at least one security authentication information. The security certificate authentication module verifies the security authentication information; if all security authentication information passes verification, it obtains the debugging mode information from the security certificate. The debugging access control module sets the hardware pathways and / or debugging permissions of the security chip according to the debugging mode information. The encryption / decryption module, the security certificate authentication module, and the debugging access control module are all hardware circuit modules located within the security chip. Attached Figure Description

[0023] Figure 1 This is a structural block diagram of the security chip embodiment, security certificate, and security certificate loading interface of the present invention.

[0024] Figure 2 This is the first part of a flowchart of an embodiment of the debugging permission control method based on security certificates of the present invention.

[0025] Figure 3 This is the second part of the flowchart of an embodiment of the debugging permission control method based on security certificates of the present invention.

[0026] The present invention will be further described below with reference to the accompanying drawings and embodiments. Detailed Implementation

[0027] The security certificate-based debugging permission control method of the present invention is mainly used for debugging security chips. For example, a debugging host is connected to the security chip and a security certificate is transmitted to the security chip. After the security chip authenticates the security certificate, the corresponding debugging permissions are controlled.

[0028] Security chip example:

[0029] See Figure 1 In this embodiment, the security chip 20 includes a memory 21, an encryption / decryption module 22, a security certificate authentication module 23, and a debugging permission control module 24. The security certificate 10 is generated by a preset security certificate generation device, such as a known security certificate generation device. Preferably, when generating a security certificate using the security certificate generation device, the device is connected to the security chip, obtains the target security authentication information recorded in the security chip, and generates a security certificate based on the target security authentication information.

[0030] Preferably, the target security authentication information may include one or more of the chip's unique identifier, the counter's count value, and the debug mode. When manufacturing a security chip, the security certificate creation device acquires one or more target security authentication information and writes the target security authentication information into the security certificate according to pre-set rules, thus forming the security authentication information of the security certificate.

[0031] Preferably, when generating a security certificate, the debugging company selects one of multiple debugging modes according to the actual debugging needs, and selects the required debugging mode through the security certificate generation device so that the generated security certificate records the debugging mode information.

[0032] Furthermore, the security certificate should meet certain requirements in its design: First, the security certificate itself needs to have a signature property, meaning it needs to use an asymmetric algorithm to sign the entire security certificate; second, the security certificate itself needs to have a hash value of the entire security certificate, used to verify the integrity of the security certificate during transmission; finally, the security certificate needs to contain at least five pieces of information, such as the certificate version, the counter value, the unique identifier of the security chip, the signature data of the security certificate, and the debugging mode information. Specifically, the structure of the security certificate designed in this embodiment is described below with reference to Table 1.

[0033] Table 1

[0034] Security Certificate Mark Security certificate length Version number in the security certificate header Device types with security chips Security certificate signature types Security certificate version number Debug mode SOC ID Public key information Length of the signature information in the security certificate Reserved area Security certificate signature information

[0035] As shown in Table 1, the security certificate includes multiple fields, specifically including the security certificate identifier, security certificate length, version number of the security certificate header, device type of the security chip, signature type of the security certificate, version number of the security certificate, debug mode, SOC ID, public key information, length of the security certificate signature information, reserved area, and signature information of the security certificate.

[0036] For example, the security certificate identifier value is 0x12345678. This identifier can be generated based on the unique identifier of the security chip, indicating that the security certificate is applicable to this security chip. The security certificate length is head_len, representing the size of the entire security certificate. The version number Head_version in the security certificate header is a preset fixed value, and the device type SocSpecific indicates the type of security chip to which the security certificate applies. The signature type Sign_type of the security certificate is used to indicate which type of signature the security certificate uses. For example, the security certificate can use two types of signatures, such as RSA or ECC. The version number Cert_NVC of the security certificate is used to represent the specific version number of the full certificate. The SOC ID, i.e., Soc_id, is used to store the hash value of the security chip ID, used for verifying the security certificate. The public key information Public_key is used to store the relevant data of the public key. Typically, the security chip only uses RSA or ECC signatures; in this embodiment, the public keys for RSA and ECC share the same structure. The length of the security certificate's signature information, Sign_len, indicates the length of the security certificate's signature. The Reserve area does not store information and is reserved for later use. The Sign information stores the security certificate's signature information and is used for security certificate authentication.

[0037] In addition, the security certificate contains a counter, which is a one-way irreversible counter. Every time the security certificate is read, the counter value will increment by one.

[0038] Preferably, a portion of the information in the security certificate is encrypted, such as the version number in the security certificate header, the device type of the security chip, the SOC ID, and the counter value. This information needs to be decrypted by the security chip to obtain it. For example, the encryption / decryption module 22 of the security chip uses the public key in the security certificate and the private key stored within the encryption / decryption module 22 to decrypt the information, thereby obtaining the decrypted information. The security certificate authentication module then compares and verifies the encrypted information to confirm whether the security certificate has passed authentication.

[0039] The security certificate needs to include debug mode information. In this embodiment, the security chip can pre-set multiple debug modes, each including different hardware pathways and debug permission controls. Specifically, each debug mode encompasses both hardware pathways and debug permission control. The preset debug modes can include various options, such as fully open debug permissions and fully closed debug permissions, or modes with partial permissions enabled. In this embodiment, to meet different debugging scenarios, the pre-set debug modes are designed with granular precision, supporting different debug permissions in various scenarios. Table 2 describes several debug modes.

[0040] Table 2

[0041]

[0042] As can be seen, since the security certificate is generated by the debugging company using a preset security certificate generation device, which means that the debugging company is allowed to generate a security certificate by itself, the security certificate is a private security certificate. The debugging company can set the debugging mode according to the actual debugging needs, and the security certificate does not have an expiration date, which allows the debugging company to flexibly debug the security chip.

[0043] Example of a security certificate-based debugging access control method:

[0044] The following is combined with Figure 2 and Figure 3 This section describes the process of secure debugging of security chips. After the debugging company generates a security certificate using a security certificate creation device, such as... Figure 1 As shown, the security certificate 10 is loaded into the memory 21 of the security chip 20 using the security certificate loading interface 15. The security certificate loading interface 15 can be an interface such as JTAG or SW, or an external interface such as UART or USB.

[0045] After security certificate 10 is loaded into memory 21, security chip 20 executes step S1 to obtain the security certificate identifier, i.e., to obtain the information in the first column of Table 1, and to determine whether the security certificate identifier meets the preset requirements. Since the security certificate generation device obtains the unique identifier information of the security chip from the security chip when generating the security certificate, and uses this unique identifier information to generate the security chip identifier, the security chip identifier should correspond to the security chip's unique identifier, i.e., meet the preset requirements. If the security certificate identifier does not meet the preset requirements, i.e., there is no corresponding relationship between the security certificate identifier and the security chip's unique identifier, it can be considered that the security certificate is not generated based on this security chip. Therefore, when the judgment result of step S1 is negative, the security certificate authentication process is directly exited, and no debugging permission settings are performed; the security chip does not perform debugging operations.

[0046] If the security certificate identifier meets the preset requirements, step S2 is executed to identify the signature type and size of the security certificate, i.e., the signature type information and size information of the security certificate. Next, step S3 is executed to obtain the public key information from the security certificate and use the public key to drive the encryption / decryption module 22 to verify the signature of the security certificate. At this time, the security chip executes step S4, where the encryption / decryption module 22 decrypts the security certificate. Specifically, the encryption / decryption module 22 obtains the public key information from the security certificate 10 and uses this public key information to decrypt the encrypted information of the security certificate, and obtains the decrypted information, such as the version number in the security certificate header, the device type of the security chip, the SOC ID, the counter value, and other information, as well as the debug mode information.

[0047] Then, each of the multiple security authentication information in the security certificate is verified one by one. Specifically, step S5 is executed to determine whether the file header of the security certificate has passed the verification, that is, to determine whether the version number of the security certificate header is consistent with the file header of the security certificate stored in the internal storage of the security chip. If so, step S6 is executed; otherwise, step S9 is executed to exit the security certificate authentication process and record the number of authentication failures, that is, to increase the recorded number of authentication failures by one.

[0048] In step S6, it is determined whether the embedded feature information of the security certificate has passed verification. For example, it is determined whether the device type information of the security chip is consistent with the device type information stored in the security chip's memory. If not, step S9 is executed; if they are consistent, step S7 is executed to determine whether the counter value of the security chip has passed verification. Since the security chip manufacturing device is connected to the security chip when the security certificate is generated, the security chip will record the counter value in the security certificate. If the counter value of the security certificate is less than the counter value recorded by the security chip, it indicates that the counter value has been tampered with, and step S9 is executed. If the counter value in the security certificate is greater than the counter value recorded by the security chip, the counter value of the security certificate is considered to have passed verification, and step S8 is executed to obtain the unique identifier of the security chip recorded in the security certificate and determine whether the unique identifier of the security chip recorded in the security certificate has passed verification. If it has passed verification, step S12 is executed; otherwise, step S9 is executed. As can be seen, after the security certificate authentication module 23 reads multiple security authentication information, it compares the obtained security authentication information with the target security authentication information stored in the security chip. If they are consistent or meet the requirements, the security authentication information passes the verification. Otherwise, if any security authentication information fails the verification, step S9 is executed, the authentication process is exited, and the information of one authentication failure is recorded.

[0049] Then, step S10 is executed to determine whether the number of security authentication failures recorded by the security chip exceeds a preset number. If so, step S11 is executed to reset the security chip; otherwise, the process ends directly. It is evident that once the number of security authentication failures exceeds the preset number, it indicates that the security chip may be subject to malicious debugging. Therefore, resetting the security chip can prevent malicious debugging and ensure the security of the data stored in the security chip.

[0050] If all security authentication information of the security chip passes verification, step S12 is executed to obtain the debugging mode information in the security certificate. Since the debugging mode is one or more of the preset debugging modes, that is, one or more of the allowed debugging modes set by the security chip, in step S13, debugging permissions are set according to the obtained debugging modes. For example, according to the debugging permissions corresponding to the debugging modes determined in Table 2, the various hardware paths of the security chip and their corresponding debugging permissions are set.

[0051] As can be seen, debugging companies can configure the debugging permissions of the security chip according to their actual debugging needs, and write the required debugging permissions into the security certificate when creating the security certificate to meet the debugging requirements. Furthermore, since the authentication process for the security certificate in the security chip is entirely offline—that is, it does not require the internet or cloud servers, nor does it require software programs for authentication—the security of the security certificate authentication can be significantly improved.

[0052] Finally, it should be emphasized that the present invention is not limited to the above-described embodiments. For example, changes in the specific steps of the security certificate generation device when generating a security certificate, or changes in the debugging mode type and debugging permissions corresponding to the debugging mode recorded by the security chip, should also be included within the scope of protection of the claims of the present invention.

Claims

1. A debugging access control method based on security certificates, characterized in that, include: The security certificate is obtained through a preset debugging interface, and the security certificate is decrypted using an encryption / decryption module to obtain at least one security authentication information of the security certificate. The security certificate authentication module verifies the security authentication information. If all the security authentication information passes the verification, the debug mode information in the security certificate is obtained. The debug permission control module sets the hardware path and / or debug permission of the security chip according to the debug mode information. The encryption / decryption module, the security certificate authentication module, and the debugging permission control module are all hardware circuit modules located within the security chip. The security certificate is generated using a preset security certificate generation device. When generating the security certificate, the security certificate generation device obtains the target security authentication information recorded by the security chip and generates the security certificate based on the target security authentication information.

2. The debugging permission control method based on security certificates according to claim 1, characterized in that: Before decrypting the security certificate, the identifier of the security certificate is obtained, and it is determined whether the identifier of the security certificate meets the preset requirements. If not, the security certificate is not decrypted.

3. The debugging permission control method based on security certificates according to claim 1 or 2, characterized in that: If at least one of the security authentication information of the security certificate fails verification, the authentication process is terminated and the number of recorded authentication failures is incremented by one.

4. The debugging permission control method based on security certificates according to claim 3, characterized in that: After incrementing the recorded number of authentication failures by one, the following steps are performed: determine whether the number of authentication failures has reached a preset threshold; if so, reset the security chip.

5. The debugging permission control method based on security certificates according to claim 1 or 2, characterized in that: The security authentication information includes at least one of the following: chip unique identifier, counter count value, and debug mode.

6. The debugging permission control method based on security certificates according to claim 1 or 2, characterized in that: The debug mode information is at least one of a plurality of pre-set debug modes.

7. A security chip, characterized in that, include: The memory is used to store security certificates obtained through a preset debugging interface; An encryption / decryption module is used to decrypt the security certificate and obtain at least one security authentication information of the security certificate; The security certificate authentication module is used to verify the security authentication information. If all the security authentication information passes the verification, the debug mode information in the security certificate is obtained. The debugging permission control module is used to set the hardware path and / or debugging permissions of the security chip according to the debugging mode information. The encryption / decryption module, the security certificate authentication module, and the debugging permission control module are all hardware circuit modules located within the security chip. Furthermore, the security certificate is generated using a preset security certificate generation device. When generating the security certificate, the security certificate generation device obtains the target security authentication information recorded by the security chip and generates the security certificate based on the target security authentication information.

8. The security chip according to claim 7, characterized in that: Before decrypting the security certificate, the encryption / decryption module obtains the identifier of the security certificate and determines whether the identifier of the security certificate meets the preset requirements. If not, the security certificate is not decrypted.

9. The security chip according to claim 7 or 8, characterized in that: The security certificate authentication module exits the authentication process and increments the recorded number of authentication failures by one when at least one of the security authentication information of the security certificate fails verification.

Images