Chip key processing method, hardware security module and chip

Abstract

The embodiment of the invention discloses a chip key processing method, a hardware security module and a chip. The hardware security module of the chip receives a key processing request sent by a main control module; determining the authority indicated by the key processing request according to the authority indication information, and verifying the authority indicated by the key processing request based on a preset authority constraint strategy to obtain a verification result; the preset permission constraint strategy comprises a permission isolation constraint, a permission constraint of an import key, a transmission key constraint and a derived key constraint; the permission isolation constraint is used for prohibiting that the single key has at least one permission in the first permission set under the condition of having the transmission permission; the permission constraint for importing the key is used for prohibiting the externally imported key from having the transmission permission; the transmission key constraint is used for limiting the source of the transmission key; the derived key constraint is used for limiting the derivation range of the parent key; and under the condition that the verification result is that the verification is passed, executing a key processing operation corresponding to the key processing request.

Description

Technical Field

[0001] The present invention relates to the field of cryptographic technology, and in particular to a chip key processing method, a hardware security module and a chip. Background Art

[0002] In the field of information security, key management is a core technology for ensuring data confidentiality and integrity. With the widespread application of cryptography, the security requirements for key processing in embedded systems have increased significantly. Key generation, storage, use, and destruction must be strictly controlled to prevent key leakage and unauthorized use.

[0003] Embedded Hardware Security Modules (HSMs) typically support key generation, import, export, derivation, and negotiation. They reference key IDs in commands to implement encryption, decryption, and signature verification. To enhance security, key operations typically require authentication before they occur. However, this additional authentication is often not performed during actual key usage, leading to potential attacks. For example, an attacker could construct a specific request to decrypt the encrypted value of a known key using another key, thereby obtaining the plaintext.

[0004] While existing technical solutions have introduced some authentication mechanisms or restrictions to mitigate these issues, these approaches have significant drawbacks. On the one hand, interactive authentication increases the management burden and is difficult to apply to resource-constrained embedded environments. On the other hand, while fixed key policies improve security, they sacrifice the flexibility and versatility of key usage. Therefore, a more efficient and flexible key processing method is urgently needed to improve the security of key operations without compromising performance. Summary of the Invention

[0005] The embodiments of the present application provide a chip key processing method, a hardware security module, and a chip, which can improve the security of key operations.

[0006] The technical solution of the embodiment of the present application is implemented as follows: In a first aspect, an embodiment of the present application provides a chip key processing method, the method comprising: The hardware security module of the chip receives a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each type of key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed; Determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on the preset authority constraint policy to obtain a verification result; wherein the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; the authority isolation constraint is used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; the transmission key constraint is used to limit the source of the transmission key; the derived key constraint is used to limit the derivation scope of the parent key; If the verification result is that the verification passes, the key processing operation corresponding to the key processing request is executed.

[0007] In a second aspect, an embodiment of the present application provides a hardware security module, the hardware security module including a receiving unit, a verification unit and a key operation unit; a receiving unit, configured to receive a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information being a binary integer of a preset length, the preset length corresponding to the number of categories of key permissions, each type of key permission corresponding to a bit in the binary integer, a first value of the bit indicating that the key permission of the corresponding category is possessed, and a second value of the bit indicating that the key permission of the corresponding category is not possessed; A verification unit is configured to determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result; wherein the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; the authority isolation constraint is used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; the transmission key constraint is used to limit the source of the transmission key; and the derived key constraint is used to limit the derivation scope of the parent key; The key operation unit is used to execute the key processing operation corresponding to the key processing request when the verification result is verification passed.

[0008] In a third aspect, an embodiment of the present application provides a chip, including a main control module and a hardware security module; a main control module, configured to send a received key processing request to the hardware security module; wherein the key processing request includes permission indication information, the permission indication information being a binary integer of a preset length, the preset length corresponding to the number of categories of key permissions, each type of key permission corresponding to a bit in the binary integer, a first value of the bit indicating that the key permission of the corresponding category is possessed, and a second value of the bit indicating that the key permission of the corresponding category is not possessed; A hardware security module is used to determine the authority indicated by a key processing request based on authority indication information, and to verify the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result; wherein the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; authority isolation constraints are used to prohibit a single key from having at least one authority in a first authority set when it has transmission authority; authority constraints for importing keys are used to prohibit keys imported from the outside from having transmission authority; transmission key constraints are used to limit the source of transmission keys; derived key constraints are used to limit the derivation range of parent keys; when the verification result is that the verification passes, the key processing operation corresponding to the key processing request is executed.

[0009] The embodiment of the present application provides a chip key processing method, a hardware security module and a chip, wherein the hardware security module receives a key processing request sent by a main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each key permission corresponds to a bit in the binary integer, the value of the bit is a first value indicating that the key permission of the corresponding category is possessed, and the value of the bit is a second value indicating that the key permission of the corresponding category is not possessed; the permission indicated by the key processing request is determined according to the permission indication information, and the permission indicated by the key processing request is verified based on the preset permission constraint policy, and the result is obtained. Verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraint, authority constraint for importing keys, transmission key constraint and derived key constraint; authority isolation constraint is used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; transmission key constraint is used to limit the source of transmission keys; derived key constraint is used to limit the derivation range of parent keys; when the verification result is that the verification passes, the key processing operation corresponding to the key processing request is executed. It can be seen that when a key processing request is received, the hardware security module can determine the relevant key permissions indicated by the request through the permission indication information in the key processing request, and then use the preset permission constraint strategy to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other key permissions, thereby avoiding key abuse or leakage; permission constraints on imported keys can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only come from controlled one-time programmable keys and their derived child keys, thereby improving the security of the key chain; derived key constraints limit the permission type of the parent key when generating child keys, thereby avoiding the formation of attack paths and enhancing the anti-attack capabilities of the entire system. Ultimately, key processing operations are performed only when the permission verification is passed, thereby greatly improving the security of the key processing process. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 1 ; Figure 2 A schematic diagram of key storage proposed in an embodiment of the present application; Figure 3 A schematic diagram of the chip structure proposed in the embodiment of the present application; Figure 4 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 2 ; Figure 5 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 3 ; Figure 6 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 4 ; Figure 7 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 5 ; Figure 8 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 6 ; Figure 9 This is a schematic diagram of the composition structure of the hardware security module proposed in an embodiment of the present application. DETAILED DESCRIPTION

[0011] The following will be combined with the accompanying drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to explain the related applications and are not intended to limit the applications. It should also be noted that for ease of description, only the portions relevant to the related applications are shown in the drawings.

[0012] Keys are the foundation of cryptographic security. Current key management technologies lack the protection of key usage and key values. Typical attack methods include: deriving a key A inside a hardware security module (HSM), sending a command to the HSM to encrypt key B using key A, obtaining and exporting the ciphertext of B, and then sending a command to the HSM to decrypt key B using key A to obtain the plaintext of B. Alternatively, an externally known plaintext key A can be imported into the HSM, and a command can be sent to the HSM to encrypt key B using key A, obtaining and exporting the ciphertext of B. The exported ciphertext of B can then be decrypted using the known plaintext key A outside the HSM to obtain the plaintext of B. The aforementioned attack methods can usually be mitigated through the following mechanisms, such as adding an authentication mechanism, requiring operators to authenticate before any operation, transferring responsibility to the administrator, or forcing Key A to be an internally preset fixed key. However, adding an authentication mechanism increases management costs, and adding an interactive authentication process is difficult on some embedded systems. Furthermore, key usage is often not authenticated to ensure key processing performance, thus posing an attack risk. Another approach, however, lacks the universal design similar to other keys due to the fixed nature of the imported and exported encryption keys.

