Chip key processing method, hardware security module and chip

Abstract

This application discloses a chip key processing method, a hardware security module, and a chip. The chip's hardware security module receives a key processing request sent by a main control module; determines the permissions indicated by the key processing request based on permission indication information, and verifies the permissions indicated by the key processing request based on a preset permission constraint strategy to obtain a verification result; the preset permission constraint strategy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints; permission isolation constraints are used to prohibit a single key from having transmission permissions while also having at least one permission from a first set of permissions; import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions; transmission key constraints are used to restrict the source of transmission keys; derived key constraints are used to restrict the derivation range of the parent key; if the verification result is successful, the key processing operation corresponding to the key processing request is executed.

Description

Technical Field

[0001] This invention relates to the field of cryptography, and in particular to a chip key processing method, a hardware security module, and a chip. Background Technology

[0002] In the field of information security, key management is one of the core technologies for ensuring data confidentiality and integrity. With the widespread application of cryptographic technology, embedded systems have placed higher demands on the secure handling of keys. Operations such as key generation, storage, use, and destruction must be strictly controlled to prevent key leakage or unauthorized use.

[0003] Embedded hardware security modules (HSMs) typically support key generation, import, export, derivation, and negotiation, and use command-line references to key IDs to implement encryption / decryption or signature verification functions. To enhance security, key operations usually require authentication beforehand; however, in actual key use, additional authentication is often lacking, leading to potential attack risks. For example, an attacker could construct a specific request to decrypt the encrypted value of another key using a known key, thereby obtaining the plaintext.

[0004] While current technical solutions have introduced some authentication mechanisms or restrictions to alleviate the aforementioned problems, these methods 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 strategies 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 sacrificing performance. Summary of the Invention

[0005] This application provides 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 this application embodiment is implemented as follows:

[0007] In a first aspect, embodiments of this application provide a chip key processing method, the method comprising:

[0008] The chip's hardware security module receives a key processing request sent by the main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to a bit in the binary integer. The first value of the bit indicates that the user has the corresponding key permission, and the second value of the bit indicates that the user does not have the corresponding key permission.

[0009] The permissions of the key processing request indication are determined based on the permission indication information, and the permissions of the key processing request indication are verified based on a preset permission constraint policy to obtain the verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from having transmission permissions while also possessing at least one permission from the first permission set. Import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key.

[0010] If the verification result is successful, execute the key processing operation corresponding to the key processing request.

[0011] Secondly, embodiments of this application provide a hardware security module, which includes a receiving unit, a verification unit, and a key operation unit;

[0012] The receiving unit is used to receive the key processing request sent by the main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to a bit in the binary integer. The value of the bit is the first value, which indicates that the user has the corresponding key permission. The value of the bit is the second value, which indicates that the user does not have the corresponding key permission.

[0013] The verification unit is used to determine the permissions of the key processing request indication based on the permission indication information, and to verify the permissions of the key processing request indication based on a preset permission constraint strategy to obtain a verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint strategy. The preset permission constraint strategy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from possessing transmission permissions while also possessing at least one permission from a first set of permissions. Import key permission constraints are used to prohibit keys imported from external sources from possessing transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key.

[0014] The key operation unit is used to perform the key processing operation corresponding to the key processing request if the verification result is successful.

[0015] Thirdly, embodiments of this application provide a chip, including a main control module and a hardware security module;

[0016] The main control module is used to send the received key processing request to the hardware security module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to one bit in the binary integer. The value of the bit is the first value, which indicates that the user has the corresponding key permission. The value of the bit is the second value, which indicates that the user does not have the corresponding key permission.

[0017] The hardware security module is used to determine the permissions of the key processing request indication based on the permission indication information, and to verify the permissions of the key processing request indication based on a preset permission constraint policy to obtain a verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from possessing transmission permissions while also possessing at least one permission from a first set of permissions. Import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, the key processing operation corresponding to the key processing request is executed.

[0018] This application provides a chip key processing method, a hardware security module, and a chip. The hardware security module receives a key processing request sent by a main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to one bit in the binary integer. A first value for the bit indicates possession of the corresponding key permission category, and a second value indicates non-possession of the corresponding key permission category. The permission indicated by the key processing request is determined based on the permission indication information, and the permission indicated by the key processing request is verified based on a preset permission constraint strategy to obtain... The verification result is used to determine whether the permissions indicated by the key processing request comply with the constraints of the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from having transmission permissions and at least one permission from the first permission set. Import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, the key processing operation corresponding to the key processing request is executed. Therefore, 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 request. Then, it can utilize preset permission constraint policies to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other critical permissions, avoiding key abuse or leakage; import key permission constraints can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only originate from controlled one-time programmable keys and their derived subkeys, improving key chain security; derived key constraints restrict the permission type of the parent key when generating subkeys, avoiding the formation of attack paths and enhancing the overall system's anti-attack capability. Finally, key processing operations are only executed if permission verification passes, thereby greatly improving the security of the key processing process. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 1 ;

[0020] Figure 2 This is a schematic diagram of key storage proposed in an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of the chip structure proposed in the embodiments of this application;

[0022] Figure 4 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 2 ;

[0023] Figure 5 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 3 ;

[0024] Figure 6 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 4 ;

[0025] Figure 7 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 5 ;

[0026] Figure 8 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 6 ;

[0027] Figure 9 This is a schematic diagram of the hardware security module structure proposed in the embodiments of this application. Detailed Implementation

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for explaining the relevant application and not for limiting the application. Furthermore, it should be noted that, for ease of description, only the parts related to the relevant application are shown in the accompanying drawings.

