Method for implementing key management and access control based on hardware security module

Abstract

The application relates to a method for realizing key management and access control based on a hardware security module, comprising the following steps: internally storing a root key in a hardware security module (HSM); registering identity credentials of an authorized hardware signature device to a device white list in the HSM by using an identifier and a random salt value, so as to establish a binding relationship between a business key and the authorized hardware signature device; creating an aggregation task by a KMS gateway, and collecting independent signatures; and performing batch verification in a stateless mode by the HSM, unsealing a business private key and performing a digital signature operation. The method, system, device, processor and computer readable storage medium thereof for realizing key management and access control based on the hardware security module can make an operator understand and audit signature content, reduce front-end tampering and opaque signature risks, and balance key escrow extensibility, access control reliability, firmware audit convenience and operation stability in a high-sensitivity business scenario.

Description

Technical Field

[0001] This invention relates to the field of information security, and more particularly to the field of cryptography, specifically to a method, system, device, processor, and computer-readable storage medium for implementing key management and access control based on a hardware security module. Background Technology

[0002] With the rapid advancement of informatization and digital transformation, key lifecycle management has become a key element in ensuring the security of core enterprise data. Especially in enterprise-level applications and high-security scenarios, the secure storage and compliant use of private keys are crucial. However, existing key management solutions still face irreconcilable technical contradictions between security, flexibility, and controllability, mainly reflected in the following three dimensions: 1. Opaque Signature and Supply Chain Attack Risks in Business Software Layers. Business front-end software is vulnerable to supply chain attacks (such as third-party library poisoning or code tampering) or UI fraud. Because the data to be signed transmitted at the underlying level is a difficult-to-read hash value or binary stream, operators cannot intuitively interpret the true semantics of the signature request and can only passively click "confirm" based on trust in the software interface. Attackers can tamper with the front-end code to induce operators to confirm seemingly normal signature requests on hardware devices, when in fact they are signing tampered malicious data, creating an opaque signature vulnerability.

[0003] 2. Security and scalability bottlenecks in key storage architecture. In enterprise-level key management systems (KMS gateways), existing storage architectures mainly fall into two categories, both of which have significant shortcomings: (1) Fully hardware managed While storing private keys entirely within the HSM offers high physical security, the physical limitations of the HSM's internal secure storage space (typically only capable of holding a few thousand key pairs) make it difficult to support the key management needs of large enterprises with massive business volumes (millions of key pairs). Furthermore, the rigid firmware logic within the HSM results in long development and iteration cycles, making it difficult to implement complex dynamic business risk control strategies (such as dynamic limit adjustments and real-time blacklist / whitelist filtering).

[0004] (2) Software hosting The private key is encrypted and stored in an external database, and then decrypted in the server's memory when needed. While this method offers good flexibility and scalability, the plaintext private key is briefly exposed in the server's memory, making it vulnerable to memory scanning, side-channel attacks, or unauthorized export by internal personnel. This makes it difficult to meet high-level compliance requirements such as FIPS 140-2 or EAL4+.

[0005] 3. Lack of device identity control in multi-stakeholder governance mechanisms. In critical information infrastructure or highly sensitive business scenarios, core operations often require collaborative governance from multiple roles, including operations and maintenance, risk control, and auditing. Existing solutions have significant shortcomings: (1) Centralized approval with multiple signatures Traditional centralized multi-signature solutions heavily rely on the approval logic of a centralized server, posing a single point of failure risk. Furthermore, centralizing an enterprise's internal approval structure and governance logic on a single node means that if that node is compromised, the entire signature authorization mechanism can be bypassed. More critically, changes to approval strategies often require downtime for deployment, resulting in poor flexibility.

[0006] (2) MPC threshold signature Although cryptographic sharding avoids centralized key storage, its cryptographic protocol implementation is relatively complex and code auditing is difficult. Furthermore, when personnel changes occur or threshold parameters (M / N values) need to be adjusted, it involves cumbersome key sharding and reassembly processes, resulting in poor operational flexibility.

[0007] In summary, the industry urgently needs a hardware-based end-to-end multisignature key management solution that can fully utilize the physical security features of HSMs to protect massive amounts of keys, reduce software-level risks through hardware-level device fingerprint binding, and simultaneously achieve flexible and efficient multi-principal signature policy control. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, system, device, processor and computer-readable storage medium for key management and access control based on a hardware security module that is efficient, secure and widely applicable.

[0009] To achieve the above objectives, the present invention provides a method, system, apparatus, processor, and computer-readable storage medium for key management and access control based on a hardware security module, as follows: The key feature of this method for implementing key management and access control based on a hardware security module is that the method includes the following steps: (1) The root key is securely stored inside the hardware security module HSM; (2) Using the root key combined with the business key identifier and random salt value, the business key encryption key is derived through the key derivation function, and the business private key is encrypted and encapsulated using the authentication encryption algorithm and then stored in the HSM external database. (3) Register the identity credentials of the authorized hardware signing device to the device whitelist inside the HSM to establish a binding relationship between the business key and the authorized hardware signing device, wherein the device whitelist and the business key are stored independently inside the HSM and the encrypted records of the device whitelist and the business key are stored and managed independently respectively. (4) For each service to be signed, the KMS gateway creates an aggregation task to generate a unified authorization payload that includes at least the service key identifier, request identifier, random number, policy version number, request validity period and hash of the data to be signed, and sends the unified authorization payload to N authorized hardware signature devices to collect the independent signatures generated by at least M devices among the N authorized hardware signature devices for the unified authorization payload; (5) The KMS gateway generates a batch integrity verification value and sends the device signature, device identity certificate, business key ciphertext record and batch integrity verification value to the HSM at once; (6) HSM performs batch verification in a stateless manner, including at least the verification of policy version validity, device whitelist attribution, authorization payload signature validity, business key ciphertext record binding relationship and device identity credential unique counting rule under the same request identifier. After the number of valid signatures reaches the threshold M, the business private key is unsealed and digital signature operation is performed, and the request identifier and policy version number bound to the business signature are returned.

[0010] Preferably, step (2) of encrypting and encapsulating the business private key specifically includes the following steps: HSM derives the business key encryption key from the root key, random salt value, and derived inputs including business key identifier, version context, and algorithm identifier through HKDF. It then uses AES-256-GCM to authenticate and encrypt the business private key, outputting ciphertext, initialization vector, and authentication tag. During decryption, it performs authentication and decryption based on the same derived inputs and additional authentication data AAD.

[0011] Preferably, the Additional Authentication Data (AAD) is composed of a Business Key Identifier and an Algorithm Identifier. The Business Key Ciphertext Record includes at least the ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier, and is stored in an external database of the HSM. If the AAD is inconsistent with the encapsulation stage during decapsulation, authentication fails and decryption is refused.

[0012] Preferably, the method further includes the following steps: The KMS gateway integrates a semantic parsing engine to parse the data to be signed that conforms to the structured data standard, extracts key business fields to generate a signature digest, and performs real-time interception and auditing based on preset risk control rules. The authorized payload also includes a semantic digest identifier and a request validity period corresponding to the signature digest.

[0013] Preferably, the device whitelist and threshold parameters are access control policies independent of the business key, stored and managed independently in partitions within the HSM, and support dynamic adjustment at runtime; wherein, new device registration requires confirmation by management key signature, and the HSM writes the new device identity into the whitelist after verifying the management key signature; device revocation takes effect immediately, and subsequent signature requests from revoked devices are rejected by the HSM.

[0014] Preferably, the method further includes the following steps: For multi-signature requests that have been created but not yet completed, the KMS gateway freezes the policy version when creating the aggregation task, and the HSM confirms whether the policy version is still in the state of being allowed to complete during the final verification. The policy version is managed by a monotonically increasing version counter inside the HSM, and any whitelist or threshold policy with a version number less than the current active version number shall not be reactivated.

[0015] Preferably, the HSM internal maintenance policy record includes at least a business key identifier, a list of authorized device identity credentials, a threshold value M, a policy version number, a device status, a management key signature, an effective time, and a revocation identifier, and is stored in the HSM internal secure storage area. External databases or KMS cannot modify its effective status independently. The management key signature covers at least the following fields: business key identifier, device identity credentials, permission scope, threshold parameters, policy version number, and effective time. The HSM verifies the management key signature before writing or updating the policy, and the policy only becomes effective after successful verification.

[0016] Preferably, the batch integrity verification value at least covers the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period; when the HSM verifies the signatures of each device in batches, it counts the same device identity credential that appears repeatedly under the same request identifier only once.

[0017] Preferably, the KMS gateway performs signature collection, replay protection check, time window control, policy version freezing, and request aggregation, while the HSM performs device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption, and final signature calculation. After completing threshold verification and generating a business signature, the HSM returns the request identifier and policy version number bound to the business signature, enabling the KMS to uniquely match the final signature result with the corresponding aggregation task.

[0018] The system for key management and access control based on a hardware security module is characterized by the following: The client hardware device layer includes multiple authorized hardware signing devices. Each authorized hardware signing device has a built-in security chip, in which a device private key is stored in a non-derivative manner. This key is used to provide device identity credentials and generate a device signature for a unified authorized payload. Each authorized hardware signing device is connected to the KMS gateway through a secure communication channel. The business key storage layer is used to store encrypted and encapsulated records of business private keys. The hardware security module, connected to the business key storage layer, includes a root key storage module, a device whitelist management module, a threshold verification module, a business key desealing module, and a cryptographic operation module. The root key storage module stores the root key within the HSM physical boundary. The device whitelist management module maintains the device whitelist and policy version in the secure storage area inside the HSM. The threshold verification module verifies batch integrity, policy version, and device signature and performs threshold judgment. The business key desealing module derives the business key encryption key and deseales the business private key. The cryptographic operation module performs digital signature operations on the data to be signed. The KMS gateway, connected to the client hardware device layer and hardware security module, includes a request aggregator, a semantic parsing engine, and a risk control rule engine. The request aggregator is used to receive signature requests, create aggregation tasks, collect device signatures from at least M devices among N authorized hardware signature devices, and generate batch integrity verification values. The semantic parsing engine is used to parse the data to be signed to generate signature digests. The risk control rule engine is used to perform risk interception.

[0019] Preferably, the device whitelist management module maintains a mapping relationship between business key identifiers and authorized device lists. The mapping relationship is stored in the internal secure storage area of ​​the HSM and its integrity is protected by management key signature. The HSM also maintains a monotonically increasing version counter to prevent rollback attacks.

[0020] Preferably, the KMS gateway and the hardware security module adopt a separation of duties design. The KMS gateway is responsible for signature collection, anti-replay check, time window control, policy version freezing, and request aggregation, while the hardware security module is responsible for device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption, and final signature calculation.