[0013] In order to solve the problems existing in the current methods of password processing, the embodiments of the present application provide a chip key processing method, a hardware security module and a chip. The hardware security module can introduce a strict permission verification mechanism before key generation, import, export, derivation and other operations to ensure that the configuration of key permissions complies with the security policy. Specifically, permission isolation constraints are used to prohibit the coexistence of transmission permissions with other key permissions; permission constraints on imported keys are used to prohibit externally imported keys from having transmission permissions; transmission key constraints are used to limit the source of transmission keys; and derived key constraints are used to limit the scope of parent key derivation permissions. These improvement measures work together to significantly improve the security and controllability of keys and effectively prevent key leakage and abuse.

[0014] The technical solutions in the embodiments of the present application will be described clearly and completely below in conjunction with the drawings in the embodiments of the present application.

[0015] An embodiment of the present application provides a chip key processing method. Figure 1 Schematic diagram of the implementation process of the chip key processing method proposed in this application embodiment Figure 1 ,like Figure 1 As shown, in an embodiment of the present application, a chip key processing method of a hardware security module may include the following steps: Step 101: The hardware security module of the chip receives a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed.

[0016] In embodiments of the present application, the hardware architecture of a chip, such as a system-on-chip (SOC), typically integrates two core components: a host module (Host) and a hardware security module (HSM). When an external device or other external chip needs to initiate a key-related operation, such as key generation, derivation, encryption, or permission verification, the request will first be received by the chip's HSM. The HSM, acting as the "front-end interface" for interaction between the chip and the outside world, is responsible for performing preliminary processing of the request, such as verifying the request format and confirming the legitimacy of the requester's identity. Once the preliminary verification passes, the HSM forwards the key processing request to the HSM in accordance with the chip's internal secure communication protocol. The HSM, acting as a trusted execution environment specifically designed to carry out key security operations, executes the core logic in the request, such as key algorithm calculations and permission verification, and feeds the final processing results back to the external requester via the HSM.

[0017] In the embodiments of the present application, a key processing request refers to a key-related operation request initiated by a user or a system, such as key generation, import, export, derivation, etc.

[0018] In some embodiments of the present application, key processing requests may include key generation requests, key import requests, key export requests, key derivation requests, key deletion requests, key negotiation requests, and key usage requests, etc. For example, key usage requests may include key encryption / decryption requests, signature / signature verification requests, etc.; the specific types of key processing requests are not limited in this application.

[0019] In an embodiment of the present application, the key processing request may include relevant information involved in the key operation requested for processing; for example, the key processing request may include the identity of the key to be operated, such as KEY ID, the type of operation expected to be performed, and related parameters and other information.

[0020] In an embodiment of the present application, a key processing request may include permission indication information, which can be understood as a digital identifier used to clarify the various types of key permissions that the key has or does not have; the permission indication information uses a structured encoding method, that is, a binary integer of a preset length, which centrally carries all permission status information related to the key, and is the core basis for the hardware security module to identify, verify or execute the key operation corresponding to the key processing request.

[0021] In the embodiments of the present application, the specific numerical values ​​of the first value and the second value are not limited in this application; for example, the first value is 1 and the second value is 0; or, the first value can be 0 and the second value can be 1.

[0022] In the embodiments of the present application, the preset length is the number of bits in a predefined binary integer representing a key permission. The preset length can be pre-set based on the total number of key permission categories required in actual business operations, and once set, it serves as a fixed parameter for encoding permission information. For example, if an actual application scenario requires 16 key permissions, the preset length is 16 bits; if 32 key permissions are required, the preset length is 32 bits. This ensures that the number of bits in the binary integer exactly matches the number of permission categories, thereby allocating unique bits to each permission and avoiding conflicts or omissions in permission identifiers.

[0023] In the embodiments of the present application, the number of categories of key permissions can be understood as the total number of types of operation permissions that are independent of the key; the number of categories of key permissions is the direct basis for determining the preset length, that is, the number of categories is numerically equal to the preset length to ensure that each type of permission can correspond to a unique bit in the binary integer.

[0024] For example, if the key permissions involved in the actual application scenario are: import permission, signature verification permission, decryption permission, encryption and decryption permission, that is, the number of key permission categories is 4, then the permission indication information can be determined to be a 4-bit binary integer, and the 0th bit in the permission indication information is set to correspond to the encryption and decryption permission, the 1st bit corresponds to the decryption permission, the 2nd bit corresponds to the signature verification permission, and the 3rd bit corresponds to the import permission; assuming that the first value is 1 and the second value is 0, the permission indication information is: 1011, which means that the relevant key for the operation requested by the key processing request has or should have encryption and decryption permission (the 0th bit is 1), has decryption permission (the 1st bit is 1), has no signature verification permission (the 2nd bit is 0), and has import permission (the 3rd bit is 1).

[0025] Exemplarily, based on the above example, assuming that the key processing request is a key generation request, the permission indication information 1011 can be understood as the key requested to be generated needs to have encryption and decryption permissions (bit 0 is 1), has decryption permissions (bit 1 is 1), does not need signature verification permissions (bit 2 is 0), and needs to have import permissions (bit 3 is 1); and if the key processing request is a key import request, the permission indication information 1011 can be understood as the key to be imported has encryption and decryption permissions (bit 0 is 1), has decryption permissions (bit 1 is 1), does not have signature verification permissions (bit 2 is 0), and has import permissions (bit 3 is 1).

[0026] Step 102: Determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on the preset authority constraint policy to obtain a verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; authority constraints for importing keys are used to prohibit keys imported from the outside from having transmission authority; transmission key constraints are used to limit the source of transmission keys; and derived key constraints are used to limit the derivation scope of parent keys.

[0027] In an embodiment of the present application, the preset permission constraint policy is a set of predefined rules used to ensure that the key meets security requirements during the generation, import, export, use and derivation process, so as to reduce the possibility of key leakage or attack, thereby improving the security of key processing.

[0028] In some embodiments of the present application, permission isolation constraints can be used to ensure that a key has other key operation permissions while having transmission permissions, thereby reducing the risk of abuse. For example, if a key can be used for both encryption and transmission, an attacker may use the encryption capability of one key to decrypt the ciphertext of other keys and then obtain the plaintext of other keys. Specifically, the permission isolation constraint can be to prohibit a single key from having at least one of encryption and decryption permissions, signature verification permissions, deriving or negotiating new keys, and key plaintext export permissions while having transmission permissions.

[0029] In some embodiments of the present application, the permission constraints for importing keys can effectively prevent externally imported keys from having transmission permissions, thereby preventing attackers from compromising the security of the system by importing malicious keys; specifically, the permission constraints for importing keys can prohibit externally imported keys from having transmission permissions, thereby preventing external attackers from using imported keys to obtain the plaintext value of the target key.

[0030] In some embodiments of the present application, a transmission key constraint is used to limit the source of the transmission key, allowing only one-time programmable (OTP) keys and keys derived from one-time programmable keys to be used as transmission keys; through this constraint, it can be ensured that only trusted keys, such as OTP keys and keys derived from OTP keys, can be used in the key import and export process.

[0031] Among them, the OTP key refers to the key burned during the production stage of the hardware security module, which cannot be changed and cannot be read externally.