[0029] Keys are the foundation of cryptographic security. Current key management technologies have shortcomings in key usage and key value protection. Some typical attack methods include: deriving a key A within a Hardware Security Module (HSM), sending a command to the HSM to encrypt key B using key A, obtaining the ciphertext of B, and exporting it; then sending a command to the HSM to decrypt key B using key A, thus obtaining the plaintext of B; or importing an external key A with known plaintext into the HSM, sending a command to the HSM to encrypt key B using key A, obtaining the ciphertext of B, and exporting it; then decrypting the exported ciphertext of B using the known plaintext of key A outside the HSM, also obtaining the plaintext of B. The aforementioned attack methods can usually be mitigated through the following mechanisms, such as adding an authentication mechanism, requiring the operator to authenticate before operation, transferring the responsibility to the administrator, or forcing key A to be an internally preset fixed key; however, adding an authentication mechanism increases management costs, and it is difficult to add an interactive authentication process on some embedded systems, and the key usage process usually cannot perform authentication in order to ensure the performance of key processing, thus posing an attack risk; another approach is to use fixed encryption keys for import and export, lacking a universal design similar to other keys.

[0030] To address the problems existing in current cryptographic processing methods, this application provides a chip key processing method, a hardware security module, and a chip. The hardware security module introduces a strict permission verification mechanism before key generation, import, export, and derivation operations to ensure that key permission configuration complies with security policies. Specifically, permission isolation constraints prevent transmission permissions from coexisting with other critical permissions; import key permission constraints prevent externally imported keys from having transmission permissions; transmission key constraints restrict the source of transmission keys; and derivation key constraints limit the scope of derivation permissions of the parent key. These improvements work together to significantly enhance key security and controllability, effectively preventing key leakage and misuse.

[0031] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0032] One embodiment of this application provides a chip key processing method. Figure 1 This is a schematic diagram of the implementation flow of the chip key processing method proposed in the embodiments of this application. Figure 1 ,like Figure 1 As shown in the embodiments of this application, the chip key processing method of the hardware security module may include the following steps:

[0033] Step 101: The chip's 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 key permission categories, each key permission corresponds to one bit in the binary integer, the value of the bit is the first value indicating that it has the key permission of the corresponding category, and the value of the bit is the second value indicating that it does not have the key permission of the corresponding category.

[0034] In the embodiments of this application, the hardware architecture of a chip, such as a system-on-chip (SOC), typically integrates two core components: a host module and a hardware security module. When an external device or other external chip needs to initiate key-related operations, such as key generation, derivation, encryption, and permission verification, the request is first received through the chip's host module. The host module, acting as the "front-end interface" for interaction between the chip and the external system, is responsible for preliminary processing of the request, such as verifying the request format and confirming the legitimacy of the requester's identity. After the preliminary verification is passed, the host module forwards the key processing request to the hardware security module according to the chip's internal secure communication protocol. The hardware security module, as a trusted execution environment specifically designed to handle key security operations, executes the core logic in the request, such as key algorithm calculations and permission verification, and feeds back the final processing result to the external requester through the host module.

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

[0036] In some embodiments of this 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 / verification requests, etc. The specific type of key processing request is not limited in this application.

[0037] In embodiments of this application, the key processing request may include relevant information related to the key operation to be processed; for example, the key processing request may include the identity identifier of the key to be operated, such as KEY ID, the type of operation to be performed, and related parameters.

[0038] In the embodiments of this application, the key processing request may include permission indication information. The permission indication information can be understood as a digital identifier used to clarify the various key permissions that the key has or does not have. The permission indication information carries all permission status information related to the key through a structured encoding method, namely a binary integer of a preset length. It is the core basis for the hardware security module to identify, verify or execute the key operation corresponding to the key processing request.

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

[0040] In the embodiments of this application, the preset length is the number of bits in a predefined binary integer representing key permissions. The preset length can be preset according to the total number of key permission categories required in actual business, and once set, it is used as a fixed parameter for encoding permission information. For example, if 16 key permissions are required in the actual application scenario, the preset length is 16 bits; if 32 key permissions are required, the preset length is 32 bits. Its function is to ensure that the number of bits in the binary integer completely matches the number of permission categories, thereby assigning a unique bit to each permission and avoiding conflicts or omissions in permission identification.

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

[0042] For example, if the key permissions involved in the actual application scenario are: import permission, signature verification permission, decryption permission, and encryption / 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. At the same time, the 0th bit of the permission indication information is set to correspond to encryption / decryption permission, the 1st bit to correspond to decryption permission, the 2nd bit to correspond to signature verification permission, and the 3rd bit to correspond to import permission. Assuming the first value is 1 and the second value is 0, the permission indication information is: 1011, which means that the key requested by the key processing request has or should have encryption / decryption permission (0th bit is 1), has decryption permission (1st bit is 1), has no signature verification permission (2nd bit is 0), and has import permission (3rd bit is 1).

[0043] For example, based on the above example, assuming the key processing request is a key generation request, the permission indication information 1011 can be understood as the requested key to be generated needs to have encryption / decryption permission (bit 0 is 1), has decryption permission (bit 1 is 1), does not need to have signature verification permission (bit 2 is 0), and needs to have import permission (bit 3 is 1); while 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 / decryption permission (bit 0 is 1), has decryption permission (bit 1 is 1), does not have signature verification permission (bit 2 is 0), and has import permission (bit 3 is 1).

[0044] Step 102: Determine the permissions of the key processing request indication based on the permission indication information, and verify the permissions of the key processing request indication based on the preset permission constraint policy to obtain the verification result; wherein, the verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint policy; the preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints; permission isolation constraints are used to prohibit a single key from having transmission permissions and also having at least one permission in the first permission set; import key permission constraints are used to prohibit keys imported from outside from having transmission permissions; transmission key constraints are used to restrict the source of transmission keys; derived key constraints are used to restrict the derivation range of the parent key.

[0045] In the embodiments of this application, the preset permission constraint policy is a set of predefined rules used to ensure that the key meets security requirements during generation, import, export, use and derivation, so as to reduce the possibility of key leakage or attack and thus improve the security of key processing.