[0021] Preferably, the batch integrity verification value at least covers the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period, so that the hardware security module can identify whether the aggregated batch has been replaced, deleted, spliced, or reused across requests.

[0022] Preferably, when the threshold verification module performs batch verification of signatures of each device, it counts the same device identity credential that appears repeatedly under the same request identifier only once.

[0023] Preferably, the policy version is managed by a monotonically increasing version counter within the HSM. Any whitelist or threshold policy with a version number less than the current active version number shall not be reactivated to prevent the rollback and replay of old policies. The policy records in the device whitelist management module are protected by management key signatures. The device whitelist management module verifies the management key signature before writing or updating a policy, and the policy can only be activated after the verification is successful.

[0024] Preferably, after completing threshold verification and generating a business signature, the cryptographic operation module returns a request identifier and policy version number bound to the business signature, enabling the KMS gateway to uniquely match the final signature result with the corresponding aggregation task, thereby preventing the signature result from being reused across requests.

[0025] Preferably, the business key decryption module derives a business key encryption key from the root key, a random salt value, and derived inputs including the business key identifier, version context, and algorithm identifier through HKDF, and uses AES-256-GCM to perform authentication encryption and authentication decryption on the business private key. The business private key ciphertext record in the business key storage layer includes at least the ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier.

[0026] The device for key management and access control based on a hardware security module is characterized in that the device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the above-described method for key management and access control based on a hardware security module.

[0027] The processor that implements key management and access control based on a hardware security module is characterized in that the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the various steps of the above-mentioned method for implementing key management and access control based on a hardware security module are implemented.

[0028] The main feature of this computer-readable storage medium is that it stores a computer program thereon, which can be executed by a processor to implement the various steps of the above-described method for key management and access control based on a hardware security module.

[0029] This invention employs a method, system, apparatus, processor, and computer-readable storage medium for key management and access control based on a hardware security module. By semantically parsing structured data to be signed at the gateway layer and maintaining device whitelists, threshold policies, and policy versions within the hardware security module, business key usage permissions are bound to authorized hardware signing devices and aggregation requests. Simultaneously, a root key-derived encapsulated key is used to authenticate and encrypt the business private key before external storage. The gateway is responsible for signature collection, policy freezing, and batch integrity encapsulation. The hardware security module performs stateless batch verification, deduplication counting, key decapsulation, and final signing. This allows operators to understand and audit signature content, reducing the risk of front-end tampering and opaque signatures. It blocks attack paths such as unauthorized modification of permissions, rollback of old policies, replacement of ciphertext, or batch concatenation triggering signatures at the software layer. Furthermore, it supports member revocation and policy adjustment without relying on external centralized approval or key fragmentation and reassembly, balancing key escalability, access control reliability, firmware auditing convenience, and operational stability in highly sensitive business scenarios. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the overall architecture of the system for implementing key management and access control based on a hardware security module according to the present invention.

[0031] Figure 2 This is a schematic diagram illustrating the key creation and hierarchical storage timing of the key management and access control method based on a hardware security module according to the present invention.

[0032] Figure 3 This is a schematic diagram of the M-of-N multi-principal signature authorization timing for the method of implementing key management and access control based on a hardware security module according to the present invention.

[0033] Figure 4 This is a schematic diagram illustrating the device identity binding and verification timing of the method for implementing key management and access control based on a hardware security module according to the present invention. Detailed Implementation

[0034] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0035] The method for key management and access control based on a hardware security module of the present invention includes the following steps: (1) The root key is securely stored inside the hardware security module HSM; (2) Using the root key combined with the business key identifier and random salt value, the business key encryption key is derived through the key derivation function, and the business private key is encrypted and encapsulated using the authentication encryption algorithm and then stored in the HSM external database. (3) Register the identity credentials of the hardware signing device to the device whitelist inside the HSM to establish a binding relationship between the business key and the authorized hardware signing device, wherein the device whitelist and the business key are stored independently inside the HSM and the encrypted records of the device whitelist and the business key are stored and managed independently respectively. (4) For each service to be signed, the KMS gateway creates an aggregation task to generate a unified authorization payload that includes at least the service key identifier, request identifier, random number, policy version number, request validity period and hash of the data to be signed, and sends the unified authorization payload to N authorized hardware signature devices to collect the independent signatures generated by at least M devices among the N authorized hardware signature devices for the unified authorization payload; (5) The KMS gateway generates a batch integrity verification value and sends the device signature, device identity certificate, business key ciphertext record and batch integrity verification value to the HSM at once; (6) HSM performs batch verification in a stateless manner, including at least the verification of policy version validity, device whitelist attribution, authorization payload signature validity, business key ciphertext record binding relationship and device identity credential unique counting rule under the same request identifier. After the number of valid signatures reaches the threshold M, the business private key is unsealed and digital signature operation is performed, and the request identifier and policy version number bound to the business signature are returned.

[0036] In a preferred embodiment of the present invention, the encryption and encapsulation of the business private key in step (2) specifically includes the following steps: HSM derives the business key encryption key from the root key, random salt value, and derived inputs including business key identifier, version context, and algorithm identifier through HKDF. It then uses AES-256-GCM to authenticate and encrypt the business private key, outputting ciphertext, initialization vector, and authentication tag. During decryption, it performs authentication and decryption based on the same derived inputs and additional authentication data AAD.

[0037] In a preferred embodiment of the present invention, the Additional Authentication Data (AAD) is composed of a business key identifier and an algorithm identifier. The business key ciphertext record includes at least ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier, and is stored in an external database of HSM. If the AAD is inconsistent with the encapsulation stage during decapsulation, authentication fails and decryption is refused.

[0038] In a preferred embodiment of the present invention, the method further includes the following steps: The KMS gateway integrates a semantic parsing engine to parse the data to be signed that conforms to the structured data standard, extracts key business fields to generate a signature digest, and performs real-time interception and auditing based on preset risk control rules. The authorized payload also includes a semantic digest identifier and a request validity period corresponding to the signature digest.

[0039] In a preferred embodiment of the present invention, the device whitelist and threshold parameters are access control policies independent of the business key, stored and managed independently in partitions within the HSM, and support dynamic adjustment at runtime; wherein, new device registration requires confirmation by management key signature, and the HSM writes the new device identity into the whitelist after verifying the management key signature; device revocation takes effect immediately, and subsequent signature requests from revoked devices are rejected by the HSM.

[0040] In a preferred embodiment of the present invention, the method further includes the following steps: For multi-signature requests that have been created but not yet completed, the KMS gateway freezes the policy version when creating the aggregation task, and the HSM confirms whether the policy version is still in the state of being allowed to complete during the final verification. The policy version is managed by a monotonically increasing version counter inside the HSM, and any whitelist or threshold policy with a version number less than the current active version number shall not be reactivated.

[0041] In a preferred embodiment of the present invention, the HSM internal maintenance policy record includes at least a business key identifier, a list of authorized device identity credentials, a threshold value M, a policy version number, a device status, a management key signature, an effective time, and a revocation identifier, and is stored in the HSM internal secure storage area. External databases or KMS cannot modify its effective status independently. The management key signature covers at least the following fields: business key identifier, device identity credentials, permission scope, threshold parameters, policy version number, and effective time. The HSM verifies the management key signature before writing or updating the policy, and the policy can only take effect after successful verification.

[0042] In a preferred embodiment of the present invention, the batch integrity verification value at least covers the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period; when the HSM verifies the signatures of each device in batches, it counts the same device identity credential that appears repeatedly under the same request identifier only once.

[0043] In a preferred embodiment of the present invention, the KMS gateway performs signature collection, anti-replay check, time window control, policy version freezing, and request aggregation; the HSM performs device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption, and final signature calculation; after completing threshold verification and generating a business signature, the HSM returns the request identifier and policy version number bound to the business signature, enabling the KMS to uniquely match the final signature result with the corresponding aggregation task.

[0044] The present invention discloses a system for key management and access control based on a hardware security module, wherein the system includes: The client hardware device layer includes multiple authorized hardware signing devices. Each authorized hardware signing device has a built-in security chip, in which a device private key is stored in a non-derivative manner. This key is used to provide device identity credentials and generate a device signature for a unified authorized payload. Each authorized hardware signing device is connected to the KMS gateway through a secure communication channel. The business key storage layer is used to store encrypted and encapsulated records of business private keys. The hardware security module, connected to the business key storage layer, includes a root key storage module, a device whitelist management module, a threshold verification module, a business key desealing module, and a cryptographic operation module. The root key storage module stores the root key within the HSM physical boundary. The device whitelist management module maintains the device whitelist and policy version in the secure storage area inside the HSM. The threshold verification module verifies batch integrity, policy version, and device signature and performs threshold judgment. The business key desealing module derives the business key encryption key and deseales the business private key. The cryptographic operation module performs digital signature operations on the data to be signed. The KMS gateway, connected to the client hardware device layer and hardware security module, includes a request aggregator, a semantic parsing engine, and a risk control rule engine. The request aggregator is used to receive signature requests, create aggregation tasks, collect device signatures from at least M devices among N authorized hardware signature devices, and generate batch integrity verification values. The semantic parsing engine is used to parse the data to be signed to generate signature digests. The risk control rule engine is used to perform risk interception.

[0045] In a preferred embodiment of the present invention, the device whitelist management module maintains a mapping relationship between business key identifiers and authorized device lists. The mapping relationship is stored in the internal secure storage area of ​​the HSM and its integrity is protected by management key signature. In addition, the HSM maintains a monotonically increasing version counter to prevent rollback attacks.

[0046] In a preferred embodiment of the present invention, the KMS gateway and the hardware security module adopt a separation of duties design. The KMS gateway is responsible for signature collection, anti-replay check, time window control, policy version freezing and request aggregation, while the hardware security module is responsible for device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption and final signature calculation.

[0047] In a preferred embodiment of the present invention, the batch integrity verification value at least covers the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period, so that the hardware security module can identify whether the aggregated batch has been replaced, deleted, spliced, or reused across requests.

[0048] In a preferred embodiment of the present invention, when the threshold verification module verifies the signatures of each device in batches, it counts the same device identity credential that appears repeatedly under the same request identifier only once.

[0049] In a preferred embodiment of the present invention, the policy version is managed by a monotonically increasing version counter inside the HSM. Any whitelist or threshold policy with a version number less than the current active version number shall not be reactivated to prevent the old policy from being rolled back and replayed. The policy records in the device whitelist management module are protected by management key signatures. The device whitelist management module verifies the management key signature before writing or updating the policy, and the policy can only be activated after the verification is successful.

[0050] In a preferred embodiment of the present invention, after completing threshold verification and generating a business signature, the cryptographic operation module returns a request identifier and policy version number bound to the business signature, enabling the KMS gateway to uniquely match the final signature result with the corresponding aggregation task, thereby preventing the signature result from being reused across requests.