[0032] In some embodiments of the present application, the derived key constraint is used to limit the derivation scope of the parent key. Specifically, the derived key constraint can be used to limit the permissions of the child key derived from a parent key to one of the encryption and decryption permissions or the transmission permissions; that is, the derived key constraint is used to prohibit a key from deriving both a key for encryption and decryption permissions and a key for transmission permissions.

[0033] It can be understood that the parent key refers to the original key used to derive the child key, and the child key refers to the key derived from the parent key.

[0034] In an embodiment of the present application, the first permission set may include encryption and decryption permissions, signature verification permissions, derive or negotiate new key permissions, and key plaintext export permissions. In an embodiment of the present application, key permissions can be understood as permissions to use a key, which determines the types of operations that can be performed with the key; for example, encryption and decryption permissions allow the use of a key to encrypt data, signature verification permissions allow the use of a key to generate a digital signature, derive or negotiate new key permissions allow the use of a key to generate a new key, key plaintext export permissions allow the key to be exported in plaintext, and transfer permissions allow the import / export of encrypted keys, which must be a symmetric key.

[0035] In some embodiments of the present application, when the hardware security module receives a key generation request, that is, when the key processing request is a key generation request, the hardware security module may verify the permissions indicated by the key processing request based on a preset permission constraint policy, and the method for obtaining the verification result may include: verifying the key permissions indicated by the key generation request based on the permission isolation constraint; and then, when the key permissions do not include the transmission permission and at least one permission in the first permission set, the verification result corresponding to the key generation request is verification passed; otherwise, the verification result is verification failed.

[0036] Exemplarily, if the key generation request indicates that the permissions of the new key to be generated are transmission permissions and encryption and decryption permissions, the hardware security module determines that the verification result corresponding to the key generation request is verification failure.

[0037] In an embodiment of the present application, by strictly verifying the permission combination of the key generation request, it is possible to prevent the generation of keys with multiple high-risk permissions, especially when transmission permissions coexist with encryption, signature and other permissions. This design allows the generated keys to naturally have security boundaries, reducing the potential risk of key abuse from the source, thereby improving the security level of the overall key management.

[0038] In some embodiments of the present application, when the key processing request is a key negotiation request, the hardware security module can also verify the key permissions indicated by the key negotiation request based on the permission isolation constraint. When the key permissions indicated by the key negotiation request do not include transmission permissions and at least one permission in the first permission set, the verification result corresponding to the key negotiation request is determined to be verification passed.

[0039] In some embodiments of the present application, the source of the transmission key includes a one-time programmable key and / or a first subkey derived based on the one-time programmable key.

[0040] In some embodiments of the present application, when the hardware security module receives a key import request, that is, when the key processing request is a key import request, the hardware security module verifies the permissions indicated by the key processing request based on a preset permission constraint policy, and the method for obtaining the verification result may include: verifying the permissions of the key to be imported indicated by the key import request based on the permission constraint of the imported key, and verifying the first transmission key corresponding to the imported key based on the transmission key constraint; and then, when the permission of the key to be imported does not have the transmission permission, and the first transmission key is a one-time programmable key or the first subkey, the verification result corresponding to the key import request is verification passed; otherwise, the verification result is verification failed.

[0041] In an embodiment of the present application, the key import request may indicate relevant information of the key to be imported and relevant information of the first transmission key used to decrypt the key to be imported.

[0042] In an embodiment of the present application, during the key import process, combined with the permission constraints of the imported keys and the source restrictions of the transmission keys, it is possible to effectively prevent externally imported keys from carrying illegal transmission permissions, while ensuring that the transmission keys themselves come from a trusted one-time key system. This mechanism improves the security of the key import process and reduces the risk of system vulnerabilities caused by external injection of malicious keys.

[0043] In some embodiments of the present application, when the hardware security module receives a key export request, that is, when the key processing request is a key export request, the hardware security module verifies the permissions indicated by the key processing request based on a preset permission constraint policy, and the method for obtaining the verification result may include: verifying the permissions of the key to be exported indicated by the key export request based on the permission isolation constraint, and verifying the second transmission key corresponding to the key to be exported based on the transmission key constraint; then, when the key to be exported has export permissions, and the permissions of the key to be exported do not include transmission permissions and at least one permission in the first permission set, and the second transmission key is a one-time programmable key or a first subkey, the verification result corresponding to the key export request is verification passed; otherwise, the verification result is verification failed.

[0044] In an embodiment of the present application, a key derivation request refers to a request for deriving a specified key in an encrypted form. The key derivation request may include identification information of the specified key and transmission key information that is expected to be used.

[0045] For example, the export permission may be the ciphertext export permission (PRIV_EXPORT_CIPHER). A key with this permission can support ciphertext export. During export, a key with the transport permission (PRIV_TRANSPORT) needs to be specified to encrypt the key value.

[0046] In an embodiment of the present application, the key export request needs to meet two conditions during the verification stage. First, the key to be exported has export permission and cannot have transmission permission and other key permissions at the same time; second, the transmission key used must be derived from a one-time key or its legal derivation; this not only ensures the authority compliance of the exported key, but also ensures the security and controllability of the transmission channel, further improving the security of the key export process.

[0047] In some embodiments of the present application, the derived key constraint is used to limit the permissions of a child key derived from a parent key to one of encryption and decryption permissions or transmission permissions; that is, in the embodiments of the present application, the derived key constraint is used to limit a parent key from deriving a child key with encryption and decryption permissions and a child key with transmission permissions at the same time.

[0048] In some embodiments of the present application, when the hardware security module receives a key derivation request, that is, when the key processing request is a key derivation request, the hardware security module verifies the permissions indicated by the key processing request based on a preset permission constraint policy, and the method for obtaining the verification result may include: verifying the parent key indicated by the key derivation request and the first child key permissions corresponding to the parent key based on the derived key constraint; and then, when the parent key has the permission to derive or negotiate a new key, the first child key permission is the encryption and decryption permission, and the derived permissions of the parent key are empty, or they are both encryption and decryption permissions, determining that the verification result corresponding to the key derivation request is verification passed; wherein the derived permissions represent the permissions of the child key derived from the parent key; when the parent key has the permission to transmit, derive or negotiate a new key, the first child key permission is the transmission permission, and the derived permissions of the parent key are empty, or they are both transmission permissions, determining the verification result based on the source of the parent key.

[0049] In some embodiments of the present application, a key derivation request may include identification information of a specified parent key and permission information of the expected child key; for example, a key derivation request may indicate that a new key with encryption and decryption permissions is derived from a key with an identifier of KEY_ID=101, that is, the identification information of the parent key is 101, and the expected child key, that is, the first child key permission is encryption and decryption permissions.

[0050] In the embodiments of this application, derived permissions refer to the set of permissions possessed by a child key that has been successfully derived from a parent key. For example, if the parent key KEY_ID=101 has already derived a child key with encryption and decryption permissions, the derived permissions field of the parent key KEY_ID=101 will be recorded by the system as encryption and decryption. If the user then requests to derive a child key with transfer permissions, the system will check whether the parent key allows mixed derivation and reject the request based on the derived key constraints.

[0051] In an embodiment of the present application, the first subkey authority is the transmission authority, which means that the parent key is required to derive a subkey with transmission authority, and at this time, the source of the parent key also needs to be verified; this application only allows a one-time programmable key to derive a subkey with transmission authority. Therefore, if the source of the parent key is not a one-time programmable key, the verification fails and the key derivation is not performed.