[0046] In some embodiments of this application, permission isolation constraints can be used to allow a key to have other critical operation permissions in addition to 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 a key to decrypt the ciphertext of other keys and thus obtain the plaintext of other keys. Specifically, permission isolation constraints can prohibit a single key from having at least one of the following permissions when it has transmission permissions: encryption / decryption permissions, signature verification permissions, permissions to derive or negotiate new keys, and permissions to derive plaintext of keys.

[0047] In some embodiments of this application, the permission constraints on imported keys can effectively prevent externally imported keys from having transmission permissions, thus preventing attackers from compromising system security by importing malicious keys. Specifically, the permission constraints on imported 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.

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

[0049] Among them, the OTP key refers to the key burned during the hardware security module production stage, which cannot be changed and cannot be read by external parties.

[0050] In some embodiments of this application, derived key constraints are used to limit the derivation scope of a parent key. Specifically, derived key constraints can be used to restrict the permissions of a child key derived from a parent key to either encryption / decryption permissions or transmission permissions; that is, derived key constraints are used to prohibit a key from deriving both encryption / decryption permissions and transmission permissions.

[0051] It is understandable 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.

[0052] In embodiments of this application, the first set of permissions may include encryption / decryption permissions, signature verification permissions, permissions to derive or negotiate new keys, and permissions to export keys in plaintext. In embodiments of this application, key permissions can be understood as permissions to use a key, which determine the types of operations that the key can perform; for example, encryption / decryption permissions allow the use of the key to encrypt data, signature verification permissions allow the use of the key to generate digital signatures, permissions to derive or negotiate new keys allow the use of the key to generate new keys, permissions to export keys in plaintext form allow the export of the key, and transmission permissions allow the import / export of key encryption; this key must be a symmetric key.

[0053] In some embodiments of this application, when the hardware security module receives a key generation request, i.e., when the key processing request is a key generation request, the hardware security module can verify the permissions indicated by the key processing request based on a preset permission constraint policy. The method for obtaining the verification result may include: verifying the key permissions indicated by the key generation request based on permission isolation constraints; and then, if the key permissions are different and include at least one permission from the first permission set, the verification result corresponding to the key generation request is verification passed; otherwise, the verification result is verification failed.

[0054] For example, if the key generation request indicates that the permissions for the new key to be generated are transmission permissions and encryption / decryption permissions, the hardware security module determines that the verification result corresponding to the key generation request is verification failure.

[0055] In the embodiments of this 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, signing and other permissions. This design makes the generated keys inherently have security boundaries, reducing the potential risk of key abuse from the source, thereby improving the overall security level of key management.

[0056] In some embodiments of this 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. If the key permissions indicated by the key negotiation request do not simultaneously include at least one permission from the transmission permission and the first permission set, the verification result corresponding to the key negotiation request is determined to be a successful verification.

[0057] In some embodiments of this application, the source of the transmission key includes a one-time programmable key and / or a first subkey derived from the one-time programmable key.

[0058] In some embodiments of this application, when the hardware security module receives a key import request, i.e., 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. 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 constraints of the imported key, and verifying the first transmission key corresponding to the key to be imported based on the transmission key constraints; then, if the permissions of the key to be imported do not have transmission permissions, and the first transmission key is a one-time programmable key or a first subkey, the verification result corresponding to the key import request is verification passed; otherwise, the verification result is verification failed.

[0059] In embodiments of this application, the key import request may indicate relevant information about the key to be imported, as well as relevant information about the first transmission key used to decrypt the key to be imported.

[0060] In the embodiments of this application, during the key import process, combining the permission constraints of the imported key with the source restrictions of the transmission key can effectively prevent externally imported keys from carrying illegal transmission permissions, while ensuring that the transmission key itself comes 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 externally injected malicious keys.

[0061] In some embodiments of this application, when the hardware security module receives a key export request, i.e., 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. 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 permission isolation constraints, and verifying the second transmission key corresponding to the key to be exported based on transmission key constraints; then, if the key to be exported has export permissions, and the permissions of the key to be exported do not include at least one permission from the first permission set and the transmission permission, and the second transmission key is a one-time programmable key or a first subkey, then the verification result corresponding to the key export request is verification passed; otherwise, the verification result is verification failed.

[0062] In the embodiments of this application, a key export request refers to a request to export a specified key in encrypted form. The key export request may include the identification information of the specified key and the transmission key information to be used.

[0063] For example, the export permission can be the ciphertext export permission (PRIV_EXPORT_CIPHER). A key with this permission can support ciphertext export. When exporting, a key with the transmission permission (PRIV_TRANSPORT) needs to be specified to encrypt the key value.

[0064] In the embodiments of this application, the key export request needs to meet two conditions during the verification stage: first, the key to be exported must have export permission and cannot simultaneously have transmission permission and other key permissions; second, the transmission key used must be derived from a one-time key or its legitimate derivative. This ensures both the compliance of the exported key's permissions and the security and controllability of the transmission channel, further enhancing the security of the key export process.

[0065] In some embodiments of this application, derived key constraints are used to restrict the permissions of a child key derived from a parent key to either encryption / decryption permissions or transmission permissions; that is, in embodiments of this application, derived key constraints are used to restrict a parent key from simultaneously deriving a child key with encryption / decryption permissions and a child key with transmission permissions.

[0066] In some embodiments of this application, when the hardware security module receives a key derivation request, i.e., 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. The method for obtaining the verification result may include: verifying the permissions of the parent key indicated by the key derivation request and the first child key corresponding to the parent key based on the derived key constraint; then, if the parent key has the permission to derive or negotiate a new key, the first child key has encryption / decryption permissions, and the parent key's derived permissions are empty, or both are encryption / decryption permissions, the verification result corresponding to the key derivation request is determined to be verified as passed; wherein, the derived permissions represent the permissions of the child keys derived by the parent key; if the parent key has the permission to transmit or negotiate a new key, the first child key has transmission permissions, and the parent key's derived permissions are empty, or both are transmission permissions, the verification result is determined based on the source of the parent key.