[0051] In a preferred embodiment of the present invention, the business key decryption module derives the business key encryption key through HKDF based on the root key, random salt value, and derived input including business key identifier, version context, and algorithm identifier, and uses AES-256-GCM to perform authentication encryption and authentication decryption on the business private key. The business private key ciphertext record in the business key storage layer includes at least the ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier.

[0052] The present invention provides a device for implementing key management and access control based on a hardware security module, wherein the device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the above-described method for key management and access control based on a hardware security module.

[0053] The processor of the present invention implements key management and access control based on a hardware security module, wherein the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the various steps of the above-described method for implementing key management and access control based on a hardware security module are implemented.

[0054] The computer-readable storage medium of the present invention stores a computer program thereon, which can be executed by a processor to implement the various steps of the above-described method for key management and access control based on a hardware security module.

[0055] To address the aforementioned deficiencies in existing technologies, this invention aims to provide a key management and access control method and system based on a hardware security module. The technical problems to be solved include: First, this invention addresses the risks of opaque signatures on the operator side and the problem of front-end supply chain attacks. It constructs a two-layer protection mechanism of "semantic transparency + hardware identity binding": A structured data parsing engine is integrated into the KMS gateway to perform semantic parsing of the data to be signed (e.g., identifying operation type, key parameters, target objects, etc.), making the signature content understandable and auditable for operators. Simultaneously, within the HSM security boundary, key usage permissions are strongly bound to the identity credentials of specific physical hardware devices—the HSM only performs the signature operation when the signature request carries an authorized device credential verified by the HSM. This mechanism ensures that even if the front-end software suffers a supply chain attack, the attacker, lacking an authorized physical device, cannot trigger the HSM to execute the signature, thus effectively preventing opaque signature vulnerabilities.

[0056] Second, this invention addresses the conflict between security and scalability in massive key storage. It proposes a hierarchical key encapsulation and storage architecture based on Key Derivation Functions (KDF): the root key is securely stored within the Hidden Key Storage (HSM). The HSM derives a one-time encryption key (KEK) based on the root key, the business key identifier, and a random salt value. This one-time encryption key is then used to authenticate and encrypt the business private key before being stored in an external database. This scheme employs a triple mechanism—"root key remains within the HSM," "one key, one key"—and "cryptographic binding of ciphertext and identifier"—to both preserve the high level of physical security of the HSM and overcome the physical limitations of its storage capacity, enabling secure hosting of millions of business keys.

[0057] Third, this invention addresses the flexibility and security issues of multi-entity authorization governance. It proposes an M-of-N multi-entity authorization mechanism based on stateless batch verification within the HSM (Hardware Management System), eliminating the need for external centralized approval systems or complex MPC threshold signature protocols. The core innovation lies in anchoring the threshold policy execution within the HSM hardware security boundary: the hardware signing device identities of each entity are registered and stored in an internal HSM whitelist. Each signature request requires independent signature confirmation from multiple authorized hardware signing devices under the M-of-N threshold policy. The KMS gateway collects the signatures and submits them to the HSM for batch verification and threshold judgment. Because the HSM employs a stateless design (each request is processed independently, eliminating the need to maintain session state), it reduces HSM firmware complexity while ensuring security. Furthermore, threshold parameters and authorized members are policy configuration items independent of business keys, supporting dynamic adjustment at runtime without key fragmentation and reassembly, effectively protecting the privacy of the enterprise's internal governance structure.

[0058] By comprehensively applying the above technical solutions, this invention constructs an end-to-end key management system with HSM and hardware signature devices as dual trust anchors and zero trust at the software layer as the design principle, providing a compliant, secure, and efficient key management infrastructure for highly sensitive scenarios such as enterprise-level cryptographic security signatures and protection of critical information infrastructure.

[0059] A key management and access control method based on a hardware security module (HSM) includes the following steps: 1. Securely storing a root key within the HSM; 2. Using the root key in combination with a business key identifier and a random salt value, deriving a business key encryption key through a key derivation function, and then encrypting and encapsulating the business private key using an authentication encryption algorithm before storing it in an external database of the HSM; 3. Registering the identity credentials of the hardware signing device to a device whitelist within the HSM to establish a binding relationship between the business key and the authorized hardware signing device, wherein the device whitelist and the business key are stored and managed independently within the HSM; 4. Creating an aggregation task for each business to be signed by a KMS gateway, wherein the aggregation task includes at least a request identifier (RequestID), a nonce, a business key identifier (KeyID), a policy version number, and an expiration time. The system operates within a window and collects independent signatures generated by at least M devices from N authorized hardware signing devices for a unified authorization payload. The unified authorization payload includes at least a business key identifier (KeyID), a request identifier (RequestID), a nonce, a policy version number, and a hash of the data to be signed. The KMS gateway sends the device signature, device identity credential, business key ciphertext record, and batch integrity check value to the HSM in one go. The HSM performs batch verification in a stateless manner, including at least verifying the validity of the policy version, device whitelist attribution, validity of the authorization payload signature, binding relationship of the business key ciphertext record, and unique counting rules of device identity credential under the same request identifier. After the number of valid signatures reaches the threshold M, the business private key is unsealed and digital signature operation is performed, and the request identifier and policy version number bound to the business signature are returned.

[0060] The encryption and encapsulation of the business private key is performed as follows: HSM derives the business key encryption key through HKDF based on the root key, random salt value and derived input including business key identifier KeyID, version context and algorithm identifier, and uses AES-256-GCM to authenticate and encrypt the business private key and output ciphertext, initialization vector IV and authentication tag. During decapsulation, authentication and decryption are performed based on the same derived input and AAD.

[0061] The KMS gateway integrates a semantic parsing engine to parse data to be signed that conforms to structured data standards, extract key business fields to generate human-readable signature digests, and perform real-time interception and auditing based on preset risk control rules.

[0062] Device whitelists and threshold parameters, as access control policies independent of business keys, are stored and managed independently within HSM partitions and support dynamic adjustment at runtime. New device registration requires administrator signature confirmation using the management key; HSM verifies the management key signature and adds the new device's identity to the whitelist. Device revocation takes effect immediately, and subsequent signature requests from revoked devices are rejected by HSM. M-of-N threshold parameters can be dynamically adjusted without changing the business key, and policy changes do not affect the key's lifecycle. For multi-signature requests that have been created but not yet completed, KMS freezes the policy version when creating the aggregation task, and HSM confirms whether the policy version is still in a state that allows completion during final verification.

[0063] A key management and access control system based on a hardware security module includes: a client hardware device layer for providing device identity credentials and device signatures for authorized hardware signing devices; a KMS gateway for receiving signature requests, creating aggregation tasks, and generating batch integrity verification values; a hardware security module for securely storing root keys, maintaining device whitelists, verifying batch integrity and policy versions, performing threshold judgments, decrypting business private keys, and performing digital signature operations; and a business key storage layer for storing encrypted records of business private keys.

[0064] The device whitelist management module of the HSM layer maintains the mapping relationship between KeyID and the list of authorized devices. The mapping relationship is stored in the internal secure storage area of ​​HSM and its integrity is protected by management key signature. In addition, HSM maintains a monotonically increasing version counter to prevent rollback attacks.

[0065] The KMS gateway and HSM layer adopt a separation of responsibilities design. KMS is responsible for signature collection, anti-replay check, time window control, policy version freezing and request aggregation, while HSM is responsible for device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption and final signature calculation. This separation of responsibilities ensures that system security does not depend on separate trust in the KMS software layer.

[0066] The batch integrity verification value at least covers the request identifier, KeyID, policy version number, device identity list, number of signatures, business key encrypted record digest, and request validity period, enabling HSM to identify whether the aggregated batch has been replaced, deleted, spliced, or reused across requests.

[0067] When HSM verifies signatures of various devices in batches, it counts the same device identity credential appearing repeatedly under the same request identifier only once, in order to prevent repeated submissions from the same authorized device from being mistakenly counted as multiple valid signatures.

[0068] The policy version is managed through a monotonically increasing version counter within HSM. Any whitelist or threshold policy with a version number lower than the current active version number shall not be reactivated to prevent the old policy from being rolled back and replayed.

[0069] The management key signature covers at least the following fields: KeyID, Device ID, permission scope, threshold parameters, policy version number, and effective time. The HSM verifies the signature before writing or updating the policy, and the policy can only take effect after the verification is successful.

[0070] After completing threshold verification and generating a business signature, HSM returns the request identifier and policy version number bound to the business signature, enabling KMS to uniquely match the final signature result with the corresponding aggregation task to prevent the signature result from being reused across requests.

[0071] 1. System Overall Architecture This invention proposes a layered and decoupled system architecture, consisting of four core components: a KMS gateway, a Hardware Security Module (HSM), a client hardware device layer, and a business key storage layer, as well as an independently deployed management backend, forming an end-to-end security system of "zero trust at the software layer and full protection at the hardware layer." Figure 1 As shown.

[0072] The system adopts a layered and decoupled architecture, consisting of four core components, with the data flow as follows: Client hardware device layer: Consists of authorized hardware signing devices (such as devices held by operations and maintenance personnel, risk control personnel, and audit / senior management), which interact with the upper layer through TLS / mTLS secure communication channels.

[0073] KMS Gateway: Includes API Gateway / Router (responsible for request authentication and rate limiting), Semantic Parsing Engine (parses structured data standards), Risk Control Rule Engine (executes quota / whitelist / blacklist checks), and Request Aggregator (collects M-of-N device signatures).

[0074] Hardware Security Module (HSM): As the security core, it provides root key storage, device authentication, M-of-N threshold verification (counting / signature verification), device whitelist management (registration / query), business key unwrapping, and cryptographic operation module (ECDSA / Ed25519) within the HSM security boundary.

[0075] Business key storage layer: A standard database or distributed storage system is used to store the ciphertext of the business key encrypted with the root key, serving only as a "ciphertext container".

[0076] Functional descriptions of each layer: (1) Client hardware device layer It consists of authorized physical hardware signing devices, such as FIDO2 security keys, USB keys, smart cards, or dedicated hardware signing terminals. Each device has a unique device identity credential (device certificate or key pair), generated during manufacturing or initialization, and cannot be exported. The device performs local user authentication via biometrics or PIN codes, ensuring a strong binding between "the device held by the person" and "the operations that the device can perform."

[0077] (2) KMS gateway As the unified entry point of the system, it undertakes the following core responsibilities: Request routing and authentication: Receive client requests and perform identity authentication and access control.

[0078] Semantic parsing engine: Parses data to be signed that conforms to structured data standards (such as JSON Schema, ASN.1, etc.), extracts data semantics (operation type, key parameters, target object, etc.), and generates human-readable signature digests.