[0052] In some embodiments of the present application, when the hardware security module determines the verification result based on the source of the parent key, if the source of the parent key is a one-time programmable key, the verification result is determined to be verification passed; otherwise, the verification result is determined to be verification failed.

[0053] In some embodiments of the present application, when the hardware security module receives a key deletion request, it can also verify the permissions of the key to be deleted indicated by the key deletion request, and if it is determined that the permissions of the key to be deleted include the deletion permission, the verification result is determined to be verification passed; if the permissions of the key to be deleted do not include the deletion permission, the verification result is determined to be verification failed.

[0054] In some embodiments of the present application, when the hardware security module receives an encryption / decryption request, it can also verify the permissions of the key indicated by the encryption / decryption request. If it is determined that the permissions of the key indicated by the encryption / decryption request include encryption / decryption permissions, the verification result is determined to be verification passed; if the permissions of the key indicated by the encryption / decryption request do not include encryption / decryption permissions, the verification result is determined to be verification failed.

[0055] In some embodiments of the present application, when the hardware security module receives a signature / verification request, it can also verify the permissions of the key indicated by the signature / verification request. If it is determined that the permissions of the key indicated by the signature / verification request include signature / verification permissions, the verification result is determined to be verification passed; if the permissions of the key indicated by the signature / verification request do not include signature / verification permissions, the verification result is determined to be verification failed.

[0056] Step 103: If the verification result is passed, execute the key processing operation corresponding to the key processing request.

[0057] In an embodiment of the present application, the hardware security module determines the authority indicated by the key processing request based on the permission indication information, and verifies the authority indicated by the key processing request based on a preset permission constraint policy. After obtaining the verification result, the hardware security module can execute the key processing operation corresponding to the key processing request if the verification result is passed.

[0058] It can be understood that the key processing operation refers to the execution of corresponding key processing operations according to the request content after the key authority verification is passed, such as key generation, import, export, derivation, deletion and other operations.

[0059] In some embodiments of the present application, for key import operations and key generation operations, the hardware security module can store a first key in a random access memory; wherein the first key is a key generated through a key generation operation or a key imported through a key import operation; and then generate identification information of the first key, and send the identification information of the first key to the main control module.

[0060] It can be understood that after receiving the identification information of the first key, the main control module can support the initiation and execution of subsequent key-related operations. For example, the main control module forwards the instructions carrying the identification information to the hardware security module. The hardware security module accurately locates the first key stored in the random access memory through the identification information and performs the corresponding operation.

[0061] Exemplarily, the contents of some key processing operations may be as shown in Table 1 below. In the key generation operation, the hardware security module may generate a new key and store the new key in a secure area, such as an OTP or random access memory (RAM), and send the identity of the new key, such as a key ID, to the main control module. The key import operation may import a key into the hardware security module, the key export operation may export a key from the hardware security module, and the key derivation operation may derive a key from a specified key, i.e., a parent key. Key negotiation may be an asymmetric key negotiation, which allows two or more communicating parties to jointly negotiate a shared symmetric key by exchanging public information over an insecure channel. In this process, no key needs to be shared in advance, and the negotiated shared key cannot be obtained by a third party. Key deletion may delete a specified key.

[0062] Table 1

[0063] In some embodiments of the present application, for the key generation operation, if the verification passes, the hardware security module can perform the key generation operation, store the generated key in the storage area, and send the identity information of the key to the main control module.

[0064] In some embodiments of the present application, for the key derivation operation, if the verification passes, the hardware security module can perform the key derivation operation, store the generated subkey in the storage area, and send the identity information of the generated subkey to the main control module.

[0065] In some embodiments of the present application, for a key negotiation operation, if the verification passes, the hardware security module may perform the key negotiation operation, store the negotiated key in a storage area, and send identity information of the negotiated key to the main control module.

[0066] In an embodiment of the present application, key processing operations need to be completed inside the hardware security module to ensure that key data is not exposed to the external environment.

[0067] In some embodiments of the present application, when the key processing request is a key import request, the hardware security module can use the first transmission key to decrypt the key to be imported when executing the key processing operation corresponding to the key processing request to obtain first plaintext data; then remove the random amount data in the first plaintext data to obtain the first target key, and store the first target key to complete the key import operation.

[0068] It can be understood that the first target key is the real key value after removing the random amount data; by removing the random amount data in the first plaintext data, it can ensure that the imported key value is correct, thereby avoiding incorrect use due to random amount interference.

[0069] It can be understood that the first plaintext data is the plaintext data of the key obtained by decrypting the key to be imported.

[0070] In some embodiments of the present application, when storing the first target key, the hardware security module may store the first target key in a RAM storage area to further ensure the confidentiality and integrity of the first target key.

[0071] In some embodiments of the present application, after completing the storage of the first target key, the hardware full module may send the identity information of the first target key to the main control module.

[0072] In the embodiment of the present application, when storing a key, the hardware security module may store not only the key but also the permission information of the key.

[0073] In some embodiments of the present application, when storing key permission information, a separate bit can be assigned to each specific permission of the key as an identifier. The state of the bit indicates whether the key has that permission: when the corresponding bit is 1, it indicates that the key has that permission; when it is 0, it indicates that the key does not have that permission. In terms of storage format, the bit states of all permissions can be combined into a fixed-length integer value, such as 16 or 32 bits. The specific length can depend on the total number of permissions supported by the system.

[0074] For example, if the permission integer of a key is 000000000000000010 (16 bits), it means that only the permission corresponding to the second bit is enabled.

[0075] For example, Figure 2 As shown, N keys are stored in the RAM storage area of ​​the hardware security module, and each key has corresponding permission information and key data.

[0076] For example, as shown in Table 2 below, the permission information of each key can be 16 bits, where one bit corresponds to one permission, for example, bit 0 corresponds to encryption and decryption permission (PRIV_CIPHER), bit 1 corresponds to signature verification permission (PRIV_SIGNATURE), bit 2 corresponds to derived key permission (PRIV_DERIVE_KEY), bit 3 corresponds to transmission permission (PRIV_TRANSPORT), bit 4 corresponds to derived transmission permission (PRIV_DERIVE_TRANSPORT), bit 5 corresponds to plaintext import permission (PRIV_IMPORT_PLAIN), bit 6 corresponds to ciphertext import permission (PRIV_IMPORT_CIPHER), bit 7 corresponds to key plaintext export permission (PRIV_EXPORT_PLAIN), bit 8 corresponds to ciphertext export permission (PRIV_EXPORT_CIPHER), bit 9 corresponds to remove permission (PRIV_REMOVE), and bits 10 to 15 are reserved for undefined functions and can be used for subsequent expansion.

[0077] Table 2

[0078] In the embodiments of the present application, random amount data refers to random data added or removed during the key derivation or import process, which can prevent attackers from establishing a correspondence between plaintext and ciphertext, thereby enhancing the system's anti-attack capability.

[0079] In some embodiments of the present application, if the verification result corresponding to the key derivation request is verification passed, the hardware security module can perform the key derivation operation. If the key processing request is a key derivation request, when performing the key derivation operation, the hardware security module can add random data to the plaintext data of the key to be derived to obtain second plaintext data; then use the second transmission key to encrypt the second plaintext data to obtain a second target key, and derive the second target key.

[0080] In some embodiments of the present application, the method for generating random quantity data is not limited in this application; for example, the hardware security module can generate random number data through a secure random number generator, and the length of the data can be configured, for example, to 64 bits or 128 bits.