[0067] In some embodiments of this application, a key derivation request may include identification information of a specified parent key and permission information of the desired child key; for example, a key derivation request may instruct the derivation of a new key with encryption and decryption permissions from a key with identifier KEY_ID=101, i.e., the identification information of the parent key is 101, and the desired child key, i.e., the first child key, has encryption and decryption permissions.

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

[0069] In the embodiments of this application, the first subkey permission is the transmission permission, which means that the parent key needs to derive a subkey with transmission permission. At this time, the source of the parent key also needs to be verified. This application only allows one-time programmable keys to derive subkeys with transmission permission. Therefore, if the source of the parent key is not a one-time programmable key, the verification will fail and key derivation will not be performed.

[0070] In some embodiments of this 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 successful; otherwise, the verification result is determined to be unsuccessful.

[0071] In some embodiments of this 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. If it is determined that the permissions of the key to be deleted include deletion permissions, the verification result is determined to be verification passed; if the permissions of the key to be deleted do not include deletion permissions, the verification result is determined to be verification failed.

[0072] In some embodiments of this 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.

[0073] In some embodiments of this 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.

[0074] Step 103: If the verification result is successful, perform the key processing operation corresponding to the key processing request.

[0075] In the embodiments of this application, the hardware security module determines the permissions indicated by the key processing request based on the permission indication information, verifies the permissions indicated by the key processing request based on the preset permission constraint policy, and after obtaining the verification result, can execute the key processing operation corresponding to the key processing request if the verification result is successful.

[0076] As can be understood, key processing operations refer to performing corresponding key processing operations according to the request content after the key permission verification is passed, such as key generation, import, export, derivation, deletion and other operations.

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

[0078] It is understandable 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 instruction carrying the identification information to the hardware security module, and the hardware security module accurately locates the first key stored in the random access memory through the identification information and executes the corresponding operation.

[0079] For example, some key processing operations can be shown in Table 1 below. In the key generation operation, the hardware security module can generate a new key and store it in a secure area, such as OTP or Random Access Memory (RAM), and send the identification of the new key, such as the key ID, to the main control module. The key import operation can import a key into the hardware security module, and the key export operation can export a key from the hardware security module. The key derivation operation can derive a key from a specified key, i.e., the parent key. Key negotiation can be asymmetric key negotiation, which allows two or more communicating parties to negotiate a shared symmetric key by exchanging public information on an insecure channel. This process does not require prior sharing of the key and can also ensure that third parties cannot obtain the negotiated shared key. Key deletion can delete a specified key.

[0080] Table 1

[0081]

[0082] In some embodiments of this 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 key's identification information to the main control module.

[0083] In some embodiments of this application, for key derivation operations, 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.

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

[0085] In the embodiments of this application, the key processing operation needs to be completed inside the hardware security module to ensure that the key data is not exposed to the external environment.

[0086] In some embodiments of this 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 to obtain the first plaintext data when performing the key processing operation corresponding to the key processing request; then remove the random data in the first plaintext data to obtain the first target key, and store the first target key to complete the key import operation.

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

[0088] It is understandable that the first plaintext data is the plaintext data of the key obtained after decrypting the key to be imported.

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

[0090] In some embodiments of this application, after the hardware module completes the storage of the first target key, it can send the identity information of the first target key to the main control module.

[0091] In the embodiments of this application, when storing the key, the hardware security module can store not only the key itself, but also the key's permission information.

[0092] In some embodiments of this application, when storing the permission information of the key, an independent bit can be assigned as an identifier for each specific permission of the key. The state of the bit indicates whether the key has the permission: 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 the permission. In terms of storage format, the bit states of all permissions can be integrated into a fixed-length integer value, such as 16 bits or 32 bits, and the specific length can depend on the total number of permissions supported by the system.

[0093] 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.

[0094] For example, such as Figure 2 As shown, the RAM storage area of ​​the hardware security module stores N keys, each with corresponding permission information and key data.

[0095] For example, as shown in Table 2 below, the permission information for each key can be 16 bits, with one bit corresponding to one permission. For instance, bit 0 corresponds to encryption / 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 removal permission (PRIV_REMOVE), and bits 10-15 are reserved for undefined functions that can be used for future expansion.

[0096] Table 2

[0097]

[0098] In the embodiments of this application, random data refers to random data added or removed during the key export or import process, which prevents attackers from establishing a correspondence between plaintext and ciphertext, thereby enhancing the system's resistance to attacks.

[0099] In some embodiments of this application, if the verification result corresponding to the key export request is successful, the hardware security module can perform the key export operation. When the key processing request is a key export request, the hardware security module, when performing the key export operation, can add random data to the plaintext data of the key to be exported to obtain second plaintext data; then, it can use the second transmission key to encrypt the second plaintext data to obtain the second target key, and export the second target key.

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

[0101] In the embodiments of this application, the second target key is the ciphertext form generated after encrypting the second plaintext data containing random data using the second transmission key.

[0102] Understandably, when a request is made to export a key, the hardware security module can first obtain the plaintext data of the key to be exported, and then insert random data into it to form new plaintext data, i.e., 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 the different random values. The mechanism of adding random data effectively prevents cryptanalysis methods based on known plaintext attacks and improves the security of key processing.

[0103] In some embodiments of this application, when adding random data, the hardware security module can either concatenate the random data to the plaintext data of the key to be exported, or it can fuse the random data into the original plaintext data through XOR operations or other methods. The specific method of adding the random data is not limited in this application.

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

[0105] In some embodiments of this application, if the verification result corresponding to the key deletion request is successful, the key deletion operation corresponding to the key deletion request can be executed to delete the specified key in the storage area.