[0079] Risk control rule engine: Real-time risk interception based on preset rules (single / daily cumulative limit, blacklist / whitelist, time window, etc.).

[0080] Request Aggregator: In multi-subject authorization scenarios, it collects and temporarily stores independent signatures from N different hardware devices. Once the M-of-N threshold is met, it sends the aggregation request to the HSM.

[0081] (3) Hardware Security Module (HSM) The system's core security feature provides a high-level protective environment with physical isolation. Root Key Storage: Securely stores the system root key, which does not leave the physical boundaries of the HSM.

[0082] Device authentication: Verify the identity credentials of the client hardware device and confirm that the device is on the authorized whitelist.

[0083] Device whitelist management: Maintains a list of registered authorized devices, and supports dynamic registration, revocation, and updates of devices.

[0084] M-of-N threshold verification: In multi-entity scenarios, the validity of each device's signature is independently verified and counted. Business key signing is only triggered when the number of valid signatures reaches the preset threshold M.

[0085] Business key unwrapping: Use the root key to decrypt the encrypted business key stored externally (Key Unwrapping) and recover the plaintext private key inside the HSM.

[0086] Cryptographic operations: Execute digital signature algorithms such as ECDSA and Ed25519. The private key plaintext is always inside the HSM. The temporary copy in memory is destroyed immediately after the signing is completed.

[0087] (4) Business key storage layer A standard database (such as PostgreSQL or MySQL) or a distributed storage system is used to store the ciphertext of the business key, which is encrypted with the root key. Because the private key is stored in ciphertext form, even if the database is compromised, it is difficult for attackers to obtain a usable private key. This layer only acts as a "ciphertext container," and all encryption and decryption operations are performed by the HSM.

[0088] (5) Management backend (independent deployment) Provide a graphical interface for administrators: Hardware device registration: Add the identity public key / certificate of the new hardware device to the HSM whitelist.

[0089] Policy configuration: Set M-of-N threshold parameters, risk control rules, and key usage policies.

[0090] Audit log query: View all signature requests, approval records, and system operation logs.

[0091] Key lifecycle management: key creation, archiving, rotation, and destruction.

[0092] Core architectural innovations: HSM's internal closed-loop device identity-authorization binding mechanism: This invention does not merely record "which device can use which key" at the software layer, but maintains the binding relationship between KeyID, authorized device list, threshold value, and policy version within the HSM security boundary; only when the device identity credentials, device signature, and policy version carried in the request all pass HSM verification will HSM allow the unsealing of the business private key and the execution of the signature operation, thereby moving access control from tamperable software logic to an unbypassable hardware execution boundary.

[0093] The dual responsibilities of KMS stateful aggregation and HSM stateless verification are decoupled: KMS is responsible for collecting multi-device signatures, maintaining RequestID / Nonce, controlling the time window, and generating batches to be verified; HSM performs independent device signature verification, threshold judgment, and key desealing for each batch of submissions, without maintaining cross-request session state. This design leaves the volatile process state at the software layer and anchors the unavoidable authorization judgment at the hardware layer, reducing the complexity of the HSM firmware state machine and the difficulty of auditing.

[0094] A governance model with orthogonal separation of policies and keys and version rollback prevention: Device whitelists, threshold parameters, policy version numbers, and business keys are stored independently within the HSM. Policy changes are confirmed by administrator hardware signatures and the version is monotonically incremented. Member changes, threshold adjustments, and device revocation do not require migration of business keys, and old version policies can be prevented from being rolled back and replayed.

[0095] A layered encapsulation support mechanism for massive key escrow: The root key is always kept within the HSM, while the business private key is authenticated and encrypted using a dedicated encapsulation key derived from KeyID, context, and random salt value before being stored externally. This mechanism itself serves as a supporting security foundation, working in conjunction with the aforementioned hardware authorization mechanism to form a decoupled architecture where "access control is enforced by the HSM, and capacity is expanded by external storage."

[0096] 2. Core Work Process 2.1 Key Creation Process Key creation is a fundamental step in system security operations, employing a layered strategy of "pre-setting the root key and deriving the business key." This process is decoupled from device registration, allowing for key creation before dynamic binding to authorized devices.

[0097] Step S101: Administrator Authentication Administrators log in through the management backend, and the system verifies the administrator's identity and permissions (whether they are key administrators).

[0098] Step S102: Create parameter configuration The administrator configures the key parameters, and the business system generates a KeyID as a permanent identifier for that key: KeyID: A globally unique identifier generated by the business system; Key algorithm types: ECDSA-secp256k1, Ed25519, SM2, etc.; Key usage: signing or encryption; Related business identifiers: user ID, business number, and other business information.

[0099] Step S103: HSM Internal Key Generation and Encapsulation The KMS gateway forwards the KeyID and creation parameters to the HSM, which then executes the following within the security boundary: Generate business key pairs (private keys) Public key ); The business private key is encrypted and encapsulated using the root key to generate a Wrapped Key; Immediately destroy the plaintext private key in memory.

[0100] Step S104: Ciphertext Storage The HSM returns the wrapped key and related metadata (KeyID, random salt value, public key, algorithm type) to the KMS gateway, which then stores it in an external database. The database only stores the encrypted ciphertext; the plaintext private key remains within the HSM's security boundaries.

[0101] Step S105: Return key identifier The administrator obtains the KeyID for subsequent signature requests. Device binding and registration are completed through a separate device registration process (see Section 2.3), which supports dynamically associating authorized devices after key creation.

[0102] 2.2M-of-N Multi-Subject Signature Authorization Process In multi-entity scenarios, the KMS gateway collects independent signatures from M different authorized devices and sends them to the HSM for batch verification and threshold judgment at once. Step S201: Initiate a multi-principal signature request When any authorized user initiates an operation request, the KMS gateway recognizes the M-of-N policy configured for the KeyID (such as 2-of-3, which requires signatures from two devices) and enters the multi-principal signature collection mode.

[0103] Step S202: KMS gateway initializes collection state The KMS gateway creates a temporary aggregation record for this request: Record the raw data to be signed. Initialize the collected signature counter (initially set to 0). Record the target threshold value M (e.g., 2). Set a valid time window (e.g., collection must be completed within 30 minutes). Step S203: Parallel Signature Collection by Multiple Devices Each authorized device holder completes the signing process in parallel or serially: Device A holder: Connects to the hardware device, performs local authentication, generates Device Signature A for the unified authorization payload, and sends it to the KMS gateway. After the KMS gateway completes the initial verification of the certificate chain and message format, it temporarily stores the signature record and increments the counter by 1 (currently 1).

[0104] Device B holder: Connecting to the hardware device, through local authentication, Device B generates Device Signature B for the same authorized payload and sends it to the KMS gateway. After the KMS gateway completes the initial verification of the certificate chain and message format, it temporarily stores the signature record and increments the counter by 1 (currently 2).

[0105] Step S204: KMS gateway threshold check The KMS gateway detects that the number of collected signatures (2) has reached the threshold M (2) and triggers the batch sending process.

[0106] Step S205: Send to HSM in one go The KMS gateway packages the following data and sends it to the HSM in one go: KeyID (Business Key Identifier); RequestID (aggregation task identifier); Nonce (anti-replay random number); PolicyVersion (policy version number); Raw data to be signed; Device signature list: [Device Signature A, Device Signature B], wherein each device signature covers a unified authorization payload, and the authorization payload includes at least KeyID, RequestID, Nonce, PolicyVersion, hash of the data to be signed, semantic digest identifier and request validity period; Device authentication credential list: [Device Cert A, Device Cert B]; Business key encrypted record (Wrapped Key, random salt value, IV, Tag, AlgorithmID and related metadata); Batch integrity verification values ​​(covering RequestID, KeyID, PolicyVersion, device list, number of signatures, business key encrypted record digest and validity period).

[0107] Step S206: HSM Batch Validation and Threshold Judgment HSM performs batch verification within the security boundary: Verify in turn whether the identity credentials of device A and device B are in the whitelist; Verify the validity of each Device Signature relative to the unified authorization payload using the corresponding device public key; Count the number of valid signatures (number of valid signatures = 2); If the number of valid signatures is greater than or equal to M (2 ≥ 2), the threshold is met; If any device verification fails or the number of valid signatures is less than M, HSM returns verification failure details and rejects the signature request.

[0108] Step S207: Perform business key signing Once the threshold is met, the HSM executes: Receive the Wrapped Key encrypted record queried and submitted by the KMS gateway by KeyID; Decrypt using the internal root key to recover the plaintext of the business private key (which exists only in HSM secure memory). Use the business private key to perform digital signature operations on the data to be signed; Immediately and securely erase the plaintext of the business private key from memory.

[0109] Step S208: Return Signature Result. The HSM returns the final digital signature to the KMS gateway, which then forwards it to the request initiator.

[0110] Step S209: Completion and Audit KMS gateway records complete audit logs: List of devices that participated in the signing (A, B) and their respective signing timestamps; Timestamps for bulk sending to HSM; HSM verification result and final business signature hash; Risk control verification results;

[0111] Clear temporary aggregate records.

[0112] 2.3 Hardware Device Registration Process The registration of new hardware devices requires a strict administrator review process. Step S301: New device initialization New hardware devices (such as new USB keys) generate a device key pair during initialization. The device private key is persistently stored in the device's security chip and cannot be exported; the device public key / certificate can be exported.

[0113] Step S302: Submit registration application The device owner submits a registration application to the administrator, providing: Device identity credentials (device certificate or public key), device holder identity information (name, department, role), and the KeyID to be associated (which business keys this device can sign).

[0114] Step S303: Administrator Approval Administrator login to the management backend, verification: Verification of the device holder's identity (offline confirmation or internal system verification); validity of the device's public key / certificate (certificate chain verification); reasonableness of the authorization scope (whether the user has permission to access the KeyID).

[0115] Step S304: HSM Internal Registration After the review is approved, the management backend will send the registration request to HSM, which will remain within the security boundary: Verify administrator identity (administrator hardware device signature verification); Write the device public key / certificate to the device whitelist storage area associated with this KeyID; Record the registration audit log (time, operator, device ID).

[0116] Step S305: Registration Completed HSM returns a successful registration status, and the new device can be used for signing requests for this KeyID.

[0117] 3. Key Technical Details 3.1 Cryptographic Principles of Key Encapsulation Mechanism This invention employs a hierarchical key encapsulation mechanism based on Key Derivation Functions (KDF). Its core design goal is to achieve secure storage and efficient access to massive amounts of keys while ensuring that the plaintext of the private key does not leave the security boundary.