[0081] In an embodiment of the present application, the second target key is in ciphertext form generated by encrypting the second plaintext data containing the random amount of data using the second transmission key.

[0082] It is understandable that when a request is made to export a certain key, the hardware security module can first obtain the plaintext data of the key to be exported, and insert random data on its basis to form new plaintext data, namely the second plaintext data. This process ensures that the second target key exported each time is different. Even if the same key is exported multiple times, the form of its second target key will change due to different random amounts; the mechanism of adding random data effectively prevents cryptanalysis methods based on known plaintext attacks and improves the security of key processing.

[0083] In some embodiments of the present application, when adding random data, the hardware security module can concatenate the random data to the plaintext data of the key to be derived, or it can merge the random data into the original plaintext data through methods such as XOR operations. The specific adding method is not limited in this application.

[0084] For example, if the original plaintext data is KEY123, a 128-bit random number, such as 7A5B...D9F1, can be added during derivation. These two parts are then combined to form new plaintext data, such as KEY123_7A5B...D9F1, for subsequent encryption. By using this method of adding random numbers, even if the same key is derived multiple times, the resulting second target key will be different, effectively preventing replay attacks and known-plaintext attacks.

[0085] In some embodiments of the present application, when the verification result corresponding to the key deletion request is verification passed, the key deletion operation corresponding to the key deletion request can be executed to delete the specified key in the storage area.

[0086] In some embodiments of the present application, when the verification result corresponding to the encryption / decryption request is verification passed, the encryption / decryption operation corresponding to the encryption / decryption request can be performed to encrypt / decrypt the specified key.

[0087] In some embodiments of the present application, when the verification result corresponding to the signature / verification request is verification passed, the signature / verification operation corresponding to the signature / verification request can be performed, and the data can be signed or verified using the specified key.

[0088] In some embodiments of the present application, the chip key processing method may further include the following steps: Step 104: If the verification result is failure, the key processing operation is not performed.

[0089] In an embodiment of the present application, the hardware security module determines the authority indicated by the key processing request based on the permission indication information, and verifies the authority indicated by the key processing request based on a preset permission constraint policy. After obtaining the verification result, the key processing operation may not be performed if the verification result is that the verification fails.

[0090] In some embodiments of the present application, if the verification result is verification failure, the hardware security module may refuse to execute the key processing request and return an error message.

[0091] For example, if the key involved in the key processing request does not have the permission required to perform the corresponding operation, or the key involved in the request does not comply with the constraints of the preset permission constraint policy, the request will be deemed an invalid request, the hardware security module will not perform any operation, and an error prompt message will be generated.

[0092] The embodiment of the present application provides a chip key processing method, wherein the hardware security module receives a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each key permission corresponds to a bit in the binary integer, the value of the bit is a first value indicating that the key permission of the corresponding category is possessed, and the value of the bit is a second value indicating that the key permission of the corresponding category is not possessed; the permission indicated by the key processing request is determined according to the permission indication information, and the permission indicated by the key processing request is verified based on the preset permission constraint policy to obtain a verification result; wherein the verification is used to determine the key processing Whether the permission indicated by the request complies with the constraints of the preset permission constraint policy; the preset permission constraint policy includes permission isolation constraint, permission constraint for imported keys, transmission key constraint and derived key constraint; permission isolation constraint is used to prohibit a single key from having at least one permission in the first permission set when it has transmission permission; permission constraint for imported keys is used to prohibit keys imported from the outside from having transmission permission; transmission key constraint is used to limit the source of transmission keys; derived key constraint is used to limit the derivation scope of parent keys; if the verification result is verification passed, the key processing operation corresponding to the key processing request is executed; if the verification result is verification failed, the key processing operation is not executed. It can be seen that when a key processing request is received, the hardware security module can determine the relevant key permissions indicated by the request through the permission indication information in the key processing request, and then use the preset permission constraint strategy to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other key permissions, thereby avoiding key abuse or leakage; permission constraints on imported keys can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only come from controlled one-time programmable keys and their derived child keys, thereby improving the security of the key chain; derived key constraints limit the permission type of the parent key when generating child keys, thereby avoiding the formation of attack paths and enhancing the anti-attack capabilities of the entire system. Ultimately, key processing operations are performed only when the permission verification is passed, thereby greatly improving the security of the key processing process.

[0093] Based on the above embodiment, in another embodiment of the present application, illustratively, as Figure 3As shown, chip 0 may include a hardware security module 1 and a host control module (Host) 2. The host control module may include a host processor (Host CPU) 21, host RAM 22, and a host unit (Host Unit) 23. The host RAM is a random access memory directly managed and accessed by the host processor, and the host unit is a comprehensive module set within the chip that performs system-level host control and general processing functions. The hardware security module may include a command processing unit 11, a key management unit 12, an OTP key storage area 13, a RAM key storage area 14, and a cryptographic algorithm engine 15. The host control module may interact with the hardware security module through commands supported by the hardware security module, including sending key processing requests, cryptographic management commands, and cryptographic calculation commands. The keys in the OTP key storage area are burned during production, while the keys in the RAM can be obtained through operations such as importing or internal generation, derivation, and negotiation. The OTP key storage area and the RAM key storage area are encrypted and protected by hardware, and their values ​​cannot be directly read. The keys in the OTP key storage area and the RAM key storage area can be indexed by their key identifiers, and the host control module can reference the key identifiers in commands to perform corresponding cryptographic calculations.

[0094] For example, based on the structure of the above chip, Figure 4 As shown, the key generation / derivation / negotiation process may include the following steps: Step 201: The main control module sends a key generation / derivation / negotiation request to the command processing unit of the hardware security module.

[0095] Step 202: The command processing unit notifies the key management unit to generate / derive / negotiate a new key with the specified authority.

[0096] Step 203: The key management unit checks whether the specified permissions contain permissions that do not comply with the preset permission constraint policy, and in the case of derivation, checks whether the parent key has the corresponding permissions.

[0097] Step 204: The key management unit performs corresponding generation / derivation / negotiation operations.

[0098] In an embodiment of the present application, if the key management unit determines that the authority verification passes, step 204 may be executed.

[0099] Step 205: Store the new key in the RAM key storage area.

[0100] Step 206: Feedback the key ID to the main control module.

[0101] Step 207: reject the operation and feed back error information to the main control module.

[0102] In an embodiment of the present application, if the permission check fails, step 207 may be executed.

[0103] For example, Figure 5 As shown, the key import process may include the following steps: Step 301: The main control module sends a key import request to the command processing unit of the hardware security module.

[0104] Step 302: The command processing unit notifies the key management unit to import a new key with the specified authority.

[0105] Step 303: The key management unit checks whether there is any permission in the specified permissions that does not comply with the preset permission constraint policy.

[0106] Step 304: The key management unit decrypts the ciphertext using the transmission key to obtain the key.

[0107] In an embodiment of the present application, if the permission check passes, step 304 may be executed.

[0108] Step 305: Store the key in the RAM key storage area.

[0109] Step 306: Feedback the key ID to the main control module.

[0110] Step 307: reject the operation and feed back error information to the main control module.

[0111] In an embodiment of the present application, if the permission check fails, step 307 may be executed.

[0112] For example, Figure 6 As shown, the key derivation process may include the following steps: Step 401: The main control module sends a key derivation request to the command processing unit of the hardware security module.

[0113] Step 402: The command processing unit notifies the key management unit to export the key of the specified ID.

[0114] Step 403: The key management unit checks whether the designated key has export permission and whether the relevant permission complies with the preset permission constraint policy.