[0106] In some embodiments of this application, if the verification result corresponding to the encryption / decryption request is successful, the encryption / decryption operation corresponding to the encryption / decryption request can be executed to encrypt / decrypt the specified key.

[0107] In some embodiments of this application, if the verification result corresponding to the signature / verification request is successful, the signature / verification operation corresponding to the signature / verification request can be executed, and the data can be signed or verified using the specified key.

[0108] In some embodiments of this application, the chip key processing method may further include the following steps:

[0109] Step 104: If the verification result is that the verification fails, do not perform key processing operations.

[0110] In the embodiments of this application, the hardware security module determines the permissions of the key processing request indication based on the permission indication information, and verifies the permissions of the key processing request indication based on the preset permission constraint policy. After obtaining the verification result, it may not perform the key processing operation if the verification result is that the verification fails.

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

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

[0113] This application provides a chip key processing method. A hardware security module receives a key processing request sent by a main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to one bit in the binary integer. A first value for the bit indicates possession of the corresponding key permission category, and a second value indicates non-possession of the corresponding key permission category. The permission indicated by the key processing request is determined based on the permission indication information, and the permission indicated by the key processing request is verified based on a preset permission constraint strategy to obtain a verification result. The verification is used to determine the key processing... The system checks whether the requested permissions comply with the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prevent a single key from having transmission permissions while also possessing at least one permission from the first permission set. Import key permission constraints are used to prevent keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, the key processing operation corresponding to the key processing request is executed. If the verification result is unsuccessful, the key processing operation is not executed. Therefore, 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 request. Then, it can utilize preset permission constraint policies to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other critical permissions, avoiding key abuse or leakage; import key permission constraints can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only originate from controlled one-time programmable keys and their derived subkeys, improving key chain security; derived key constraints restrict the permission type of the parent key when generating subkeys, avoiding the formation of attack paths and enhancing the overall system's anti-attack capability. Finally, key processing operations are only executed if permission verification passes, thereby greatly improving the security of the key processing process.

[0114] Based on the above embodiments, in another embodiment of this application, exemplarily, as follows: Figure 3As shown, chip 0 may include a hardware security module 1 and a host module 2. The host module may include a host CPU 21, host RAM 22, and a host unit 23. The host RAM is a random access memory directly managed and accessed by the host CPU. The host unit is a collection of integrated modules in the chip that undertake system-level main 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 module can 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 in during production, and the keys in the RAM can be obtained through import, internal generation, derivation, negotiation, and other operations. 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 the key's identity identifier, and the host module can use the key's identity identifier in commands to perform corresponding cryptographic calculations.

[0115] For example, based on the structure of the chip described above, such as Figure 4 As shown, the key generation / derivation / negotiation process may include the following steps:

[0116] Step 201: The main control module sends a key generation / derivation / negotiation request to the command processing unit of the hardware security module.

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

[0118] Step 203: The key management unit checks whether there are any permissions in the specified permissions that do not conform to the preset permission constraint policy, and in the case of derivation, checks whether the parent key has the corresponding permissions.

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

[0120] In the embodiments of this application, if the key management unit determines that the permission verification has passed, step 204 can be executed.

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

[0122] Step 206: Feed back the key ID to the main control module.

[0123] Step 207: Reject the operation and send an error message to the main control module.

[0124] In an embodiment of this application, if the permission verification fails, step 207 can be executed.

[0125] For example, such as Figure 5 As shown, the key import process may include the following steps:

[0126] Step 301: The main control module sends a key import request to the command processing unit of the hardware security module.

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

[0128] Step 303: The key management unit checks whether there are any permissions in the specified permissions that do not conform to the preset permission constraint policy.

[0129] Step 304: The key management unit uses the transmission key to decrypt the ciphertext and obtain the key.

[0130] In an embodiment of this application, if the permission verification passes, step 304 can be executed.

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

[0132] Step 306: Feed back the key ID to the main control module.

[0133] Step 307: Reject the operation and send an error message to the main control module.

[0134] In an embodiment of this application, if the permission verification fails, step 307 can be executed.

[0135] For example, such as Figure 6 As shown, the key export process may include the following steps:

[0136] Step 401: The main control module sends a key export request to the command processing unit of the hardware security module.

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

[0138] Step 403: The key management unit checks whether the specified key has export permissions and whether the relevant permissions comply with the preset permission constraint policy.

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

[0140] In an embodiment of this application, if the permission verification passes, step 404 can be executed.

[0141] Step 405: Encrypt the key using the transmission key to obtain the ciphertext.

[0142] Step 406: Output the ciphertext.

[0143] Step 407: Reject the operation and send an error message to the main control module.

[0144] In an embodiment of this application, if the permission verification fails, step 407 can be executed.

[0145] For example, such as Figure 7 As shown, the key deletion process may include the following steps:

[0146] Step 501: The main control module sends a key deletion request to the command processing unit of the hardware security module.

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

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

[0149] Step 504: Delete the specified key in the storage area.

[0150] In an embodiment of this application, if the permission verification passes, step 504 can be executed.

[0151] Step 505: Reject the operation and send an error message to the main control module.

[0152] In an embodiment of this application, if the permission verification fails, step 505 can be executed.

[0153] For example, such as Figure 8 As shown, the key usage process, including encryption / decryption and signing / verification, may include the following steps:

[0154] Step 601: The main control module sends a key usage request to the command processing unit of the hardware security module.

[0155] In this embodiment, the key usage request can be any one of an encryption / decryption request or a signature / verification request.

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

[0157] Step 603: The key management unit checks whether the specified key has the permissions corresponding to the purpose of the key.

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

[0159] In an embodiment of this application, if the permission verification passes, step 604 can be executed.

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

[0161] Step 606: Feed back the processing results to the main control module.

[0162] Step 607: Reject the operation and send an error message to the main control module.

[0163] In embodiments of this application, if the permission verification fails, a 607 error can be executed.