[0118] (1) Key parameters This mechanism involves the following core parameters, the sources and functions of which are as follows: (Root Key): Generated by a hardware True Random Number Generator (TRNG) during HSM initialization, with a strength of no less than 256 bits, and securely stored inside the HSM without leaving the physical boundaries of the HSM.

[0119] KeyID (Business Key Identifier): A globally unique identifier (such as UUID or business ID, e.g., "biz_key_9527") generated by the business system to identify a specific business key and serve as the key input for deriving the KEK.

[0120] Context (Version Context): The fixed string "KeyWrapping-v1" is used to implement algorithm version isolation and prevent confusion between keys of different versions.

[0121] Salt (random salt value): A 128-bit random number generated by HSM, stored together with the Wrapped Key in an external database to increase the randomness of the derivation process and defend against pre-computed attacks.

[0122] IV (Initialization Vector): HSM is a 96-bit random vector generated for each encapsulation process, used in the AES-256-GCM encryption process, and stored together with the ciphertext.

[0123] (Business Private Key): The business private key generated internally by HSM (such as secp256k1 or Ed25519 private key) is the key actually used for digital signatures and only exists briefly in the secure memory of HSM.

[0124] AAD (Additional Authentication Data): Composed of KeyID and algorithm type (e.g., "biz_key_9527secp256k1"), it is used for AES-GCM authentication encryption to achieve a strong binding between the ciphertext and KeyID.

[0125] Tag (Authentication Tag): An integrity verification tag output by AES-256-GCM, used for authentication verification during the unsealing phase.

[0126] (2) Key encapsulation (encrypted storage) When a business key is created, the HSM performs the following encapsulation process within the security boundary: The business system first generates a KeyID and sends it to the HSM. The HSM internally generates a 128-bit random Salt and determines a fixed Context value. Subsequently, the HSM uses the TRNG to generate the business private key. and its corresponding public key .

[0127] Based on the above parameters, the HSM-derived dedicated key encryption key (KEK) is as follows: Where || represents byte string concatenation. This derivation process ensures that different KeyIDs correspond to different... This achieves a "one key, one password" isolation mechanism.