[0115] Step 404: Read the key from the storage area.

[0116] In an embodiment of the present application, if the permission check passes, step 404 may be executed.

[0117] Step 405: Use the transmission key to encrypt the key to obtain ciphertext.

[0118] Step 406: Output the ciphertext.

[0119] Step 407: reject the operation and feed back error information to the main control module.

[0120] In an embodiment of the present application, if the permission check fails, step 407 may be executed.

[0121] For example, Figure 7 As shown, the key deletion process may include the following steps: Step 501: The main control module sends a key deletion request to the command processing unit of the hardware security module.

[0122] Step 502: The command processing unit notifies the key management unit to delete the key of the specified ID.

[0123] Step 503: The key management unit checks whether the permissions of the key of the specified ID include deletion permission.

[0124] Step 504: Delete the designated key in the storage area.

[0125] In an embodiment of the present application, if the permission check passes, step 504 may be executed.

[0126] Step 505: reject the operation and feed back error information to the main control module.

[0127] In an embodiment of the present application, if the permission check fails, step 505 may be executed.

[0128] For example, Figure 8 As shown, the key usage process, including encryption / decryption and signing / verification, can include the following steps: Step 601: The main control module sends a key usage request to the command processing unit of the hardware security module.

[0129] In this embodiment, the key usage request may be any one of an encryption / decryption request and a signature / signature verification request.

[0130] Step 602: The command processing unit notifies the key management unit to read the specified key ID and key usage.

[0131] Step 603: The key management unit checks whether the designated key has the authority corresponding to the key usage.

[0132] Step 604: Read the key value corresponding to the key ID from the storage area.

[0133] In an embodiment of the present application, if the permission check passes, step 604 may be executed.

[0134] Step 605: The command processing unit sends the key value and related data to the cryptographic algorithm engine for processing to obtain a processing result.

[0135] Step 606: Feedback the processing result to the main control module.

[0136] Step 607: reject the operation and feed back error information to the main control module.

[0137] In an embodiment of the present application, if the permission check fails, step 607 may be executed.

[0138] In some embodiments of the present application, the storage area in the hardware security module stores the key's permission information when storing the key, for example, as mentioned above Figure 2 As shown, N keys are stored in the RAM storage area of ​​the hardware security module, and each key has corresponding permission information and key data.

[0139] Exemplarily, the permission information of the key can be 16 bits, one bit corresponding to one permission, for example, bit0 corresponds to encryption and decryption permission (PRIV_CIPHER), bit1 corresponds to signature verification permission (PRIV_SIGNATURE), bit2 corresponds to derived key permission (PRIV_DERIVE_KEY), bit3 corresponds to transmission permission (PRIV_TRANSPORT), bit4 corresponds to derived transmission permission (PRIV_DERIVE_TRANSPORT), bit5 corresponds to plaintext import permission (PRIV_IMPORT_PLAIN), bit6 corresponds to ciphertext import permission (PRIV_IMPORT_CIPHER), bit7 corresponds to key plaintext export permission (PRIV_EXPORT_PLAIN), bit8 corresponds to ciphertext export permission (PRIV_EXPORT_CIPHER), bit9 corresponds to removal permission (PRIV_REMOVE), and bits10~15 are reserved for undefined functions and can be used for subsequent expansion.

[0140] In some embodiments of the present application, for the permission information of the key, each permission is represented by one bit. When the corresponding bit is 1, it indicates that the key has the permission; when it is 0, it indicates that the key does not have this permission.

[0141] For example, the following are some typical definitions of key permissions: Encryption and decryption permissions (PRIV_CIPHER): The key can be used to encrypt and decrypt data. The hardware security module can check this permission when using the key for encryption / decryption.

[0142] Signature and Verification Permission (PRIV_SIGNATURE): The key can be used to sign and verify data, including generating and verifying Message Authentication Codes (MACs). The hardware security module can check this permission when using the key for signing and verification.

[0143] Permission to derive or negotiate new keys (PRIV_DERIVE_KEY): The key can be used to derive / negotiate new keys. The hardware security module can check this permission of the parent key when deriving a new key.

[0144] Transport permission (PRIV_TRANSPORT): The key can be used for encryption or decryption during the import / export key process. This key must be a symmetric key; the hardware security module checks this permission when importing / exporting ciphertext keys.

[0145] Transfer Derivation Permission (PRIV_DERIVE_TRANSPORT): When set to 1, the key can be used to derive new keys with transfer permission; when set to 0, the key cannot be used to derive new keys with transfer permission; the hardware security module checks this permission when deriving the key, and the derived new key has transfer permission.

[0146] Plaintext import permission (PRIV_IMPORT_PLAIN): allows keys to be imported in plaintext, and the imported keys will be stored in the RAM storage area; when the hardware security module performs a plaintext import operation, if the target KEY ID to be imported already exists in the system, the hardware security module will automatically verify whether the existing key has plaintext import permission.

[0147] Ciphertext import permission (PRIV_IMPORT_CIPHER): allows keys to be imported in ciphertext form, and the imported keys will be stored in the RAM storage area; during the ciphertext import process, a key with transmission permission must be specified to decrypt the imported key ciphertext; when the hardware security module performs a ciphertext import operation, if the target KEY ID to be imported already exists in the system, the hardware security module will automatically check whether the existing key has the corresponding ciphertext import permission.

[0148] Key plaintext export permission (PRIV_EXPORT_PLAIN): The key can be exported in plain text. The hardware security module checks whether the key has this permission when exporting the key in plain text.

[0149] Ciphertext export permission (PRIV_EXPORT_CIPHER): The key can be exported as ciphertext. When exporting the ciphertext, you need to specify a key with transfer permission to encrypt the exported key value. The hardware security module checks whether the key has this permission when exporting the key as ciphertext.

[0150] Remove permission (PRIV_REMOVE): The key can be deleted. The hardware security module checks this permission when the key is deleted.

[0151] In some embodiments of the present application, each key may include any one of the above permissions, or a combination of any of the above permissions.

[0152] For example, this application proposes some typical attack methods, as shown in Table 3 and Table 3 (Continued) below: Table 3

[0153] Table 3 (continued)

[0154] In the embodiments of the present application, the following rules can be summarized based on the above-mentioned coping methods: (1) A key with the PRIV_TRANSPORT permission cannot have any of the following permissions: PRIV_CIPHER, PRIV_SIGNATURE, PRIV_DERIVE_KEY, and PRIV_EXPORT_PLAIN, or any combination thereof. (2) Only the OTP key or its derived key can be configured as PRIV_TRANSPORT permission; (3) Only OTP keys can be configured with PRIV_DERIVE_TRANSPORT permission; (4) Prohibit externally imported keys from having PRIV_TRANSPORT permissions; (5) When the key ciphertext is exported, a random amount should be added to the plaintext data of the key. When the ciphertext is imported, the random amount should be discarded after decryption.

[0155] In an embodiment of the present application, the processing process of various key processing requests is executed based on the above rules, including verifying the permissions of different key processing requests and performing key processing operations after the verification is passed, which can all be executed based on the above rules, thereby improving the security of key processing.