[0164] In some embodiments of this application, the storage area in the hardware security module stores key permission information when storing the key, for example, as described above. Figure 2 As shown, the RAM storage area of ​​the hardware security module stores N keys, each with corresponding permission information and key data.

[0165] For example, the key's permission information can be 16 bits, with one bit corresponding to one permission. For instance, bit 0 corresponds to encryption / 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 removal permission (PRIV_REMOVE), and bits 10-15 are reserved for undefined functions that can be used for future expansion.

[0166] In some embodiments of this 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 the permission.

[0167] For example, the following are some typical definitions of key permissions:

[0168] Encryption / decryption permission (PRIV_CIPHER): The key can be used for data encryption and decryption. The hardware security module can check this permission when using the key for encryption / decryption.

[0169] PRIV_SIGNATURE: The key can be used for data signing and verification, including generating Message Authentication Code (MAC) and verifying MAC; the hardware security module can check this permission when using the key for signing and verification.

[0170] Derivation or negotiation of new key permissions (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.

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

[0172] PRIV_DERIVE_TRANSPORT: When PRIV_DERIVE_TRANSPORT is 1, the key can be used to derive a new key with PRIV_DERIVE_TRANSPORT; when PRIV_DERIVE_TRANSPORT is 0, the key cannot derive a new key with PRIV_DERIVE_TRANSPORT. The hardware security module checks this permission when deriving a key, and the derived key has PRIV_DERIVE_TRANSPORT.

[0173] Plaintext import permission (PRIV_IMPORT_PLAIN): Allows the import of keys in plaintext form, 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.

[0174] Ciphertext Import Permission (PRIV_IMPORT_CIPHER): Allows the import of keys 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 the 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.

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

[0176] PRIV_EXPORT_CIPHER: The key can be exported in ciphertext. When exporting in ciphertext, a key with transmission permission must be specified to encrypt the exported key value. The hardware security module checks whether the key has this permission when exporting the key in ciphertext.

[0177] PRIV_REMOVE permission: The key can be deleted, and the hardware security module checks this permission when the key is deleted.

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

[0179] For example, this application proposes countermeasures to address some typical current attack methods, as shown in Table 3 and Table 3 (continued) below:

[0180] Table 3

[0181]

[0182] Table 3 (continued)

[0183]

[0184] In the embodiments of this application, the following rules can be summarized based on the above-described response methods:

[0185] (1) A key with PRIV_TRANSPORT permission cannot have any or a combination of PRIV_CIPHER, PRIV_SIGNATURE, PRIV_DERIVE_KEY and PRIV_EXPORT_PLAIN;

[0186] (2) Only the OTP key or its derived key can be configured with PRIV_TRANSPORT permission;

[0187] (3) Only OTP keys can be configured with PRIV_DERIVE_TRANSPORT permissions;

[0188] (4) Keys that are prohibited from being imported from outside must have PRIV_TRANSPORT permission;

[0189] (5) When exporting the ciphertext of the key, a random amount should be added to the plaintext data of the key. When importing the ciphertext, the random amount should be discarded after decryption.

[0190] In the embodiments of this application, the processing of various key processing requests based on the above rules, including verifying the permissions of different key processing requests and performing key processing operations after the verification is passed, can all be performed based on the above rules, thereby improving the security of key processing.

[0191] In summary, this application employs a combination of permission bits and special permission verification methods to protect the generation, import, export, deletion, and use of keys, ensuring the security of the processing and reducing the risk of attacks. Specifically, it may include binding a set of permission bits to all keys, including permissions such as encryption, decryption, signing, signature verification, transmission encryption, transmission signature, plaintext import, plaintext export, ciphertext import, ciphertext export, deletion, and write protection. Before key generation, import, export, derivation, negotiation, and use, key permissions are checked, and operations that do not meet the requirements are rejected. Transmission keys are prohibited from having permissions such as encryption, decryption, signing, and signature verification; a key is prohibited from having permissions to derive both non-transmission keys and transmission keys simultaneously; only OTP keys or their derived keys can be used as transmission keys; transmission keys are prohibited from having export permissions. Compared to current related key processing technologies, this application can ensure that key values ​​are not obtained by attackers without authentication. Furthermore, it improves performance by reducing authentication operations, and since transmission keys use the same design and checking process as other keys, the checking and verification effects can be achieved by relying on general permission rule definitions, making it more versatile.

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

[0193] The receiving unit 16 is used to receive a key processing request sent by the main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to a bit in the binary integer. The value of the bit is a first value, which indicates that the user has the corresponding key permission category. The value of the bit is a second value, which indicates that the user does not have the corresponding key permission category.

[0194] Verification unit 17 is used to determine the permissions of the key processing request indication based on the permission indication information, and to verify the permissions of the key processing request indication based on a preset permission constraint strategy to obtain a verification result; wherein, the verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint strategy; the preset permission constraint strategy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints; permission isolation constraints are used to prohibit a single key from having transmission permissions and also having at least one permission in the first permission set; import key permission constraints are used to prohibit keys imported from outside from having transmission permissions; transmission key constraints are used to restrict the source of transmission keys; and derived key constraints are used to restrict the derivation range of the parent key.

[0195] The key operation unit 18 is used to perform the key processing operation corresponding to the key processing request if the verification result is successful; and not to perform the key processing operation if the verification result is unsuccessful.

[0196] In some embodiments of this application, the first permission set includes encryption / decryption permission, signature verification permission, permission to derive or negotiate a new key, and permission to export the plaintext of the key; the key processing request includes a key generation request; the verification unit 17 is further configured to verify the key permissions indicated by the key generation request based on permission isolation constraints; and when the key permissions are different and include at least one permission from the transmission permission and the first permission set, the verification result corresponding to the key generation request is verification passed; otherwise, the verification result is verification failed.

[0197] In some embodiments of this 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 from the one-time programmable key; the verification unit 17 is further configured to verify the permissions of the key to be imported indicated by the key import request based on the permission constraints of the import key, and to verify the first transmission key corresponding to the key to be imported based on the transmission key constraints; and if the permissions of the key to be imported do not have transmission permissions, and the first transmission key is a one-time programmable key or a first subkey, the verification result corresponding to the key import request is verification passed; otherwise, the verification result is verification failed.

[0198] In some embodiments of this application, the key processing request includes a key export request; the verification unit 17 is further configured to verify the permissions of the key to be exported indicated by the key export request based on permission isolation constraints, and to verify the second transmission key corresponding to the key to be exported based on transmission key constraints; and if the key to be exported has export permissions, and the permissions of the key to be exported do not include at least one of the permissions in the first permission set and the transmission permission, and the second transmission key is a one-time programmable key or a first subkey, then the verification result corresponding to the key export request is verification passed; otherwise, the verification result is verification failed.

[0199] In some embodiments of this application, the key processing request includes a key derivation request; the derived key constraint is used to restrict the permissions of a child key derived from a parent key to either encryption / decryption permissions or transmission permissions; the verification unit 17 is further used to verify the permissions of the parent key indicated by the key derivation request and the first child key corresponding to the parent key based on the derived key constraint; and to determine that the verification result corresponding to the key derivation request is verified as passed when the parent key has the permission to derive or negotiate a new key, the first child key has the permission to encrypt / decrypt, and the parent key's derived permissions are empty, or both are encryption / decryption permissions; wherein, the derived permissions represent the permissions of the child keys derived from the parent key; and to determine the verification result based on the source of the parent key when the parent key has the permission to transmit, the first child key has the permission to transmit, and the parent key's derived permissions are empty, or both are transmission permissions.

[0200] In some embodiments of this application, the verification unit 17 is further configured to determine that the verification result is successful if the source of the parent key is a one-time programmable key; otherwise, determine that the verification result is unsuccessful.

[0201] In some embodiments of this application, the key operation unit 18 is further configured to, when the key processing request is a key import request, decrypt the key to be imported using a first transmission key to obtain first plaintext data; remove random data from 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 data to the plaintext data of the key to be exported to obtain second plaintext data; encrypt the second plaintext data using a second transmission key to obtain a second target key, and export the second target key.

[0202] In some embodiments of this application, the key operation unit 18 is further configured 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 generate identification information of the first key and send the identification information of the first key to the main control module.

[0203] This application provides a hardware security module, which includes a receiving unit, a verification unit, and a key operation unit. The receiving unit receives a key processing request sent by a main control module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to one bit in the binary integer. A first value of the bit indicates possession of the corresponding category of key permission, and a second value indicates non-possession of the corresponding category of key permission. The verification unit determines the permission indicated by the key processing request based on the permission indication information and performs verification based on a preset permission constraint strategy. The system performs a verification process to obtain a verification result. The verification determines whether the permissions indicated by the key processing request comply with a preset permission constraint policy. This preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints prevent a single key from possessing transmission permissions while also possessing at least one permission from the first permission set. Import key permission constraints prevent keys imported from external sources from having transmission permissions. Transmission key constraints restrict the source of transmission keys. Derived key constraints restrict the derivation range of the parent key. A key operation unit executes the key processing operation corresponding to the key processing request if the verification result is successful. Therefore, 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 request. Then, it can use preset permission constraint policies to verify the relevant permissions of the key processing request. Specifically, permission isolation constraints can effectively prevent transmission permissions from coexisting with other critical permissions, avoiding key abuse or leakage; import key permission constraints can prevent externally imported keys from having sensitive transmission permissions; transmission key constraints can ensure that transmission keys only originate from controlled one-time programmable keys and their derived subkeys, improving key chain security; and derived key constraints restrict the permission type of the parent key when generating subkeys, avoiding the formation of attack paths and enhancing the overall system's resistance to attacks. This greatly improves the security of the key processing process.

[0204] Furthermore, embodiments of this application propose a chip, as described above. Figure 3 As shown, chip 0 may include hardware security module 1 and main control module 2.

[0205] The main control module 2 can be used to send the received key processing request to the hardware security module. The key processing request includes permission indication information, which is a binary integer of a preset length. The preset length corresponds to the number of key permission categories. Each key permission corresponds to one bit in the binary integer. The first value of the bit indicates that the user has the corresponding key permission, and the second value of the bit indicates that the user does not have the corresponding key permission.

[0206] Hardware security module 1 can be used to determine the permissions of the key processing request indication based on the permission indication information, and to verify the permissions of the key processing request indication based on a preset permission constraint policy to obtain a verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from having transmission permissions while also possessing at least one permission from a first set of permissions. Import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, the key processing operation corresponding to the key processing request is executed; if the verification result is unsuccessful, the key processing operation is not executed.

[0207] Furthermore, in this embodiment, the functional modules can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional module.

[0208] If the integrated unit is implemented as a software functional module and is 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, in essence, or the part 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 to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the method of this embodiment. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0209] Specifically, the program instructions corresponding to a chip key processing method in this embodiment can be stored on storage media such as optical discs, hard disks, and USB flash drives. When the program instructions corresponding to a chip key processing method in the storage media are read or executed by an electronic device, the following steps are included:

[0210] Receive key processing requests 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 key permission categories, each key permission corresponds to one bit in the binary integer, the value of the bit is the first value indicating that the corresponding category of key permission is possessed, the value of the bit is the second value indicating that the corresponding category of key permission is not possessed;

[0211] The permissions of the key processing request indication are determined based on the permission indication information, and the permissions of the key processing request indication are verified based on a preset permission constraint policy to obtain the verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. Permission isolation constraints are used to prohibit a single key from having transmission permissions while also possessing at least one permission from the first permission set. Import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. Transmission key constraints are used to restrict the source of transmission keys. Derived key constraints are used to restrict the derivation range of the parent key.

[0212] If the verification result is successful, execute the key processing operation corresponding to the key processing request.

[0213] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, cause a computer to perform the steps in the method provided in the above-described method embodiments.

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

[0215] This application is described with reference to schematic and / or block diagrams of implementations of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the schematic and / or block diagrams can be implemented by computer program instructions, and combinations of blocks in the schematic and / or block diagrams can be implemented. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the schematic and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0216] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are 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.

[0217] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

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

Claims

1. A chip key processing method, characterized in that, The method includes: The chip's 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 key permission categories, each key permission corresponds to a bit in the binary integer, the value of the bit is a first value indicating that it has the key permission of the corresponding category, the value of the bit is a second value indicating that it does not have the key permission of the corresponding category; The permissions of the key processing request indication are determined based on the permission indication information, and the permissions of the key processing request indication are verified based on a preset permission constraint policy to obtain a verification result. The verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. The permission isolation constraints are used to prohibit a single key from possessing transmission permissions while also possessing at least one permission from a first permission set. The import key permission constraints are used to prohibit keys imported from external sources from possessing transmission permissions. The transmission key constraints are used to restrict the source of transmission keys. The derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, 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 set of permissions includes encryption / decryption permissions, signature verification permissions, permissions to derive or negotiate new keys, and permissions to export keys in plaintext. The key processing request includes a key generation request; The step of verifying the permissions indicated by the key processing request based on a preset permission constraint policy, and obtaining the verification result, includes: The permissions indicated by the key generation request are verified based on the permission isolation constraints. If the permissions indicated by the key generation request are different and include at least one of the transmission permissions and the first set of permissions, 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 from the one-time programmable key; The step of verifying the permissions indicated by the key processing request based on a preset permission constraint policy, and obtaining the verification result, includes: The permissions of the key to be imported indicated by the key import request are verified based on the permission constraints of the import key, and the first transmission key corresponding to the key to be imported is verified based on the transmission key constraints. If the key to be imported does not have the permission to transmit, 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 export request; The step of verifying the permissions indicated by the key processing request based on a preset permission constraint policy, and obtaining the verification result, includes: The permissions of the key to be exported indicated by the key export request are verified based on the permission isolation constraints, and the second transmission key corresponding to the key to be exported is verified based on the transmission key constraints. If the key to be exported has export permission, and the permissions of the key to be exported do not simultaneously include at least one of the transmission permission and 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 export 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 restrict the permissions of a child key derived from a parent key to either encryption / decryption permissions or transmission permissions. The step of verifying the permissions indicated by the key processing request based on a preset permission constraint policy, and obtaining the verification result, includes: The permissions of the parent key indicated by the key derivation request and the first child key corresponding to the parent key are verified based on the derived key constraints. If the parent key has the permission to derive or negotiate a new key, the first child key has the permission to encrypt or decrypt, and the parent key's derived permissions are empty or both are encryption or decryption permissions, then the verification result corresponding to the key derivation request is determined to be verified as passed; wherein, the derived permissions represent the permissions of the child keys derived from the parent key. If the parent key has transmission derivation permission, the first child key has the transmission permission, and the parent key has no derivation permission, or both have 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, Determining the verification result based on the source of the parent key includes: If the source of the parent key is a one-time programmable key, the verification result is determined to be a successful verification; otherwise, the verification result is determined to be a failed verification.