[0128] get Then, HSM uses the AES-256-GCM algorithm to encrypt and encapsulate the business private key: After encapsulation, HSM will store KeyID, ciphertext C, Salt, IV, Tag, and public key. The data is then returned to the business system. The business system stores this data in an external database, resulting in the following record structure: { "key_id": "biz_key_9527", "wrapped_key": "0x4f2a8e...", "salt": "0x7a3f9e..." "iv": "0xa13c5f...", "tag": "0x98de11..." "public_key": "0x04a3b2...", "algorithm": "secp256k1 } Finally, the HSM is immediately and securely erased from secure memory. This ensures that the plaintext private key does not leave the HSM boundary.

[0129] (3) Key decapsulation (for signature use) When the business private key is required for signing, the system securely restores the private key through the following process: The business system retrieves the corresponding ciphertext C, Salt, IV, and Tag from the database based on the KeyID, and sends them along with the data to be signed to the HSM. Upon receiving the request, the HSM uses the same parameters as during encapsulation (…). (KeyID, Context, Salt) re-derived : Because the parameters remain consistent with the encapsulation stage, the derived With packaging Same. HSM uses this key to decrypt ciphertext: It is important to note that the AAD should be consistent with the encapsulation; otherwise, GCM authentication will fail and the decryption operation will be rejected. This mechanism prevents attackers from obfuscating key usage by replacing ciphertext entries in the database (e.g., replacing user A's ciphertext with user B's).

[0130] After successful decryption, HSM uses the recovered... Perform a digital signature operation on the data to be signed. After signing, the HSM is immediately and securely erased from secure memory. Only the signature result is returned to the business system.

[0131] (4) Security Mechanism This layered key encapsulation mechanism can establish the following security constraints: Offline analysis resistance: Even if an attacker obtains the ciphertext C and Salt from an external database, due to the lack of... It is still impossible to rebuild the correct one. This makes it difficult to recover the business private key.

[0132] Ciphertext integrity and tamper resistance: The AES-256-GCM authentication encryption mechanism can trigger authentication failure and decryption operation rejection if the ciphertext or AAD is modified.

[0133] Anti-ciphertext replacement capability (AAD binding): AAD contains KeyID and algorithm type, which binds the ciphertext to the business context; ciphertext replacement across KeyIDs will fail due to AAD mismatch.

[0134] Key isolation (one key, one password): different combinations of KeyID and Salt derive different keys. This achieves cryptographic isolation between business keys.

[0135] Root key boundary protection: Remaining within the HSM, derivation and encryption / decryption operations are performed within the HSM boundary and are protected by a hardware protection mechanism at the physical layer.

[0136] 3.2 Security Model for Device Identity Binding The device identity binding mechanism is the core technology of this invention, extending key protection from "confidentiality" to "availability control," thus solving the problem of "key leakage equals loss of privileges" in traditional key management. Its security model is based on the following threat assumptions: Threat model assumptions: Attackers can control the KMS gateway host (including memory read, network interception, and process injection); attackers can obtain all key ciphertexts in the external database; attackers can obtain the device holder's PIN code through social engineering or malware; attackers cannot physically steal all authorized hardware signing devices (physical security assumption); the physical protection mechanism of the HSM hardware has not been breached (hardware security assumption).

[0137] Under the aforementioned threat model, this invention employs a three-factor authentication model of "known (password / password) + all (physical devices) + hardware binding (HSM whitelist)" to ensure that even if an attacker obtains the PIN code and key ciphertext, they cannot complete a valid signature without the physical device itself.

[0138] (1) The unforgeability of the device identification certificate Each hardware signing device generates a unique device key pair during manufacturing or initialization. Device private key Stored within the device's secure element, it has physical tamper protection and cannot be exported; Device public key Export as a certificate (Device Certificate) or raw public key and register it to the HSM whitelist.

[0139] Device signatures are based on Elliptic Curve Cryptography (ECC), whose security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public key... It is computationally infeasible to derive the private key. Therefore, it is computationally difficult for attackers to forge device signatures, even if they gain control of the user's client host.

[0140] (2) Anti-tampering storage of HSM internal policy whitelist The device whitelist is stored internally in the HSM as a protected, versioned key-value pair structure: Whitelist records = { KeyID → { Authorized device list: [DeviceID_1, DeviceID_2, ...] Threshold parameter M: Integer, Strategy version number: Version Registration timestamp Administrator signature Status (Enabled / Disabled) } } Key safety features of this structure: Storage location: Located in the HSM's internal secure storage area, not dependent on external databases; Integrity protection: Each whitelist record is protected by an administrator's hardware signature. The signature covers the KeyID, list of authorized devices, threshold parameters, policy version number, and effective time. The HSM will only accept the record after verifying the signature. Anti-rollback: HSM internally maintains a monotonically increasing version counter. Any policy write request with a version number lower than the current active version is rejected to prevent attacks that replace the old version whitelist. The effective boundaries are clearly defined: HSM only recognizes the latest policy version that is in the "published and not revoked" state, and is used to prevent draft policies, expired policies and revoked policies from being invoked incorrectly.

[0141] (3) Closed-loop control of equipment registration, revocation and policy change Device binding is not a one-time static write, but a complete closed loop including registration, release, freezing, revocation, and auditing: Registration phase: After a new device submits its device certificate or public key, the administrator uses the management device to sign "KeyID + DeviceID + Permission Scope + Policy Version". The HSM verifies the administrator's identity and signature before adding it to the candidate whitelist.

[0142] Release phase: The candidate whitelist will only take effect after it is explicitly released; when releasing, HSM will advance the internal version counter and record the effective timestamp and the operator's identity.

[0143] Revocation Phase: When a device is lost, the user leaves their post, or a leak is suspected, the administrator can initiate a revocation order; the HSM will mark the DeviceID as disabled and immediately reject any subsequent signature requests, without needing to replace the business key.

[0144] Audit phase: Each registration, revocation, and threshold adjustment records the policy version, administrator identity, affected device set, and effective time for future traceability.

[0145] (4) Dynamic management capability of device binding Compared to the "deployment-as-it-is" approach of traditional centralized multi-signature or MPC threshold signature, the device binding of this invention supports dynamic adjustment at runtime: Device registration: New devices require hardware signature confirmation from the administrator. The HSM verifies the administrator's device identity before adding the device to the whitelist.

[0146] Device revocation: Administrators can immediately mark lost / leaked devices as "disabled". Subsequent signature requests for such devices will be directly rejected by HSM without the need to change the business key.

[0147] Threshold adjustment: Supports dynamic modification of the M-of-N parameter (e.g., from 2-of-3 to 3-of-5) without regenerating the business key.

[0148] This flexibility stems from the core design principle of this invention—the orthogonal separation of policy and key: the business key is always securely stored by the HSM, while the device whitelist and threshold parameters are independent access control policies, stored and managed independently within the HSM in partitioned areas. For multi-signature requests that have been created but not yet completed, the KMS freezes the corresponding policy version number when creating the aggregation task and submits it for verification when submitting to the HSM; the HSM verifies whether the version is still valid, thus ensuring that policy changes do not silently pollute requests in transit. This design ensures that policy changes (such as personnel changes or threshold adjustments) do not affect the key lifecycle, and key rotation does not affect existing authorization policies, achieving independent evolution of key security and governance flexibility.

[0149] (5) Security demonstration of HSM internal storage This invention chooses to anchor the device whitelist, threshold parameters, and policy versions entirely within the HSM hardware security boundary, rather than simply having the HSM perform the password computation function while storing the permission data in an external database, based on the following security considerations: Physical-level tamper resistance: HSM possesses physical protection mechanisms (anti-tampering, anti-side-channeling, and anomaly removal) to ensure that even if an attacker gains database administrator privileges, they cannot directly modify the device's license status. If the license data is stored in an external database, attackers can directly add new licensed devices or lower the signature threshold through SQL injection or privilege escalation attacks.

[0150] Minimum trust boundary under the zero-trust assumption: When the KMS software layer is compromised (including database control), attackers still cannot add new authorized devices or lower the signature threshold on their own. This is because HSM does not accept whitelist change requests initiated by external software; all policy changes must be confirmed by the administrator's hardware signature and the signature validity verified by HSM before they take effect.

[0151] Auditability and non-repudiation of policy changes: All policy changes must be signed by the administrator using a hardware device. The signature covers key fields such as KeyID, DeviceID (device identity credential), permission scope, threshold parameters, policy version number, and effective time. Change records are stored in HSM secure storage, making them traceable afterward and difficult to tamper with by the software side, providing a reliable foundation for security auditing and accountability.

[0152] 3.3M-of-N Threshold Validation Mechanism The core design principle of the M-of-N threshold authentication mechanism is separation of responsibilities and minimization of security boundaries: KMS handles signature collection, initial verification, and replay protection (stateful operations), while HSM focuses on batch signature verification and final authorization judgment in a stateless manner (purely cryptographic operations). This design keeps the HSM firmware complexity to a minimum, reducing the difficulty of firmware security auditing.

[0153] 3.3.1 Signature Collection and Preprocessing at the KMS Layer The KMS gateway maintains a multi-signature request aggregator. Its workflow is as follows: After multiple users, such as user A, user B, and user C, generate signatures respectively, the KMS aggregator collects these signatures (with expiration time control) and sends the signature list and original data in batches to the HSM for verification.

[0154] Key features of the KMS aggregator: Deduplication of requests: Identify different signatures of the same transaction by using the RequestID to prevent duplicate counting.

[0155] Initial device identity verification: Verify the validity of the device certificate chain and whether the device is in an enabled state.

[0156] Replay protection check: Maintain a short-term nonce cache (such as an LRU cache, which retains the nonce from the most recent hour) and reject duplicate nonces.

[0157] Time window control: Set the validity period of the request (e.g., 30 minutes), and automatically clean up the aggregated records after the expiration.

[0158] Strategy version freeze: When creating an aggregation task, the currently effective strategy version number is bound, and the subsequent collection process revolves around the same version, avoiding the threshold parameters being switched imperceptibly during the collection process.

[0159] Batch integrity encapsulation: Before sending the batch to the HSM, the KMS generates an integrity verification value for the RequestID, KeyID, policy version, device list, number of signatures, business key ciphertext record digest, and expiration time. Before each hardware device generates a signature, it also confirms and signs the authorization payload containing KeyID, RequestID, Nonce, PolicyVersion, hash of the data to be signed, semantic digest identifier, and validity period, so that the HSM can verify the consistency between the aggregated batch and the device's authorization intent.

[0160] 3.3.2 Batch Verification of HSM Layer After KMS collects M signatures, it sends the following data to HSM in one go: KeyID, Policy Version, RequestID and Nonce, Raw Data to be Signed or its normalized hash, Authorization Payload, Device Signature List: [Sig_1, Sig_2, …, Sig_M], Corresponding Device Public Key / Certificate List: [PK_1, PK_2, …, PK_M], Business Key Ciphertext Record (Wrapped Key, Salt, IV, Tag, AlgorithmID), and Aggregate Batch Integrity Check Value.

[0161] HSM performs stateless batch verification, and the specific process is as follows: (1) Batch integrity check: Verify whether the RequestID, Nonce, policy version number, business key encrypted record digest and integrity check value are consistent. If they are inconsistent, reject directly. (2) Obtain policy parameters: Query the current valid device whitelist and threshold value M corresponding to the KeyID, and verify whether the submitted policy version is still in an acceptable state; (3) Signature count check: If the number of received signatures is less than the threshold value M, return an insufficient signature error directly; (4) Batch signature verification: Iterate through the signatures of each device and execute the following steps in sequence: Device whitelist verification: Verify whether the device's public key is in the whitelist. If not, return a device unauthorized error. Signature validity verification: Use the device's public key to verify the validity of the signature on the authorized payload. If the verification fails, return an invalid signature error. Uniqueness check: Verify that the same DeviceID is counted only once under the same RequestID, and duplicate submissions are not counted repeatedly; Valid signature count: Verified signatures are counted in the valid signature count; (5) Threshold judgment and business signature: If the number of valid signatures reaches the threshold value M, the business private key is unsealed, the original data is digitally signed using the business private key, and the plaintext of the business private key in memory is immediately and securely erased after completion, and the final signature result is returned; if the threshold is not reached, the threshold failure error is returned. (6) Result binding return: When HSM returns the result, it includes RequestID, policy version and verification conclusion, so that KMS can match the final signature with the original aggregation task one by one and avoid the cross-request reuse of results.

[0162] Design advantages: HSM is stateless: HSM does not require the maintenance of a complex counter state machine. Each request is processed independently, reducing the complexity of HSM firmware. Replay protection is offloaded: KMS handles replay attack protection, while HSM focuses on cryptographic operations, which aligns with the design principle of "specialized security components". Batch efficiency: HSM completes all verification and signing in a single command, reducing the number of HSM communication round trips; Clear boundaries for requests in transit: By freezing the policy version and reviewing it in HSM, ambiguity caused by member changes or threshold adjustments to ongoing multisignature tasks can be avoided.

[0163] 3.3.3 Safety Boundary Analysis The responsibilities of each safety function are as follows: Signature collection and aggregation: This is handled by KMS and relies on software security and memory isolation mechanisms to achieve temporary storage and aggregation of signatures from multiple devices.

[0164] Replay protection / time window: This is handled by KMS, which relies on software security to implement nonce verification and request expiration control.

[0165] Device whitelist lookup: Handled by HSM, relying on physical security to reduce the risk of whitelist data being tampered with by the software side.

[0166] Signature verification: This is handled by the HSM and relies on physical security to perform cryptographic verification of device signatures.

[0167] Threshold judgment: This is handled by HSM, which relies on physical security to execute the M-of-N counting and judgment logic.

[0168] Business private key decryption: This is handled by HSM, which relies on physical security to perform KEK derivation and ciphertext decryption.

[0169] Final signature operation: This is handled by the HSM, which performs the signature operation of the business private key in a physically secure manner.

[0170] This division of labor separates policy enforcement (KMS gateway) from key protection (HSM), forming a two-layer security boundary: even if the KMS gateway is compromised, attackers cannot forge HSM verification results due to the lack of the HSM's internal root key; even if the threshold is known to have been met, the final signature cannot be obtained without the cooperation of the HSM. This architecture ensures that security does not depend on trust in the KMS gateway, embodying the core concept of "zero trust at the software layer" of this invention.

[0171] 4. Alternative solutions In addition to the preferred embodiments described above, the technical solution of the present invention can also be implemented through the following alternative methods: (1) Alternative architecture for threshold verification The aforementioned KMS collection + M-of-N batch verification model can be replaced by the following alternative: Centralized approval system verification: The device signature is uploaded to the centralized approval service, and the server performs threshold judgment. It is suitable for scenarios that require unified audit logs (but there is a risk of single point of failure).

[0172] MPC (Multi-Party Computation) Threshold Signature: It adopts protocols such as Shamir Secret Sharing or GG20. The business private key is stored in multiple HSMs in fragments. The signature shares of each HSM are aggregated. It is suitable for scenarios with extremely high security requirements (but increases complexity).

[0173] (2) Alternatives to key storage The aforementioned layered key encapsulation mechanism can be replaced by the following alternatives: HSM cluster sharded storage: Stores business private keys in shards across multiple HSMs, requiring multiple HSMs to work together for decryption. Suitable for scenarios without a single point of trust.

[0174] Homomorphic encryption operation: Using HSM that supports homomorphic encryption, the signature operation is performed directly on the ciphertext without decrypting the private key (but the performance is currently limited).

[0175] (3) Alternative implementation of semantic parsing The aforementioned KMS gateway resolution can be replaced by the following alternatives: Local parsing on hardware devices: The hardware device directly parses the complete data structure and displays it on the screen. KMS only forwards the raw data, which is suitable for extreme "zero trust" scenarios (but requires high device performance).

[0176] Trusted Execution Environment (TEE) resolution: Semantic resolution is performed in a TEE (such as Intel SGX), so that even if the KMS host is compromised, the resolution logic and cached data are still protected.

[0177] Figure 1The diagram illustrates the layered system architecture of this invention, including a client hardware device layer, a KMS gateway, a hardware security module (HSM), and a business key storage layer. The diagram clearly shows the data flow and trust boundaries between the components, reflecting the design concept of "end-to-end hardware security"—the user-side hardware device and the server-side HSM form a trust anchor, with the intermediate software layer serving only as a data transmission channel.

[0178] Figure 2 This demonstrates the complete process of business key generation and encrypted storage. The business system first generates a KeyID (a unique identifier for the business key) and sends it to the HSM (Hardware Smart Controller). Within the security boundary, the HSM sequentially generates a random Salt and a business key pair, derives a key based on the KeyID, a fixed Context, and an algorithm identifier, encrypts the key (KEK), and uses the AES-256-GCM algorithm to encrypt the business private key. Finally, the plaintext private key in memory is immediately destroyed. The HSM returns the KeyID, ciphertext C, Salt, IV, Tag, and public key to the business system, which then stores this data in an external database. This process embodies the core mechanism of "the root key never leaves the HSM, while the encrypted business key is stored externally," resolving the contradiction between security and scalability in massive key storage.

[0179] Figure 3 This diagram illustrates the signature authorization sequence in a multi-entity scenario: multiple authorized users generate device signatures using their respective hardware signature devices. The KMS gateway collects and temporarily stores these signatures, then sends them in batches to the HSM once a preset threshold M is reached. The HSM performs device whitelist verification, signature validity verification, threshold judgment, and finally, business key signing. This diagram demonstrates the separation of responsibilities design of "KMS collection and aggregation, HSM batch verification," as well as the efficiency of multi-entity threshold control.

[0180] Figure 4 It demonstrates the complete lifecycle of a hardware device, from initialization and registration to authentication. This includes: (1) Device initialization generates device key pairs; (2) The administrator reviews and registers the device's public key to the HSM whitelist; (3) The process of HSM verifying device identity and signing during a signature request. This diagram illustrates the “device-key strong binding” mechanism, ensuring that only authorized physical devices can use the corresponding business key.

[0181] In specific embodiments of the present invention, the technical solution of the present invention will be described in detail below with reference to specific examples.

[0182] Example 1: Key Management of an Enterprise-Level Cryptographic Security Signature Platform An enterprise-level cryptographic security signature platform uses this invention to manage its core business private keys, and its deployment architecture is as follows: Environment configuration: HSM: HSM devices that meet the Level 2 security requirements of GM / T 0028 and have passed the commercial cryptography product certification of the State Cryptography Administration.

[0183] KMS Gateway: Deployed in an independent security subnet, running a semantic parsing engine and a risk control rule engine.

[0184] Client equipment: The operator is equipped with a domestically produced hardware signature device (certified by the State Cryptography Administration).

[0185] Database: A domestically developed relational database stores the encrypted business key ciphertext.

[0186] Key creation process: The administrator initiates a creation request through the management backend. The HSM internally generates an SM2 key pair, encrypts the key using an HKDF-SM3 derived key, and encrypts the private key using the SM4-GCM algorithm. The AAD contains the KeyID and algorithm identifier. The generated ciphertext is stored in the database, and the original private key is destroyed internally within the HSM.

[0187] Standard signature process (single device): The operator initiates a signature request. The KMS gateway parses the structured data to extract the operation type and key parameters. After the risk control engine verifies the data, it forwards the request to the HSM. After verifying the device signature and whitelist, the HSM decrypts the business private key and performs SM2 signing. Immediately after signing, the private key in memory is erased.

[0188] High-Sensitive Operation Multi-Signature Process (2-of-3 Threshold): For highly sensitive operations exceeding the specified security level, configuration requires signatures from two authorized devices. Authorized personnel A uses their hardware device to sign; KMS temporarily stores the signature and notifies authorized personnel B. After B uses their hardware device to sign, KMS collects both signatures and sends them to HSM at once. HSM performs batch verification that both device signatures are valid and both are in the whitelist; once the threshold is met, business key signing is performed.

[0189] Key pseudocode (HSM internal signature process) # Simplified version of HSM internal business key signing function def sign_transaction(request_id, nonce, key_id, policy_version, tx_data, device_sigs, device_pks, wrapped_key_record): """ request_id: Unique identifier for the aggregated request nonce: a random number to prevent replay. key_id: Business key identifier policy_version: The version of the policy for freezing aggregated tasks. tx_data: Data to be signed device_sigs: List of device signatures [sig1, sig2, ...] device_pks: A list of device public keys [pk1, pk2, ...] wrapped_key_record: The encrypted record submitted by KMS after retrieving it from an external database by KeyID. """ # 1. Verify request metadata and policy version if not verify_request_binding(request_id, nonce, key_id, policy_version, tx_data): return Error("Request binding verification failed") auth_payload = canonical_encode({ "request_id": request_id, "nonce": nonce, "key_id": key_id, "policy_version": policy_version, "tx_hash": sha256(tx_data), "wrapped_key_hash": sha256(wrapped_key_record), }) threshold = hsm_get_threshold(key_id, policy_version) whitelist = hsm_get_whitelist(key_id, policy_version) # 2. Check the number of signatures if len(device_sigs) < threshold: return Error("Insufficient signature count") # 3. Batch verify and deduplicate the signature of each device. valid_count = 0 counted_devices = set() for sig, pk in zip(device_sigs, device_pks): # Verify if the device is on the whitelist If pk is not in the whitelist: return Error(f"Device not authorized: {pk}") if pk is in counted_devices: continue # Verify device signature if not ecdsa_verify(pk, sig, sha256(auth_payload)): return Error(f"Invalid device signature: {pk}") counted_devices.add(pk) valid_count += 1 # 4. Threshold Decision if valid_count < threshold: return Error("Valid signature threshold not reached") # 5. Unblock the business private key (only in HSM secure memory) kek = hsm_derive_key(key_id, wrapped_key_record.salt, wrapped_key_record.algorithm) private_key = aes_gcm_decrypt(kek, wrapped_key_record) # Decrypt # 6. Perform final signing signature = ecdsa_sign(private_key, sha256(tx_data)) # 7. Securely erase private key secure_zero_memory(private_key) return { "request_id": request_id, "policy_version": policy_version, "signature" means signature. } The core technical concept of this invention is as follows: In scenarios where the software layer may be compromised, external databases may be tampered with, business private keys need to be managed in large quantities, and multi-subject authorization needs to be adjusted at runtime, the final determination of key usage permissions is anchored within the HSM security boundary. Through the binding relationship between hardware signature devices, KMS aggregation tasks, policy versions, and business key ciphertext records, a dual-trust anchor access control model of "client hardware device + server HSM" is formed.

[0190] The core technical features of the present invention are as follows: 1. Business private keys are processed within a closed loop within the HSM throughout the entire process. The business private key remains within the HSM security boundary during creation, encapsulation, decapsulation, signing, and erasure. The external database only stores encrypted records such as Wrapped Key, Salt, IV, Tag, and AlgorithmID. Neither KMS nor the application obtains the plaintext of the business private key.

[0191] 2. Closed-loop device identity-permission binding within HSM. HSM internally maintains the binding relationship between KeyID, authorized device list, threshold parameters, policy version number, and device status, and performs unified verification before final business signature.

[0192] 3. Separation of responsibilities between KMS stateful aggregation and HSM stateless batch verification. KMS is responsible for RequestID, Nonce, validity period, policy version freezing, device signature collection, and batch integrity encapsulation; HSM does not maintain cross-request session state, but performs whitelist verification, signature verification, DeviceID unique counting, threshold judgment, business private key decryption, and final signing on aggregated batches submitted in a single transaction.

[0193] 4. Policies and keys are orthogonally separated and versioned to prevent rollback. Device whitelists, threshold parameters, and policy versions are stored as access control policies independent of business keys within the HSM. Policy changes require administrator hardware signature confirmation, and the rollback of old policies is prevented through a monotonically increasing version counter within the HSM.

[0194] 5. Binding mechanism between batch aggregation and signature results. Hardware device signatures cover KeyID, RequestID, Nonce, PolicyVersion, hash of data to be signed, semantic digest identifier, and validity period; batch integrity verification values ​​submitted by KMS cover RequestID, KeyID, policy version, device list, number of signatures, business key ciphertext record digest, and validity period; the business signature finally returned by HSM is bound to both RequestID and policy version number.

[0195] The technical problem actually solved by the technical solution of the present invention can be described as follows: In scenarios where the KMS software layer may be compromised, the external key ciphertext may be read or tampered with, and the business keys need to be managed in large quantities and the authorized members need to change dynamically, how to forcibly anchor the usage rights of the business private key to the hardware trust boundary jointly formed by the HSM and the authorized hardware signature device.

[0196] The HSM internal policy record includes KeyID, a list of authorized DeviceIDs, threshold value M, policy version number, device status, management key signature, effective time, and revocation identifier. It also states that the policy record is stored in the HSM internal secure storage area, and its effective status cannot be modified by an external database or KMS.

[0197] The authorized payload for hardware device signatures must include at least KeyID, RequestID, Nonce, PolicyVersion, hash of the data to be signed, semantic digest identifier, and request validity period; the batch integrity check value submitted by KMS to HSM must at least cover the device identity list, number of signatures, business key ciphertext record digest, and validity period.

[0198] Existing KMS solutions typically focus on storing the root key in the HSM and storing the business key encrypted externally. Their core focus is on key confidentiality and capacity expansion. However, access control logic such as device identity, approval thresholds, and member adjustments is usually still maintained by the software layer or an external approval system. This invention further anchors device identity, threshold parameters, policy versions, and their effective status within the HSM for unified determination. This solves not only the problem of "key leakage" but also the availability control problem of "even if the software layer is compromised, attackers cannot trigger unauthorized key usage."

[0199] Existing device whitelisting solutions often only record the accessible range of devices in the gateway or business services, and device revocation, member changes, or permission adjustments rely on external database updates. This invention requires that the device whitelist and policy version number be maintained internally in the HSM, and that old policies be rolled back through administrator hardware signatures and a monotonically increasing version counter. Therefore, it protects not only the authenticity of device identities, but also the integrity and temporal validity of the authorization policies themselves.

[0200] Traditional centralized approval schemes rely on external approval services to store approval status, which poses a single point of failure and the risk of state tampering. While conventional M-of-N schemes can express threshold relationships, they typically do not define the consistency boundary between aggregation tasks and final verification. This invention binds the stateful aggregation results of KMS and the stateless verification process of HSM into a single, indivisible authorization transaction by using RequestID, Nonce, policy version freezing, and batch integrity check values. This prevents duplicate counting, cross-batch splicing, and policy switching contamination of in-transit requests.

[0201] The focus of MPC schemes is to eliminate a single key holder, but their implementation relies on complex multi-round interaction protocols, fragmentation and reassembly processes, and member replacement procedures. This invention does not aim to replace HSMs through cryptographic fragmentation, but rather achieves a multi-principal authorization mechanism that is easier to deploy, audit, and adjust at runtime through "internal HSM permission determination + independent authorization across multiple devices + policy version governance." Its innovation lies in the permission execution model within the hardware boundary, rather than the distributed signature mathematical protocol itself.

[0202] Compared with the prior art, the technical solution of the present invention has the following technical effects: (1) Reduce the risk of opaque signatures on the operator's side and improve signature transparency. By implementing structured data semantic parsing in the KMS gateway, machine-hard-to-read hexadecimal data is converted into business information that operators can understand (such as operation type, key parameters, target objects, etc.). Combined with the whitelist binding mechanism of hardware devices, even if the front end is subjected to supply chain attacks, attackers will find it difficult to complete signatures on unauthorized devices. This technology can reduce the risk of opaque signatures caused by front-end tampering attacks and support the security goal of "what you see is what you sign".

[0203] (2) Block unauthorized calls from the software side by determining the internal permissions of the HSM. Because KeyID, authorized device list, threshold parameters, and policy version are uniformly verified within HSM, even if KMS is compromised, it can only forward requests and cannot unilaterally expand device permissions, forge authorization results that pass the threshold, or bypass device revocation status. Compared to solutions that only maintain device permissions in the software database, this invention anchors critical access control logic within the hardware security boundary, thus shrinking the effective attack surface after the software side is compromised.

[0204] (3) Overcome the "security-capacity" contradiction in key storage and support large-scale deployment. The hierarchical key encapsulation and storage architecture supports secure escrow of large-scale business keys, increasing capacity compared to fully hardware-hosted solutions. Simultaneously, the plaintext private key remains within the HSM security boundary during usage, balancing security and scalability.

[0205] (4) Achieve efficient multi-entity governance and reduce operating costs Compared to traditional centralized multi-signature schemes and MPC threshold signatures, the M-of-N threshold mechanism of this invention: No external dependencies: No need to deploy additional centralized approval services, reducing system complexity and operating costs; Improved response efficiency: Reduce round-trip interaction overhead through batch verification; Privacy exposure is reduced: the approval structure does not need to be decentralized to an external independent approval system; Enhanced flexibility: Supports dynamic adjustment of thresholds and members without the need to redeploy the approval system or reassemble key fragments; Enhanced consistency: By using RequestID, Nonce, and policy version freezing mechanisms, we can prevent requests in transit from being counted repeatedly, spliced ​​across batches, or causing ambiguity due to policy switching.

[0206] (5) Construct a dual-anchor hardware trust chain to achieve a "zero-trust software" architecture. The user-side hardware signature device and the server-side HSM form a symmetrical dual-trust anchor point. Cryptographic operations are performed independently within the hardware at both ends. The intermediate KMS gateway is downgraded to an untrusted data channel and does not hold independently usable key materials. Even if the KMS host is compromised, the attacker: Unable to decrypt the business private key (cannot be decrypted without HSM); Device signature cannot be forged (without device private key); It is impossible to bypass the threshold verification (enforced internally by the HSM).

[0207] This architecture embodies the design philosophy of "assuming the software layer is untrusted, the system can still maintain key security constraints," and can serve as an implementation path for zero-trust deployment in highly sensitive scenarios.

[0208] (6) The policy and key are orthogonally separated, supporting dynamic policy adjustment. Device whitelists and M-of-N policies are independent configuration items, orthogonally separated from service keys, and are stored in partitions within the HSM, supporting dynamic updates at runtime. The device can be revoked immediately if it is lost, without the need to replace the business key; Thresholds can be dynamically adjusted when personnel change, without the need for key fragmentation and reassembly; Policy changes take effect immediately without requiring system downtime; The old version strategy cannot be reactivated through version rollback; Requests in transit can be completed according to the frozen policy version or explicitly rejected, with clear governance boundaries.

[0209] Compared to the traditional centralized multi-signature system's "downtime for changes" and MPC's "complex reorganization process," this method can improve operational efficiency while meeting security constraints.

[0210] For the specific implementation scheme of this embodiment, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0211] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0212] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0213] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0214] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution device. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0215] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The corresponding program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiments.