[0156] In summary, the embodiments of the present application use permission bit combinations and special permission verification methods to protect the key generation, import, export, deletion, and use processes to ensure the security of the processing process and reduce the risk of attack. Specifically, it can include binding a set of permission bits to all keys, including permissions such as encryption, decryption, signing, signature verification, transmission encryption, transmission signing, plaintext import, plaintext export, ciphertext import, ciphertext export, deletion, and write protection. Before the generation, import, export, derivation, negotiation, and use of keys, key permissions will be checked, and operations that do not meet the requirements will be rejected. Transmission keys are prohibited from having permissions such as encryption, decryption, signing, and signature verification. A key is prohibited from having the permission to derive both non-transmission keys and transmission keys. Only OTP keys or their derivatives can be used as transmission keys. Transmission keys are prohibited from having export permissions. Compared with current related key processing technologies, this application can protect key values ​​from being obtained by attackers without using authentication. At the same time, performance is improved by reducing authentication operations. Transmission keys use the same design and inspection process as other keys, relying on common permission rule definitions to achieve inspection and verification effects, making them more versatile.

[0157] Based on the above embodiment, in another embodiment of the present application, Figure 9 This is a schematic diagram of the structure of the hardware security module proposed in the embodiment of the present application, as shown in FIG. Figure 9 As shown, the hardware security module 1 proposed in the embodiment of the present application may include: a receiving unit 16, a verification unit 17 and a key operation unit 18.

[0158] The receiving unit 16 is used to receive a key processing request sent by the main control module; wherein the key processing request includes permission indication information, which is a binary integer of a preset length, and the preset length corresponds to the number of categories of key permissions. Each key permission corresponds to a bit in the binary integer, and the value of the bit is a first value, indicating that the key permission of the corresponding category is possessed, and the value of the bit is a second value, indicating that the key permission of the corresponding category is not possessed.

[0159] The verification unit 17 is used to determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on the preset authority constraint policy to obtain a verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints and derived key constraints; authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; the transmission key constraint is used to limit the source of the transmission key; and the derived key constraint is used to limit the derivation scope of the parent key.

[0160] The key operation unit 18 is configured to execute the key processing operation corresponding to the key processing request if the verification result is that the verification is passed; and not execute the key processing operation if the verification result is that the verification is failed.

[0161] In some embodiments of the present application, the first permission set includes encryption and decryption permissions, signature verification permissions, derive or negotiate new key permissions, and key plaintext export permissions; the key processing request includes a key generation request; the verification unit 17 is also used to verify the key permissions indicated by the key generation request based on the permission isolation constraint; and when the key permissions do not include transmission permissions and at least one permission in the first permission set, the verification result corresponding to the key generation request is verification passed; otherwise, the verification result is verification failed.

[0162] In some embodiments of the present application, the key processing request includes a key import request; the source of the transmission key includes a one-time programmable key and / or a first subkey derived based on the one-time programmable key; the verification unit 17 is also used to verify the authority of the key to be imported indicated by the key import request based on the authority constraint of the imported key, and to verify the first transmission key corresponding to the imported key based on the transmission key constraint; and when the authority of the key to be imported does not have the transmission authority and the first transmission key is a one-time programmable key or the first subkey, the verification result corresponding to the key import request is verification passed; otherwise, the verification result is verification failed.

[0163] In some embodiments of the present application, the key processing request includes a key export request; the verification unit 17 is further used to verify the authority of the key to be exported indicated by the key export request based on the authority isolation constraint, and to verify the second transmission key corresponding to the key to be exported based on the transmission key constraint; and when the key to be exported has export authority, and the authority of the key to be exported does not include transmission authority and at least one authority in the first permission set, and the second transmission key is a one-time programmable key or a first subkey, the verification result corresponding to the key export request is verification passed; otherwise, the verification result is verification failed.

[0164] In some embodiments of the present application, the key processing request includes a key derivation request; the derived key constraint is used to limit the permission of a child key derived from a parent key to one of the encryption and decryption permissions or the transmission permission; the verification unit 17 is also used to verify the parent key indicated by the key derivation request and the first child key permission corresponding to the parent key based on the derived key constraint; and when the parent key has the permission to derive or negotiate a new key, the first child key permission is the encryption and decryption permission, and the derived permission of the parent key is empty, or they are both encryption and decryption permissions, determine that the verification result corresponding to the key derivation request is verification passed; wherein the derived permission represents the permission of the child key derived from the parent key; and when the parent key has the transmission derived permission, the first child key permission is the transmission permission, and the derived permission of the parent key is empty, or they are both transmission permissions, determine the verification result based on the source of the parent key.

[0165] In some embodiments of the present application, the verification unit 17 is further configured to determine that the verification result is a passed verification when the source of the parent key is a one-time programmable key; otherwise, determine that the verification result is a failed verification.

[0166] In some embodiments of the present application, the key operation unit 18 is also used to, when the key processing request is a key import request, decrypt the key to be imported using the first transmission key to obtain first plaintext data; and remove the random amount data in the first plaintext data to obtain a first target key, and store the first target key to complete the key import operation; and when the key processing request is a key export request, add random amount data to the plaintext data of the key to be exported to obtain second plaintext data; and encrypt the second plaintext data using the second transmission key to obtain a second target key, and export the second target key.

[0167] In some embodiments of the present application, the key operation unit 18 is also used to store the first key in a random access memory; wherein the first key is a key generated by a key generation operation or a key imported by a key import operation; and to generate identification information of the first key, and send the identification information of the first key to the main control module.

[0168] The embodiment of the present application provides a hardware security module, which includes a receiving unit, a verification unit and a key operation unit; the receiving unit is used to receive a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each key permission corresponds to a bit in the binary integer, the value of the bit is a first value indicating that the key permission of the corresponding category is possessed, and the value of the bit is a second value indicating that the key permission of the corresponding category is not possessed; the verification unit is used to determine the permission indicated by the key processing request according to the permission indication information, and to perform a check on the permission indicated by the key processing request based on a preset permission constraint policy. A verification is performed to obtain a verification result; wherein the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of a preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; transmission key constraints are used to limit the source of transmission keys; derived key constraints are used to limit the derivation range of parent keys; a key operation unit is used to execute the key processing operation corresponding to the key processing request when the verification result is that the verification passes. It can be seen that when the hardware security module receives a key processing request, it can determine the relevant key permissions indicated by the request through the permission indication information in the key processing request, and then use the preset permission constraint strategy to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other key permissions, thereby avoiding key abuse or leakage; permission constraints on imported keys can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only come from controlled one-time programmable keys and their derived child keys, thereby improving the security of the key chain; derived key constraints limit the permission type of the parent key when generating child keys, avoiding the formation of attack paths, and enhancing the anti-attack capability of the entire system, thereby greatly improving the security of the key processing process.

[0169] Furthermore, the present invention provides a chip, as described above. Figure 3 As shown, chip 0 may include a hardware security module 1 and a main control module 2 .

[0170] The main control module 2 can be used to send the received key processing request to the hardware security module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each key permission corresponds to a bit in the binary integer, the bit value is the first value, indicating that the key permission of the corresponding category is possessed, and the bit value is the second value, indicating that the key permission of the corresponding category is not possessed.

[0171] The hardware security module 1 can be used to determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on the preset authority constraint policy to obtain a verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints and derived key constraints; authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; authority constraints for importing keys are used to prohibit keys imported from the outside from having transmission authority; transmission key constraints are used to limit the source of transmission keys; derived key constraints are used to limit the derivation range of parent keys; when the verification result is verification passed, the key processing operation corresponding to the key processing request is executed; when the verification result is verification failed, the key processing operation is not executed.

[0172] In addition, the functional modules in this embodiment may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware or software functional modules.