7. The chip key processing method according to claim 4, characterized in that, The key processing operation corresponding to the key processing request includes: When the key processing request is the key import request, the key to be imported is decrypted using the first transmission key to obtain the first plaintext data; The random data in the first plaintext data is removed to obtain the first target key, and the first target key is stored to complete the key import operation. If the key processing request is a key export request, random data is added to the plaintext data of the key to be exported to obtain the second plaintext data; The second plaintext data is encrypted using the second transmission key to obtain the second target key, which is then derived.

8. The chip key processing method according to claim 2 or 3, characterized in that, The method further includes: The first key is stored in 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. The identification information of the first key is generated and sent 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 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 key permission categories, 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 present, the value of the bit is a second value indicating that the key permission of the corresponding category is not present; The verification unit is used to determine the permissions of the key processing request indication based on the permission indication information, and to verify the permissions of the key processing request indication based on a preset permission constraint policy to obtain a verification result; wherein, the verification is used to determine whether the permissions of the key processing request indication comply with the constraints of the preset permission constraint policy; the preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints; the permission isolation constraints are used to prohibit a single key from having transmission permissions while also having at least one permission from a first set of permissions; the import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions; the transmission key constraints are used to restrict the source of transmission keys; and the derived key constraints are used to restrict the derivation range of the parent key; The key operation unit is used to perform the key processing operation corresponding to the key processing request if the verification result is successful.

10. A chip, characterized in that, Including the main control module and the hardware security module; The main control module is 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 key permission categories, each key permission corresponds to a bit in the binary integer, the value of the bit is a first value indicating that the corresponding category of key permission is possessed, the value of the bit is a second value indicating that the corresponding category of key permission is not possessed; The hardware security module is used to determine the permissions indicated by the key processing request based on the permission indication information, and to verify the permissions indicated by the key processing request based on a preset permission constraint policy to obtain a verification result. The verification is used to determine whether the permissions indicated by the key processing request comply with the preset permission constraint policy. The preset permission constraint policy includes permission isolation constraints, import key permission constraints, transmission key constraints, and derived key constraints. The permission isolation constraints are used to prohibit a single key from having transmission permissions while also possessing at least one permission from a first set of permissions. The import key permission constraints are used to prohibit keys imported from external sources from having transmission permissions. The transmission key constraints are used to restrict the source of the transmission key. The derived key constraints are used to restrict the derivation range of the parent key. If the verification result is successful, the key processing operation corresponding to the key processing request is executed.

Images