[0216] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0217] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0218] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0219] This invention employs a method, system, apparatus, processor, and computer-readable storage medium for key management and access control based on a hardware security module. By semantically parsing structured data to be signed at the gateway layer and maintaining device whitelists, threshold policies, and policy versions within the hardware security module, business key usage permissions are bound to authorized hardware signing devices and aggregation requests. Simultaneously, a root key-derived encapsulated key is used to authenticate and encrypt the business private key before external storage. The gateway is responsible for signature collection, policy freezing, and batch integrity encapsulation. The hardware security module performs stateless batch verification, deduplication counting, key decapsulation, and final signing. This allows operators to understand and audit signature content, reducing the risk of front-end tampering and opaque signatures. It blocks attack paths such as unauthorized modification of permissions, rollback of old policies, replacement of ciphertext, or batch concatenation triggering signatures at the software layer. Furthermore, it supports member revocation and policy adjustment without relying on external centralized approval or key fragmentation and reassembly, balancing key escalability, access control reliability, firmware auditing convenience, and operational stability in highly sensitive business scenarios.

[0220] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. A method for implementing key management and access control based on a hardware security module, characterized in that, The method includes the following steps: (1) The root key is securely stored inside the hardware security module HSM; (2) Using the root key combined with the business key identifier and random salt value, the business key encryption key is derived through the key derivation function, and the business private key is encrypted and encapsulated using the authentication encryption algorithm and then stored in the HSM external database. (3) Register the identity credentials of the authorized hardware signing device to the device whitelist inside the HSM to establish a binding relationship between the business key and the authorized hardware signing device, wherein the device whitelist and the business key are stored and managed independently inside the HSM; (4) For each service to be signed, the KMS gateway creates an aggregation task to generate a unified authorization payload that includes at least the service key identifier, request identifier, random number, policy version number, request validity period and hash of the data to be signed, and sends the unified authorization payload to N authorized hardware signature devices to collect the independent signatures generated by at least M devices among the N authorized hardware signature devices for the unified authorization payload; (5) The KMS gateway generates a batch integrity verification value and sends the device signature, device identity certificate, business key ciphertext record and batch integrity verification value to the HSM at once; (6) HSM performs batch verification in a stateless manner, including at least the verification of policy version validity, device whitelist attribution, authorization payload signature validity, business key ciphertext record binding relationship and device identity credential unique counting rule under the same request identifier. After the number of valid signatures reaches the threshold M, the business private key is unsealed and digital signature operation is performed, and the request identifier and policy version number bound to the business signature are returned.