[0173] If the integrated unit is implemented as a software functional module and not sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this embodiment, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media that can store program code, such as a USB flash drive, a mobile hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0174] Specifically, the program instructions corresponding to a chip key processing method in this embodiment can be stored on a storage medium such as an optical disk, a hard disk, or a USB flash drive. When the program instructions corresponding to a chip key processing method in the storage medium are read or executed by an electronic device, the following steps are included: Receive a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each type of key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed; Determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on the preset authority constraint policy to obtain a verification result; wherein the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; the authority isolation constraint is used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraint for importing keys is used to prohibit keys imported from the outside from having transmission authority; the transmission key constraint is used to limit the source of the transmission key; the derived key constraint is used to limit the derivation scope of the parent key; If the verification result is that the verification passes, the key processing operation corresponding to the key processing request is executed.

[0175] An embodiment of the present application provides a computer program product, including a computer program or instructions. When the computer program or instructions are executed by a processor, the computer executes the steps of the method provided in the above method embodiment.

[0176] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of hardware embodiments, software embodiments, or embodiments combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage and optical storage) containing computer-usable program code.

[0177] The present application is described with reference to the implementation flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the steps in the flowchart. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0178] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which is implemented in the implementation flow diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0179] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process described in the flowchart. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0180] The above are merely preferred embodiments of the present application and are not intended to limit the scope of protection of the present application.

Claims

1. A chip key processing method, characterized in that: The method comprises: The hardware security module of the chip receives a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each type of key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed; Determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints, and derived key constraints; the authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraints for importing keys are used to prohibit keys imported from the outside from having transmission authority; the transmission key constraints are used to limit the source of the transmission key; and the derived key constraints are used to limit the derivation scope of the parent key; If the verification result is that the verification is passed, the key processing operation corresponding to the key processing request is executed.

2. The chip key processing method according to claim 1, characterized in that: The first permission set includes encryption and decryption permissions, signature verification permissions, deriving or negotiating new keys permissions, and key plaintext export permissions; The key processing request includes a key generation request; The verifying the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result includes: verifying the authority indicated by the key generation request based on the authority isolation constraint; In a case where the permissions indicated by the key generation request do not include the transmission permission and at least one permission in the first permission set, the verification result corresponding to the key generation request is verification passed; otherwise, the verification result is verification failed.

3. The chip key processing method according to claim 1, characterized in that: The key processing request includes a key import request; the source of the transmission key includes a one-time programmable key and / or a first subkey derived based on the one-time programmable key; The verifying the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result includes: Verifying the authority of the key to be imported indicated by the key import request based on the authority constraint of the imported key, and verifying the first transmission key corresponding to the key to be imported based on the transmission key constraint; When the permission of the key to be imported does not have the transmission permission and the first transmission key is the one-time programmable key or the first subkey, the verification result corresponding to the key import request is verification passed; otherwise, the verification result is verification failed.

4. The chip key processing method according to claim 3, characterized in that: The key processing request includes a key derivation request; The verifying the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result includes: Verifying the authority of the key to be derived indicated by the key derivation request based on the authority isolation constraint, and verifying the second transmission key corresponding to the key to be derived based on the transmission key constraint; If the key to be derived has export permission, and the permissions of the key to be derived do not simultaneously include the transmission permission and at least one permission in the first permission set, and the second transmission key is the one-time programmable key or the first subkey, then the verification result corresponding to the key derivation request is verification passed; otherwise, the verification result is verification failed.

5. The chip key processing method according to claim 1, characterized in that: The key processing request includes a key derivation request; the derived key constraint is used to limit the authority of a child key derived from a parent key to one of encryption and decryption authority or transmission authority; The verifying the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result includes: Verifying the parent key indicated by the key derivation request and the first child key authority corresponding to the parent key based on the derived key constraint; If the parent key has the permission to derive or negotiate a new key, the permission of the first child key is the encryption / decryption permission, and the derived permission of the parent key is empty, or both are encryption / decryption permissions, determining that the verification result corresponding to the key derivation request is verification passed; wherein the derived permission represents the permission of the child key derived from the parent key; When the parent key has the transmission derived permission, the first child key permission is the transmission permission, and the derived permission of the parent key is empty, or both are transmission permissions, the verification result is determined based on the source of the parent key.

6. The chip key processing method according to claim 5, characterized in that: The determining the verification result based on the source of the parent key includes: In a case where the source of the parent key is a one-time programmable key, the verification result is determined to be a verification pass; otherwise, the verification result is determined to be a verification fail.

7. The chip key processing method according to claim 4, characterized in that: The executing the key processing operation corresponding to the key processing request includes: In a case where the key processing request is the key import request, decrypting the key to be imported using the first transmission key to obtain first plaintext data; removing random data from the first plaintext data to obtain a first target key, and storing the first target key to complete the key import operation; When the key processing request is a key derivation request, adding random data to the plaintext data of the key to be derived to obtain second plaintext data; The second plaintext data is encrypted using the second transmission key to obtain a second target key, and the second target key is derived.

8. The chip key processing method according to claim 2 or 3, characterized in that: The method further comprises: Storing a first key in a random access memory; wherein the first key is a key generated by a key generation operation or a key imported by a key import operation; Generate identification information of the first key, and send the identification information of the first key to the main control module.

9. A hardware security module, characterized in that: The hardware security module includes a receiving unit, a verification unit and a key operation unit; The receiving unit is configured to receive a key processing request sent by the main control module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each type of key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed; The verification unit is used to determine the authority indicated by the key processing request based on the authority indication information, and verify the authority indicated by the key processing request based on a preset authority constraint policy to obtain a verification result; wherein, the verification is used to determine whether the authority indicated by the key processing request complies with the constraints of the preset authority constraint policy; the preset authority constraint policy includes authority isolation constraints, authority constraints for importing keys, transmission key constraints and derived key constraints; the authority isolation constraints are used to prohibit a single key from having at least one authority in the first authority set when it has transmission authority; the authority constraints for importing keys are used to prohibit keys imported from the outside from having transmission authority; the transmission key constraints are used to limit the source of the transmission key; and the derived key constraints are used to limit the derivation scope of the parent key; The key operation unit is configured to execute a key processing operation corresponding to the key processing request if the verification result is verification passed.

10. A chip, characterized in that: Including main control module and hardware security module; The main control module is configured to send the received key processing request to the hardware security module; wherein the key processing request includes permission indication information, the permission indication information is a binary integer of a preset length, the preset length corresponds to the number of categories of key permissions, each type of key permission corresponds to a bit in the binary integer, a first value of the bit indicates that the key permission of the corresponding category is possessed, and a second value of the bit indicates that the key permission of the corresponding category is not possessed; The hardware security module is used to determine the permission indicated by the key processing request based on the permission indication information, and verify the permission indicated by the key processing request based on a preset permission constraint policy to obtain a verification result; wherein, the verification is used to determine whether the permission indicated by the key processing request complies with the constraints of the preset permission constraint policy; the preset permission constraint policy includes permission isolation constraints, permission constraints for imported keys, transmission key constraints and derived key constraints; the permission isolation constraints are used to prohibit a single key from having at least one permission in the first permission set when it has transmission permission; the permission constraints for imported keys are used to prohibit keys imported from the outside from having transmission permission; the transmission key constraints are used to limit the source of the transmission key; the derived key constraints are used to limit the derivation range of the parent key; when the verification result is that the verification is passed, the key processing operation corresponding to the key processing request is executed.

Images