2. The method for key management and access control based on a hardware security module according to claim 1, characterized in that, The encryption and encapsulation of the business private key in step (2) includes the following steps: HSM is based on the root key, random salt value, and derived inputs including business key identifier, version context, and algorithm identifier. It derives the business key encryption key through HKDF, uses AES-256-GCM to authenticate and encrypt the business private key, and outputs ciphertext, initialization vector, and authentication tag. During decryption, it is based on the same derived input and additional authentication data AAD for authentication and decryption.

3. The method for implementing key management and access control based on a hardware security module according to claim 2, characterized in that, The Additional Authentication Data (AAD) is composed of a business key identifier and an algorithm identifier. The business key ciphertext record includes at least the ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier, and is stored in an external database of HSM. If the AAD is inconsistent with the one used in the encapsulation stage during decapsulation, authentication fails and decryption is refused.

4. The method for implementing key management and access control based on a hardware security module according to claim 1, characterized in that, The method further includes the following steps: The KMS gateway integrates a semantic parsing engine to parse the data to be signed that conforms to the structured data standard, extracts key business fields to generate a signature digest, and performs real-time interception and auditing based on preset risk control rules. The unified authorization payload also includes a semantic digest identifier and a request validity period corresponding to the signature digest.

5. The method for implementing key management and access control based on a hardware security module according to claim 1, characterized in that, The device whitelist and threshold parameters are access control policies independent of the business key, stored and managed independently in partitions within the HSM, and support dynamic adjustment at runtime. New device registration requires confirmation through management key signature, and the HSM writes the new device identity into the whitelist after verifying the management key signature. Device revocation takes effect immediately, and subsequent signature requests from revoked devices are rejected by the HSM.

6. The method for implementing key management and access control based on a hardware security module according to claim 5, characterized in that, The method further includes the following steps: For multi-signature requests that have been created but not yet completed, the KMS gateway freezes the policy version when creating the aggregation task, and the HSM confirms whether the policy version is still in the state of being allowed to complete during the final verification. The policy version is managed by a monotonically increasing version counter inside the HSM, and any whitelist or threshold policy with a version number less than the current active version number shall not be reactivated.

7. The method for implementing key management and access control based on a hardware security module according to claim 5, characterized in that, The HSM internal maintenance policy record includes at least a business key identifier, a list of authorized device identity credentials, a threshold value M, a policy version number, a device status, a management key signature, an effective time, and a revocation identifier. This record is stored in the HSM's internal secure storage area, and its effective status cannot be modified independently by an external database or KMS. The management key signature covers at least the following fields: business key identifier, device identity credentials, permission scope, threshold parameters, policy version number, and effective time. The HSM verifies the management key signature before writing or updating the policy; the policy only becomes effective after successful verification.

8. The method for implementing key management and access control based on a hardware security module according to claim 1, characterized in that, The batch integrity verification value shall at least cover the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period; When HSM verifies signatures of various devices in batches, it counts the same device identity credential appearing repeatedly under the same request identifier only once.

9. The method for implementing key management and access control based on a hardware security module according to claim 1, characterized in that, The KMS gateway performs signature collection, replay protection check, time window control, policy version freezing, and request aggregation, while the HSM performs device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption, and final signature calculation. After completing threshold verification and generating a business signature, HSM returns the request identifier and policy version number bound to the business signature, enabling KMS to uniquely match the final signature result with the corresponding aggregation task.

10. A system for implementing key management and access control based on a hardware security module, characterized in that, The system includes: The client hardware device layer includes multiple authorized hardware signing devices. Each authorized hardware signing device has a built-in security chip, in which a device private key is stored in a non-derivative manner. This key is used to provide device identity credentials and generate a device signature for a unified authorized payload. Each authorized hardware signing device is connected to the KMS gateway through a secure communication channel. The business key storage layer is used to store encrypted and encapsulated records of business private keys. The hardware security module, connected to the business key storage layer, includes a root key storage module, a device whitelist management module, a threshold verification module, a business key desealing module, and a cryptographic operation module. The root key storage module stores the root key within the HSM physical boundary. The device whitelist management module maintains the device whitelist and policy version in the secure storage area inside the HSM. The threshold verification module verifies batch integrity, policy version, and device signature and performs threshold judgment. The business key desealing module derives the business key encryption key and deseales the business private key. The cryptographic operation module performs digital signature operations on the data to be signed. The KMS gateway, connected to the client hardware device layer and hardware security module, includes a request aggregator, a semantic parsing engine, and a risk control rule engine. The request aggregator is used to receive signature requests, create aggregation tasks, collect device signatures from at least M devices among N authorized hardware signature devices, and generate batch integrity verification values. The semantic parsing engine is used to parse the data to be signed to generate signature digests. The risk control rule engine is used to perform risk interception.

11. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, The device whitelist management module maintains a mapping relationship between business key identifiers and authorized device lists. This mapping relationship is stored in the HSM's internal secure storage area and its integrity is protected by management key signatures. Furthermore, the HSM maintains a monotonically increasing version counter to prevent rollback attacks.

12. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, The KMS gateway and the hardware security module adopt a separation of responsibilities design. The KMS gateway is responsible for signature collection, anti-replay check, time window control, policy version freezing, and request aggregation, while the hardware security module is responsible for device whitelist query, request batch integrity verification, signature verification, threshold judgment, business private key decryption, and final signature calculation.

13. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, The batch integrity verification value covers at least the request identifier, business key identifier, policy version number, device identity credential list, number of signatures, digest obtained by hashing the business key ciphertext record, and request validity period, so that the hardware security module can identify whether the aggregated batch has been replaced, deleted, spliced, or reused across requests.

14. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, When the threshold verification module performs batch verification of signatures for each device, it counts the same device identity credential appearing repeatedly under the same request identifier only once.

15. The system for key management and access control based on a hardware security module according to claim 11, characterized in that, The policy version is managed by a monotonically increasing version counter inside HSM. Any whitelist or threshold policy with a version number lower than the current active version number shall not be reactivated to prevent the old policy from being rolled back and replayed. The policy records in the device whitelist management module are protected by management key signatures. The device whitelist management module verifies the management key signatures before writing or updating policies, and the policies can only take effect after the verification is successful.

16. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, After completing threshold verification and generating a business signature, the cryptographic operation module returns a request identifier and policy version number bound to the business signature, enabling the KMS gateway to uniquely match the final signature result with the corresponding aggregation task, thereby preventing the signature result from being reused across requests.

17. The system for key management and access control based on a hardware security module according to claim 10, characterized in that, The business key decryption module derives the business key encryption key through HKDF based on the root key, random salt value, and derived input including business key identifier, version context, and algorithm identifier. It then uses AES-256-GCM to perform authentication encryption and authentication decryption on the business private key. The business private key ciphertext record in the business key storage layer includes at least the ciphertext, random salt value, initialization vector, authentication tag, public key, and algorithm identifier.

18. A device for implementing key management and access control based on a hardware security module, characterized in that, The device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the method for key management and access control based on a hardware security module as described in any one of claims 1 to 9.

19. A processor for implementing key management and access control based on a hardware security module, characterized in that, The processor is configured to execute computer-executable instructions, which, when executed by the processor, implement the steps of the method for key management and access control based on a hardware security module as described in any one of claims 1 to 9.

20. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the steps of the method for key management and access control based on a hardware security module as described in any one of claims 1 to 9.

Images