Method for realizing longan chain node key security protection in combination with encryption machine

Abstract

The application relates to a method for realizing long-chain node key security protection in combination with an encryption machine, comprising the following steps: generating and saving a node private key in the encryption machine; deploying a key agent component between a blockchain node and the encryption machine; sending a pre-authorization request to an out-of-band pre-authorization interface of the key agent component through an out-of-band pre-authorization channel; checking signature constraint data SCD; capturing a standard PKCS#11 interface through an in-band interception channel, obtaining a hash value of to-be-signed data, and matching the hash value of the to-be-signed data; the method, system, device, processor and computer readable storage medium thereof for realizing long-chain node key security protection in combination with the encryption machine reduce the risk of inconsistency between an out-of-band authorization context and an in-band signature hash, reduce the risk of continuing to sign a corresponding key after a certificate is revoked, improve the provability of signature event auditing and verification, and reduce the risk of strategy domain mixing when multiple chains share the encryption machine.

Description

Technical Field

[0001] This invention relates to the field of blockchain infrastructure security, and more particularly to the field of cryptographic application cross-technology. Specifically, it refers to a method, system, device, processor, and computer-readable storage medium for achieving secure protection of Chang'an Chain node keys by combining an encryption machine. Background Technology

[0002] Consortium blockchains are widely used in scenarios requiring high security and reliable collaboration, such as government collaboration and financial services. As an independently controllable domestic consortium blockchain technology system, Chang'an Chain provides a complete consensus, node access, and identity authentication mechanism. However, in actual deployments, the security of consortium blockchain node keys remains a critical bottleneck in the entire security protection system.

[0003] In consortium blockchains, nodes undertake core responsibilities such as consensus proposals, block verification, transaction endorsement, message signing, and TLS authentication. These actions are all highly dependent on the node's private key. Once a node's private key is leaked or misused, attackers can forge legitimate identities to participate in consensus or forge management instructions, leading to compromised ledger consistency. Therefore, ensuring the absolute security of node private keys throughout their entire lifecycle and the compliant and controllable use of these keys is a pressing issue that needs to be addressed in the construction of consortium blockchain infrastructure.

[0004] Existing technical solution 1: Software key store combined with file permission control This scheme typically encrypts the node's private key and stores it on the local disk, then loads it into memory and performs the signing process upon startup. However, in a production environment, this scheme has the following drawbacks: 1. Difficulty in closing the key exposure surface: The plaintext private key is retained in the application process memory for a long time. When the system is subjected to high-privilege intrusion, it can be illegally copied through memory reading or debugging injection.

[0005] 2. Vulnerable policy execution path: The use of keys lacks strong hardware-level constraints, and the application-layer software signature policy is easily bypassed by code injection or dynamic library hijacking.

[0006] 3. Low credibility of audit evidence: Auditing is limited to the application log level, and log data is easily tampered with or deleted, failing to form an irrefutable chain of evidence. Cause of the defect: The root cause of this defect lies in the lack of strong protection from a low-level hardware-level root of trust in key storage, use, and auditing.

[0007] Existing technical solution 2: Cloud KMS remote signature mode This scheme involves nodes calling an external Key Management Service (KMS) via a network interface to perform cryptographic operations. However, this scheme introduces the following limitations: 1. Latency and performance limitations: Cryptographic calls rely on external network communication, and in high-concurrency consensus scenarios, network latency jitter can easily affect consensus efficiency.

[0008] 2. Cross-domain compliance and deployment limitations: In heavily regulated scenarios such as government affairs or finance, cross-organizational and cross-domain calls to cloud-based KMS face significant compliance pressures and difficulties in network boundary management. Cause of the flaw: The root cause of this solution's flaw lies in the inherent conflict between the benefits of centralized cloud management and the requirements of low latency and localized secure execution by consortium blockchain nodes.

[0009] Existing technical solution 3: PKCS#11 direct connection HSM access This scheme connects nodes directly to the encryption machine (HSM) via the PKCS#11 standard interface, enabling direct initiation of signature and other computations. However, direct access does not equate to complete key security governance capabilities and has the following limitations: 1. Disconnect between policy and lifecycle management: PKCS#11 only provides low-level cryptographic atomic operation interfaces and cannot understand upper-level business semantics such as consensus and endorsement. Lifecycle processes such as key rotation and certificate binding are still handled on the application side, which can easily lead to inconsistent policy interpretations.

[0010] 2. Risks of Loss of Business Semantics and Unauthorized Access Spoofing: Standard PKCS#11 interfaces (such as C_Sign) are stateless underlying APIs that only receive the hash value of a message. Due to the one-way nature of hash algorithms, underlying cryptographic devices cannot identify the specific business scenario they represent. Malicious callers can request authorization through legitimate low-risk scenarios (such as TLS handshakes), while actually passing in the hash value of high-risk scenarios (such as management commands) to complete the signature, forming a "bait and switch" type of unauthorized access attack. Limitations: The root cause of this flaw lies in the fact that PKCS#11 is a standard cryptographic interface, not a key governance scheme specifically designed for blockchain, and cannot strongly bind the hash to be signed to the upper-level policy context at the cryptographic level.

[0011] In the daily operation and maintenance of consortium blockchains, the following common issues that directly affect key security also exist: 1. Disconnect between key and certificate status verification: Certificate updates and key rotations are performed separately, and there is a lack of linkage between checking the certificate revocation status (such as CRL or OCSP) and key signing calls, resulting in a security vulnerability where "the certificate has been revoked but the corresponding private key can still sign normally".

[0012] 2. Inconsistent multi-channel signature strategies: Consensus signatures, endorsement signatures, and management signatures are usually handled by different components, lacking a unified strategy engine and security baseline, which makes them prone to policy configuration vulnerabilities.

[0013] 3. Audit details are scattered and easily tampered with: System logs and encrypted machine call records are scattered in various places, lacking a collaborative audit mechanism between on-chain and off-chain, making it difficult to conduct non-repudiable and rapid tracing in the event of a security incident.

[0014] In summary, existing solutions have significant limitations in areas such as private key leakage prevention, business semantic binding, certificate revocation linkage, and trusted auditing. Therefore, this invention proposes a method and system for protecting the key security of Chang'an Chain nodes by incorporating an encryption machine, to address the aforementioned deficiencies and limitations of the existing technologies. Summary of the Invention

[0015] The purpose of this invention is to overcome the shortcomings of the prior art and provide a method, system, device, processor and its computer-readable storage medium for achieving secure protection of Chang'an Chain node keys by combining encryption machines, which is low-risk, highly provable and widely applicable.

[0016] To achieve the above objectives, the present invention provides a method, system, apparatus, processor, and computer-readable storage medium for securing the key of Chang'an Chain nodes by combining an encryption machine, as follows: The main feature of this method for securing the key of Chang'an Chain nodes by combining an encryption machine is that the method includes the following steps: (1) The node private key is generated and stored in the encryption machine. The blockchain node application side only uses the logical key identifier key_id to refer to the node private key for cryptographic operations; (2) Deploy a key proxy component between the blockchain node and the encryption machine, wherein the key proxy component includes an out-of-band pre-authorization channel and an in-band interception channel; (3) Before initiating a signature operation, the blockchain node sends a pre-authorization request to the out-of-band pre-authorization interface of the key broker component through the out-of-band pre-authorization channel. The pre-authorization request includes the node session ticket, the hash value of the data to be signed, and the signature constraint data SCD. (4) The key proxy component verifies the signature constraint data SCD. After the verification is successful, it registers an authorization credential that is bidirectionally bound to the hash value of the data to be signed in the authorized credential cache, and sets the validity period of the authorization credential. (5) The key broker component captures the standard PKCS#11 interface initiated by the blockchain node through the in-band interception channel, obtains the hash value of the data to be signed, and matches the hash value of the data to be signed in the authorized credential cache; (6) If the match is successful and within the validity period, the corresponding authorization certificate in the authorized certificate cache is destroyed once, and the logical key identifier key_id is converted into a physical encryption machine key handle, and the physical PKCS#11 interface is used to allow the process and call the encryption machine to perform the signature, and return the standard signature result; If the match fails or the validity period expires, it is determined to be an unauthorized spoofing attack, and the key proxy component directly blocks and rejects the in-band cipher call; (7) Record detailed audit logs for each signature call, generate audit summaries, and periodically anchor the Merkle root value of the audit summaries to the blockchain to establish a verifiable correspondence between off-chain logs and on-chain summaries.

[0017] Preferably, the key broker component adopts a three-layer architecture, including: The interface layer includes an out-of-band gRPC or UDS pre-authorized interface and an in-band PKCS#11 compatible interface; The core processing layer includes a policy engine, an authorized credential cache, an interceptor verifier, a session management module, an auditing module, and an exception handling module. The policy engine is used to perform out-of-band pre-authorization verification, and the interceptor verifier is used to perform in-band hash matching and single-time destruction of authorized credentials. The physical adaptation layer is used to manage the encryption machine connection session pool through the physical PKCS#11 interface, perform the conversion between logical key_id and encryption machine hardware handle, and adapt to encryption machines from different manufacturers.

[0018] Preferably, the key broker component supports access from multiple blockchain systems and achieves independent key management and auditing for different blockchain systems through a strategy isolation mechanism based on blockchain type and node identifier; the audit records of different blockchain nodes are distinguished by the blockchain type field.

[0019] Preferably, the signature constraint data SCD is constructed by the blockchain node, specifically as follows: The key_id, node_id, scene_type, policy_hash, message_hash of the data to be signed, timestamp, and nonce are concatenated using length prefix encoding. The concatenated byte string is then subjected to cryptographic hash operation to generate an SCD value. The length prefix of each field uses fixed-byte big-endian encoding to indicate the byte length of the field.

[0020] Preferably, step (3) further includes the following steps: After receiving the pre-authorization request, the key broker component verifies the session ticket. The verification includes verifying the signature validity of the session ticket, whether the session ticket is within its validity period, whether the node identifier in the session ticket matches, whether the scenario authorization bitmap in the session ticket contains the scenario type for this signature, and whether the policy hash in the session ticket is consistent with the currently loaded policy version. The session ticket is issued by the policy control component using its internal signature key.

[0021] Preferably, in step (4), the key proxy component verifies the signature constraint data SCD, specifically by: The signature constraint data SCD is recalculated using the parameters in the pre-authorization request and compared with the signature constraint data SCD in the request. It is also verified whether the offset between the timestamp and the current time is within the allowed range and whether the random number has been used.

[0022] Preferably, step (4) further includes a dual-channel verification mechanism, wherein the first channel performs scenario-based strategy verification and the second channel performs certificate status verification. The aforementioned scenario-based strategy verification specifically includes: The strategy is matched according to the signature scenario type, node role and risk level, and the request is verified to meet the set time window and rate threshold conditions. The certificate status verification specifically includes: The validity of the CA signature and the certificate validity period are verified step by step along the certificate chain. The certificate revocation status is obtained by querying the local Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). At the same time, the consistency between the public key fingerprint referenced in the Distributed Identity Identifier (DID) document and the certificate public key fingerprint of the blockchain node is verified. If both the first channel and the second channel pass verification, the authorization credential is registered in the authorized credential cache; if either channel fails verification, the registration of the authorization credential is rejected. The revocation status query supports Certificate Revocation List (CRL) mode and Online Certificate Status Protocol (OCSP) mode. When OCSP is unreachable, it falls back to the locally cached CRL to determine the revocation status.

[0023] Preferably, the method further includes a step of generating auditable link anchors, specifically comprising the following processes: Collect audit records generated by signature calls according to the set window, serialize each audit record in the window according to the field order, calculate the password hash value, and use it as the leaf node of the Merkle tree; The leaf nodes are arranged in lexicographical order according to the record identifier trace_id to construct a Merkle tree, and the Merkle root value is calculated. An on-chain record structure containing the window start and end identifiers, the Merkle root value, the number of leaves, and the anchor transaction identifier is written into the blockchain audit contract. During verification, the record ownership is verified by providing a single audit record and its Merkle proof path.

[0024] Preferably, the method further includes a key rotation process, specifically comprising the following steps: After authorization by multiple parties and / or multi-factor authentication, a new key pair is generated within the encryption machine; The certificate signing request is issued using the private key of the new key pair, and the new certificate is issued after verification by the certificate service component, thus establishing a binding relationship between the new key and the new certificate. Open a grayscale observation window where new and old keys are available in parallel, and control the blockchain node to perform grayscale switching; After the grayscale observation window ends, the old key is deactivated, and the rotation process is recorded in the audit log and anchored on the chain.

[0025] Preferably, the method further includes the key broker component executing a controlled degradation strategy when the cryptographic machine is unreachable, specifically including the following steps: Entering a controlled downgrade state, the signature capability configured for high-risk scenarios is suspended, and only management operations and consensus signatures within the whitelist are retained; Trigger a switchover operation from the primary encryption machine to the backup encryption machine. After the switchover, perform a loopback test for signing and verifying the signature and a policy version consistency check for each active logical key identifier. If the test passes, rebuild the node session ticket. If the test fails or the policy version is inconsistent, maintain the controlled degradation state and trigger an alarm. If the primary encryption machine and the backup encryption machine are from different manufacturers, the key proxy component encapsulates and shields the manufacturer differences through a standard PKCS#11 interface.

[0026] The system for securing the key of Chang'an Chain nodes by combining an encryption machine is characterized by the following: The node runtime component is used to send a pre-authorization request to the key broker component through an out-of-band channel and initiate a signature call through the in-band standard PKCS#11 interface; the pre-authorization request contains the hash value of the data to be signed and the signature constraint data SCD. A key broker component is deployed between the blockchain node and the encryption machine; The policy control component is used for policy configuration, version release and integrity verification, as well as for issuing session tickets using its cryptographic in-machine signature key; An encryption machine cluster is used to generate and securely store node private keys and provide physical signature execution. The audit anchoring component is used to record audit logs of signature calls, generate audit summaries, and anchor the audit summaries to the blockchain.

[0027] Preferably, the key proxy component includes an out-of-band pre-authorization interface, an in-band standard PKCS#11 interception driver, and a physical encryption machine adapter module. The out-of-band pre-authorization interface is used to receive the pre-authorization request and verify the signature constraint data SCD. After the verification is successful, the authorization credential is registered in the authorized credential cache with the hash value of the data to be signed as the key. The in-band standard PKCS#11 interception driver is used to capture the signature call and obtain the hash value of the data to be signed, and match it with the authorized credential cache. If the match is successful and the data is within the validity period, the corresponding credential is destroyed in one go, and the logical key identifier key_id is converted into a physical encryption machine key handle. The encryption machine cluster is then called through the physical encryption machine adaptation module to perform the signature. If the match fails, the request is blocked. The physical encryption machine adaptation module is used to convert the logical key_id into a physical encryption machine key handle, and call the encryption machine to perform signing through the physical PKCS#11 interface.

[0028] Preferably, the system further includes a certificate and identity service component for maintaining the mapping relationship between node certificates, Distributed Identity Identifier (DID) documents, and organizational roles. The DID document records the public key information and service endpoints of the node identity. A two-way binding is established between the node certificate and the DID document through public key fingerprints, and the public key reference in the DID document is updated synchronously when the certificate is updated or rotated.

[0029] Preferably, the system further includes an operation and maintenance authorization component, which provides multi-user authorization and multi-factor authentication control for key rotation, key revocation and emergency switching operations, and writes the authorization events into the audit log and then anchors them to the blockchain by the audit anchoring component.

[0030] The device for securing the key of Chang'an Chain nodes by combining an encryption machine is characterized by the following features: 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 various steps of the method described above for combining an encryption machine to achieve secure protection of the Chang'an Chain node keys.

[0031] The processor that combines an encryption machine to implement the security protection of the Chang'an Chain node key 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 the security protection of the Chang'an Chain node key by combining an encryption machine are implemented.

[0032] 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 securing the key of the Chang'an Chain node by combining an encryption machine.

[0033] The present invention employs a method, system, apparatus, processor, and computer-readable storage medium for secure protection of Chang'an Chain node keys by combining an encryption machine. This reduces the risk of inconsistency between out-of-band authorization context and in-band signature hash; reduces the risk of standard PKCS#11 calls being bypassed or replayed; reduces the risk of continued signing with the corresponding key after certificate revocation; improves the provability of signature event audit verification; and reduces the risk of policy field misuse when multiple chains share an encryption machine. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the overall architecture of the system for implementing secure protection of Chang'an Chain node keys by combining an encryption machine, as described in this invention.

[0035] Figure 2 This is a modular architecture diagram of the system functions of the system for implementing secure protection of Chang'an Chain node keys by combining an encryption machine, as described in this invention.

[0036] Figure 3 This is a diagram of the internal architecture of KeyProxy, the key proxy in the method of combining an encryption machine to achieve secure protection of the key of Chang'an Chain nodes according to the present invention.

[0037] Figure 4 This is a core business process diagram of the method for implementing secure protection of Chang'an Chain node keys by combining an encryption machine, as described in this invention.

[0038] Figure 5 This is the core interaction sequence diagram of the method for implementing secure protection of Chang'an Chain node keys by combining an encryption machine according to the present invention.

[0039] Figure 6 This is a key lifecycle state diagram for the method of combining an encryption machine to achieve secure protection of the key of the Chang'an Chain node according to the present invention. Detailed Implementation

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

[0041] The method for securing the key of a Chang'an Chain node by combining an encryption machine according to the present invention includes the following steps: (1) The node private key is generated and stored in the encryption machine. The blockchain node application side only uses the logical key identifier key_id to refer to the node private key for cryptographic operations; (2) Deploy a key proxy component between the blockchain node and the encryption machine, wherein the key proxy component includes an out-of-band pre-authorization channel and an in-band interception channel; (3) Before initiating a signature operation, the blockchain node sends a pre-authorization request to the out-of-band pre-authorization interface of the key broker component through the out-of-band pre-authorization channel. The pre-authorization request includes the node session ticket, the hash value of the data to be signed, and the signature constraint data SCD. (4) The key proxy component verifies the signature constraint data SCD. After the verification is successful, it registers an authorization credential that is bidirectionally bound to the hash value of the data to be signed in the authorized credential cache, and sets the validity period of the authorization credential. (5) The key broker component captures the standard PKCS#11 interface initiated by the blockchain node through the in-band interception channel, obtains the hash value of the data to be signed, and matches the hash value of the data to be signed in the authorized credential cache; (6) If the match is successful and within the validity period, the corresponding authorization certificate in the authorized certificate cache is destroyed once, and the logical key identifier key_id is converted into a physical encryption machine key handle, and the physical PKCS#11 interface is used to allow the process and call the encryption machine to perform the signature, and return the standard signature result; If the match fails or the validity period expires, it is determined to be an unauthorized spoofing attack, and the key proxy component directly blocks and rejects the in-band cipher call; (7) Record detailed audit logs for each signature call, generate audit summaries, and periodically anchor the Merkle root value of the audit summaries to the blockchain to establish a verifiable correspondence between off-chain logs and on-chain summaries.

[0042] In a preferred embodiment of the present invention, the key proxy component adopts a three-layer architecture, including: The interface layer includes an out-of-band gRPC or UDS pre-authorized interface and an in-band PKCS#11 compatible interface; The core processing layer includes a policy engine, an authorized credential cache, an interceptor verifier, a session management module, an auditing module, and an exception handling module. The policy engine is used to perform out-of-band pre-authorization verification, and the interceptor verifier is used to perform in-band hash matching and single-time destruction of authorized credentials. The physical adaptation layer is used to manage the encryption machine connection session pool through the physical PKCS#11 interface, perform the conversion between logical key_id and encryption machine hardware handle, and adapt to encryption machines from different manufacturers.

[0043] In a preferred embodiment of the present invention, the key proxy component supports access from multiple blockchain systems. Through a strategy isolation mechanism based on blockchain type and node identifier, it enables independent management and auditing of keys for different blockchain systems. Audit records of different blockchain nodes are distinguished by the blockchain type field.

[0044] In a preferred embodiment of the present invention, the signature constraint data SCD is constructed by the blockchain node, specifically as follows: The key_id, node_id, scene_type, policy_hash, message_hash of the data to be signed, timestamp, and nonce are concatenated using length prefix encoding. The concatenated byte string is then subjected to cryptographic hash operation to generate an SCD value. The length prefix of each field uses fixed-byte big-endian encoding to indicate the byte length of the field.

[0045] In a preferred embodiment of the present invention, step (3) further includes the following steps: After receiving the pre-authorization request, the key broker component verifies the session ticket. The verification includes verifying the signature validity of the session ticket, whether the session ticket is within its validity period, whether the node identifier in the session ticket matches, whether the scenario authorization bitmap in the session ticket contains the scenario type for this signature, and whether the policy hash in the session ticket is consistent with the currently loaded policy version. The session ticket is issued by the policy control component using its internal signature key.

[0046] In a preferred embodiment of the present invention, the key proxy component in step (4) verifies the signature constraint data SCD, specifically as follows: The signature constraint data SCD is recalculated using the parameters in the pre-authorization request and compared with the signature constraint data SCD in the request. It is also verified whether the offset between the timestamp and the current time is within the allowed range and whether the random number has been used.

[0047] As a preferred embodiment of the present invention, step (4) further includes a dual-channel verification mechanism, wherein the first channel performs scenario-based strategy verification and the second channel performs certificate status verification. The aforementioned scenario-based strategy verification specifically includes: The strategy is matched according to the signature scenario type, node role and risk level, and the request is verified to meet the set time window and rate threshold conditions. The certificate status verification specifically includes: The validity of the CA signature and the certificate validity period are verified step by step along the certificate chain. The certificate revocation status is obtained by querying the local Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). At the same time, the consistency between the public key fingerprint referenced in the Distributed Identity Identifier (DID) document and the certificate public key fingerprint of the blockchain node is verified. If both the first channel and the second channel pass verification, the authorization credential is registered in the authorized credential cache; if either channel fails verification, the registration of the authorization credential is rejected. The revocation status query supports Certificate Revocation List (CRL) mode and Online Certificate Status Protocol (OCSP) mode. When OCSP is unreachable, it falls back to the locally cached CRL to determine the revocation status.

[0048] In a preferred embodiment of the present invention, the method further includes a step of generating auditable link anchors, specifically comprising the following processing steps: Collect audit records generated by signature calls according to the set window, serialize each audit record in the window according to the field order, calculate the password hash value, and use it as the leaf node of the Merkle tree; The leaf nodes are arranged in lexicographical order according to the record identifier trace_id to construct a Merkle tree, and the Merkle root value is calculated. An on-chain record structure containing the window start and end identifiers, the Merkle root value, the number of leaves, and the anchor transaction identifier is written into the blockchain audit contract. During verification, the record ownership is verified by providing a single audit record and its Merkle proof path.

[0049] In a preferred embodiment of the present invention, the method further includes a key rotation process, specifically comprising the following steps: After authorization by multiple parties and / or multi-factor authentication, a new key pair is generated within the encryption machine; The certificate signing request is issued using the private key of the new key pair, and the new certificate is issued after verification by the certificate service component, thus establishing a binding relationship between the new key and the new certificate. Open a grayscale observation window where new and old keys are available in parallel, and control the blockchain node to perform grayscale switching; After the grayscale observation window ends, the old key is deactivated, and the rotation process is recorded in the audit log and anchored on the chain.

[0050] In a preferred embodiment of the present invention, the method further includes the key proxy component executing a controlled degradation strategy when the encryption machine is unreachable, specifically including the following steps: Entering a controlled downgrade state, the signature capability configured for high-risk scenarios is suspended, and only management operations and consensus signatures within the whitelist are retained; Trigger a switchover operation from the primary encryption machine to the backup encryption machine. After the switchover, perform a loopback test for signing and verifying the signature and a policy version consistency check for each active logical key identifier. If the test passes, rebuild the node session ticket. If the test fails or the policy version is inconsistent, maintain the controlled degradation state and trigger an alarm. If the primary encryption machine and the backup encryption machine are from different manufacturers, the key proxy component encapsulates and shields the manufacturer differences through a standard PKCS#11 interface.

[0051] The present invention relates to a system for securing the key of a Chang'an Chain node by combining an encryption machine, wherein the system comprises: The node runtime component is used to send a pre-authorization request to the key broker component through an out-of-band channel and initiate a signature call through the in-band standard PKCS#11 interface; the pre-authorization request contains the hash value of the data to be signed and the signature constraint data SCD. A key broker component is deployed between the blockchain node and the encryption machine; The policy control component is used for policy configuration, version release and integrity verification, as well as for issuing session tickets using its cryptographic in-machine signature key; An encryption machine cluster is used to generate and securely store node private keys and provide physical signature execution. The audit anchoring component is used to record audit logs of signature calls, generate audit summaries, and anchor the audit summaries to the blockchain.

[0052] In a preferred embodiment of the present invention, the key proxy component includes an out-of-band pre-authorization interface, an in-band standard PKCS#11 interception driver, and a physical encryption machine adaptation module. The out-of-band pre-authorization interface is used to receive the pre-authorization request and verify the signature constraint data SCD. After the verification is successful, the authorization credential is registered in the authorized credential cache with the hash value of the data to be signed as the key. The in-band standard PKCS#11 interception driver is used to capture the signature call and obtain the hash value of the data to be signed, and match it with the authorized credential cache. If the match is successful and the data is within the validity period, the corresponding credential is destroyed in one go, and the logical key identifier key_id is converted into a physical encryption machine key handle. The encryption machine cluster is then called through the physical encryption machine adaptation module to perform the signature. If the match fails, the request is blocked. The physical encryption machine adaptation module is used to convert the logical key_id into a physical encryption machine key handle, and call the encryption machine to perform signing through the physical PKCS#11 interface.

[0053] In a preferred embodiment of the present invention, the system further includes a certificate and identity service component for maintaining the mapping relationship between node certificates, distributed identity identifier (DID) documents, and organizational roles. The DID document records the public key information and service endpoint of the node identity. The node certificate and the DID document are bidirectionally bound through public key fingerprints, and the public key reference in the DID document is updated synchronously when the certificate is updated or rotated.

[0054] As a preferred embodiment of the present invention, the system further includes an operation and maintenance authorization component, which provides multi-user authorization and multi-factor authentication control for key rotation, key revocation and emergency switching operations, and writes the authorization events into the audit record and then anchors them to the blockchain by the audit anchoring component.

[0055] The present invention relates to a device for securing the key of a Chang'an Chain node by combining an encryption machine, wherein the device comprises: 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 various steps of the method described above for combining an encryption machine to achieve secure protection of the Chang'an Chain node keys.

[0056] The present invention relates to a processor for implementing secure protection of Chang'an Chain node keys by combining an encryption machine, 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 secure protection of Chang'an Chain node keys by combining an encryption machine are implemented.

[0057] 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 securing the key of the Chang'an Chain node by combining an encryption machine.

[0058] To address the problems of fragmented lifecycles, inconsistent policies, scattered audit evidence, and uncertain anomaly handling in existing technologies for protecting consortium blockchain node keys, this invention proposes a security protection scheme for Chang'an Chain consortium blockchain node keys that incorporates an encryption machine. This scheme is based on the core design concept of "hardware root trust combined with policy orchestration, runtime proxy, and audit closed loop," and constructs a unified mechanism around the entire process of node key generation, hosting, invocation, rotation, revocation, and destruction.

[0059] The objectives of this invention include, but are not limited to, the following aspects: One of the objectives is to establish a strongly constrained path where node private keys cannot be exported, so that signing capabilities are provided externally as "service capabilities" rather than "key materials," thereby reducing the risk of key material leakage and misuse.

[0060] The second objective is to establish a unified policy framework for various signature scenarios (consensus, endorsement, management instructions, TLS) on the Chang'an Chain, so as to achieve "the same policy language, differentiated execution" and improve the consistency of policy governance.

[0061] The third objective is to achieve bidirectional adaptation through the PKCS#11 standard interface—providing a PKCS#11 compatible interface to the node side and calling the PKCS#11 standard interface to the HSM side, enabling the system to have HSM vendor decoupling capabilities, supporting primary and backup heterogeneous HSM deployments, and avoiding single vendor lock-in.

[0062] Fourth objective: To establish a key protection middleware that supports access from multiple blockchain systems, and to achieve independent management and auditing of keys from different blockchain systems through a policy isolation mechanism based on chain type and node identifier.

[0063] Fifth objective: To establish an on-chain and off-chain collaborative auditing mechanism, enabling the correlation and verification of node call behavior, policy version, encryption machine execution records, and on-chain anchor digests, forming a complete audit evidence chain.

[0064] Objective Six: To establish security degradation and recovery processes for abnormal and disaster recovery scenarios, maintain business continuity and retain audit verifiability within defined boundaries, and reduce unpredictable risks in abnormal scenarios.

[0065] Seventh objective: While meeting the compliance and governance requirements of consortium blockchains, it also takes into account the deployability of the project, making it easy to implement in single-organization multi-node and cross-organization multi-institutional environments.

[0066] To achieve the above objectives, this invention aims to provide a more implementable, auditable, clearly defined key protection technology path for Chang'an Chain consortium chain nodes and other blockchain systems, which also has multi-chain scalability.

[0067] This invention relates to the cross-disciplinary field of blockchain infrastructure security and cryptographic applications, specifically to a key security protection method, system, device, and computer-readable storage medium for ChainMaker consortium blockchain nodes. In particular, it relates to an integrated key protection mechanism that coordinates the encryption machine (HSM, Hardware Security Module) with the blockchain node's signature, certificate, consensus, and operation and maintenance processes through the PKCS#11 standard interface. This mechanism can be extended to other blockchain systems such as Ethereum and Fabric.

[0068] This invention introduces a key proxy component (KeyProxy) between the blockchain node and the encryption machine. This component provides a PKCS#11 compatible interface for blockchain nodes to call, and interfaces with HSMs from different vendors via a PKCS#11 standard interface. Furthermore, it builds policy verification, audit semantic enhancement, and anomaly orchestration capabilities between these standard interfaces. Figure 1 As shown.

[0069] KeyProxy's core technical features are as follows: A policy engine, auditing module, and exception handling layer are added between the upstream (to nodes) and downstream (to HSM) sides of the PKCS#11 standard interface, upgrading encryption operations from "direct pass-through" to a "policy-based, auditable, and orchestratable" controlled call path. A single KeyProxy instance can simultaneously serve multiple blockchain nodes, including Chang'an Chain, Ethereum, and Fabric, achieving independent key management for different blockchain systems through policy isolation.

[0070] A method for securing the key of a Chang'an Chain node by combining an encryption machine includes the following steps: The node private key is generated and securely stored within the encryption machine. The blockchain node application side only uses the logical key identifier (key_id) to reference the private key for cryptographic operations. A key broker component is deployed between the blockchain node and the encryption machine, the key broker component including an out-of-band pre-authorization channel and an in-band interception channel; In the out-of-band pre-authorization channel, before initiating a signature operation, the blockchain node sends a pre-authorization request to the out-of-band pre-authorization interface of the key broker component. The pre-authorization request carries the node session ticket, the hash value of the data to be signed, and the signature constraint data SCD. After receiving the pre-authorization request, the key proxy component verifies the session ticket and signature constraint data SCD. If the verification is successful, it registers an authorization credential that is bidirectionally bound to the hash value of the data to be signed in the authorized credential cache in memory. In the in-band interception channel, the blockchain node calls the standard PKCS#11 interface provided by the key broker component and passes in the hash value of the data to be signed. The in-band interception driver of the key broker component captures this call and matches the hash value in the authorized credential cache. If a match is successful and the validity period is within the set period, the corresponding authorization credential in the authorized credential cache is destroyed in a single instance, and the logical key identifier key_id is converted into a physical encryption machine key handle. The process is then allowed through the physical PKCS#11 interface, and the encryption machine is called to perform the signature, returning a standard signature result. If the match fails or the set validity period expires, it is determined to be an unauthorized spoofing attack, and the key proxy component directly blocks and rejects the in-band cipher call; Record detailed audit logs for each signature call, generate audit summaries, and periodically anchor the Merkle root value of the audit summaries to the blockchain to establish a verifiable correspondence between off-chain logs and on-chain summaries.

[0071] The key broker component adopts a three-tier architecture: Interface layer: Includes out-of-band gRPC / UDS pre-licensed interfaces and in-band standard PKCS#11 compatible interfaces; Core processing layer: integrates a policy engine, authorized credential cache, interceptor verifier, session management module, auditing module, and exception handling module. The policy engine performs out-of-band pre-authorization verification, and the interceptor verifier performs in-band hash matching and single credential destruction. Physical adaptation layer: Utilizes the physical PKCS#11 interface to manage the encryption machine connection session pool, execute logic key_id conversion with encryption machine hardware handle, and adapt to encryption machines from multiple vendors.

[0072] The key broker component supports access from multiple blockchain systems. Through a strategy isolation mechanism based on blockchain type and node identifier, it enables independent management and auditing of keys for different blockchain systems. One key broker component instance can simultaneously serve at least two types of blockchain nodes in Changan Chain, Ethereum, and Fabric.

[0073] The pre-authorization request is subject to differentiated policy control based on the signature scenario type. The signature scenario type includes at least one or more of consensus signature, transaction endorsement signature, management instruction signature, and TLS communication signature. Different scenario types correspond to independent policy parameter sets within the key broker component. The policies are versioned and support traceability and rollback.

[0074] The Signature Constraint Data (SCD) is constructed by blockchain nodes in the out-of-band pre-authorization channel. The SCD contains the authorized signature context and the corresponding hash value of the data to be signed. It is constructed using length prefix encoding, and the fields include at least: key_id, node_id, scene_type, policy_hash, and message_hash, which are represented by 2-byte big-endian encoding, as well as an 8-byte timestamp and a 16-byte nonce. The constructed byte string is subjected to cryptographic hash operation to generate the SCD value. The SCD is used for context and hash anti-tampering verification of the out-of-band pre-authorization channel and does not participate in the hash operation of the encryption machine hardware signature, so as to achieve a strong cryptographic binding between the signature policy context and the hash value of the data to be signed.

[0075] When the encryption machine is unreachable, the key proxy component executes a controlled degradation strategy, including: retaining only the signing capability of whitelist management operations while suspending high-risk signing, triggering a switch between primary and backup encryption machines and performing policy version consistency verification and key signature-verification loopback test, outputting alarms and maintaining continuous audit records; wherein when the primary and backup encryption machines use equipment from different manufacturers, the key proxy component shields the manufacturer differences through the PKCS#11 standard interface.

[0076] The method also includes a key rotation process: after authorization by multiple parties and / or multi-factor authentication, a new key pair is generated in the encryption machine; a Certificate Signing Request (CSR) is issued using the new private key and a new certificate is issued after verification by the certificate service, establishing a binding relationship between the key and the certificate; the old and new keys are available in parallel within a set grayscale observation window; the old key is deactivated after the observation window is passed; the entire rotation process is recorded in an audit log and anchored to the blockchain.

[0077] The audit summary is generated using a windowed aggregation method: audit records are collected in fixed windows, and each audit record is serialized according to the field order and its cryptographic hash value is calculated as a Merkle tree leaf node. After being arranged in lexicographical order by trace_id, a Merkle tree is constructed. The start and end identifiers of the window, the Merkle root value, the number of leaves, and the anchor transaction identifier are written into the on-chain audit contract. During verification, by providing a single audit record and its Merkle proof path, it is verified in O(log n) time whether the record belongs to the corresponding window.

[0078] The method also includes a session ticket mechanism: the policy control component issues session tickets using its in-memory signature key, the session ticket containing a ticket identifier, a node identifier, a node random number, a scenario authorization bitmap, a policy hash, an issuance time, and a validity period; the key broker component verifies the signature validity and validity period of the session ticket during each out-of-band pre-authorization, verifies the matching of the node identifier with the scenario authorization bitmap, and extracts the ticket fields for SCD verification after the verification is passed; the signature key of the policy control component is also hosted in the encryption machine cluster.

[0079] The method further includes performing a dual-channel verification mechanism during out-of-band pre-authorization: the first channel performs the scenario-based policy verification, and the second channel performs certificate status verification. If either channel fails verification, pre-authorization is rejected. The certificate status verification includes: verifying the validity of the CA signature and the certificate validity period level by level along the certificate chain, querying the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP) to obtain the certificate revocation status, and verifying the consistency between the public key fingerprint referenced in the Distributed Identity Identifier (DID) document and the public key fingerprint of the node certificate. When the OCSP is unreachable, the method falls back to the locally cached CRL to determine the revocation status.

[0080] A security protection system for Chang'an Chain node keys combined with an encryption machine includes: The node runtime component is used to initiate an out-of-band pre-authorization request and call the in-band standard PKCS#11 interface to initiate cryptographic signing. The pre-authorization request carries the signature scenario type, node identifier, and hash value of the data to be signed. A key proxy component, deployed between the Chang'an Chain nodes and the encryption machine, includes an out-of-band pre-authorization interface, an in-band standard PKCS#11 interception driver, an authorized credential cache, a policy and interception engine, and a physical encryption machine adaptation module. The out-of-band pre-authorization interface receives and verifies pre-authorization requests sent by nodes and registers the authorization hash in the authorized credential cache. The in-band standard PKCS#11 interception driver captures in-band cipher calls from nodes, verifies them against the authorized credential cache, and destroys them once. The physical encryption machine adaptation module interfaces with the physical encryption machine and provides multi-vendor compatibility. The policy control component is used for policy configuration, version release, and integrity verification, and issues session tickets using its encrypted in-machine signature key; Encryption machine clusters are used for the generation, custody, and physical standard signature execution of node private keys; The audit anchoring component is used for audit record aggregation, Merkle summary generation, and on-chain anchoring.

[0081] The key broker component supports access from multiple blockchain systems and enables independent key management for different blockchain systems by isolating them according to blockchain type. One instance of the key broker component can simultaneously serve at least two blockchain nodes in Changan Chain, Ethereum, and Fabric.

[0082] The system also includes a certificate and identity service component, which is used to maintain the mapping relationship between node certificates, distributed identity identifiers (DIDs), and organizational roles. The DID document records the public key information of the node identity, and a two-way binding is established between the certificate and the DID through the public key fingerprint. When the certificate is updated or rotated, the public key reference in the DID document is updated synchronously.

[0083] The system also includes an operation and maintenance authorization component, which provides multi-factor and multi-user authorization control for key rotation, revocation, and emergency switchover operations; authorization events are recorded in audit logs and anchored to the blockchain.

[0084] The key broker component employs a dual-channel verification mechanism during pre-authorization: the first channel performs scenario-based policy verification through the policy and interception engine, and the second channel performs certificate status verification through the certificate service. If either channel fails verification, the registration of the authorization hash certificate is rejected. The certificate status verification includes: certificate chain verification at each level, revocation status query based on the Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP), and DID document public key fingerprint consistency verification. When OCSP is unreachable, the revocation status is determined by reverting to the locally cached CRL.

[0085] 1. System Architecture Figure 2 This system functional / module architecture diagram illustrates the boundary relationships between multi-chain node domains, out-of-band pre-authorization, in-band interception, security control domains, and encryption machine domains, addressing issues such as unified access to encryption machines for multiple blockchain systems, loss of semantics in standard cryptographic interfaces, and HSM vendor lock-in.

[0086] In the above architecture, KeyProxy (see Section 2), policy control component (see Section 5.1), audit anchoring component (see Section 5.3), security mechanism (see Section 6), and alternative path (see Section 7) will be described in detail in the following sections.

[0087] The responsibilities of each module are as follows: KeyProxy: As the core component of this invention, it is a general-purpose cryptographic middleware layer for blockchains deployed locally on nodes or in side-wheel containers. It features a dual-channel collaborative control design with out-of-band channels (gRPC / UDS) and in-band channels (standard PKCS#11): The out-of-band channel receives and verifies policy authorization information sent by nodes, registering short-term authorization credentials in memory; the in-band channel provides a standard PKCS#11-compatible interface, intercepting signature calls from blockchain nodes and forcibly verifying them against the hash value in the authorized credentials. After successful verification, KeyProxy calls the physical HSM through the underlying PKCS#11 interface to complete the standard signature, thereby achieving a strong cryptographic binding between the security context and the data to be signed without modifying the standard API definition.

[0088] Policy Controller: Maintains policy versions, scenario rules, and risk classification rules, and sends verifiable policy snapshots to KeyProxy. Policies are versioned, ensuring that policy changes have a traceable and rollbackable management basis.

[0089] Encryption machine session and key slot management: Responsible for session reuse, key handle mapping, concurrent queue scheduling, failure reconnection, and master / slave failover. Provides KeyProxy with a stable and reliable encryption machine access channel.

[0090] Certificate and Identity Services: Maintains the mapping relationship between node certificates, Distributed Identity Identifiers (DIDs), and roles. The DID document records the public key information and service endpoints of the node's identity. A two-way binding is established between the certificate and the DID through public key fingerprints. When a certificate is updated or rotated, the public key reference in the DID document is updated synchronously. Establishing the binding relationship between the key, certificate, and DID ensures that changes in any dimension can be traced along the audit chain.

[0091] 2. KeyProxy Internal Architecture As the core component of this invention, KeyProxy adopts a design combining channel-based and layered architecture. It provides an out-of-band pre-authorization interface and an in-band PKCS#11 interface upwards, and connects to HSM downwards through the PKCS#11 interface, thus establishing an out-of-band verification and in-band interception check mechanism between standard interfaces. Figure 3 As shown, KeyProxy is internally divided into three layers: the interface layer, the core processing layer, and the adaptation layer.

[0092] Technical advantages of KeyProxy middleware: Seamless PKCS#11 interface compatibility: It provides a standard PKCS#11 compatible interface, allowing blockchain nodes to connect directly without modifying the underlying cryptographic driver; it connects to various vendors' HSMs via PKCS#11, shielding underlying session management and hardware differences, and supporting multi-vendor decoupling.

[0093] Dual-channel security defense: The introduction of out-of-band pre-authorization and in-band hash interception and verification mechanism overcomes the cryptographic vulnerability of the standard PKCS#11 interface, which is "stateless and without business semantics", and completely eliminates the risk of unauthorized deception against key brokers (such as "bait and switch" attacks).

[0094] Unified management of multiple chains: It supports the simultaneous access of multiple blockchain systems such as Changan Chain, Ethereum, and Fabric on a single KeyProxy instance, performs protocol isolation at the interface layer, and implements independent policy management of keys for different chains and nodes at the policy control layer.

[0095] Security and Audit Closed Loop: The signature policy (SCD / Ticket), cryptographic operations, timestamps, unique hashes, and on-chain anchoring are closely linked to form an immutable off-chain detailed log and on-chain index audit chain.

[0096] Automatic anomaly orchestration: Provides built-in error code conversion, hot switching between primary and backup HSMs, key signature-verification loopback self-check, and security degradation control, ensuring business continuity under high security requirements.

[0097] 3. Data Model and Object Definition This invention defines the following core objects: KeyMeta (Key Metadata): The fields include: key_id, hsm_slot, algorithm (enumerated values: SM2, ECDSA_P256, ECDSA_secp256k1, Ed25519), key_usage, owner_org, node_id, state, create_time, and rotate_epoch.

[0098] Here, `key_id` is a logical identifier; the actual key material exists only within the security boundaries of the encryption machine. Key metadata is used to manage the logical attributes of the key and is stored separately from the actual key material.

[0099] SignPolicy: The fields include: policy_id, scene_type, risk_level, allowed_algo_set (e.g., {SM2}, {ECDSA_P256, Ed25519}, {SM2, ECDSA_secp256k1}), max_qps, ttl_ms, require_mfa, and fallback_mode.

[0100] This is used to describe the constraints for different signature scenarios. The strategy can be configured differently according to scenario type and risk level.

[0101] SessionTicket: The fields include: ticket_id, node_id, node_nonce, policy_hash, scene_bitmap, issued_at, expiry, and sig.

[0102] This is used to constrain signature requests to be valid within a limited time window and to bind the policy version. Session tickets are issued by the Policy Controller using the signature key it holds. The Policy Controller itself also protects its signature key with a cryptographic machine (i.e., as one of the callers of the KeyProxy, the Policy Controller's key is also hosted in the cryptographic machine cluster, or stored in a separate HSM partition). The issued message is: ticket_msg=ticket_id || node_id || node_nonce || policy_hash || scene_bitmap || issued_at || expiry ticket.sig=HSM_SIGN(policyControllerKey, ticket_msg) Before each signing request, KeyProxy verifies ticket.sig (using the default public key of the Policy Controller or a public key obtained through a certificate service) to confirm that the ticket has not been tampered with and originates from a trusted policy control component. Upon successful verification, it extracts the node_id, scene_bitmap, policy_hash, and expiration fields for policy validation.

[0103] AuditRecord: Fields include: trace_id, node_id, scene_type, key_id, policy_id, result_code, latency_bucket, digest, anchor_txid.

[0104] Used to support cross-system verification. Audit logs cover the entire signature request process.

[0105] Explanation of abbreviations (explanation upon first appearance): HSM: Hardware Security Module (encryption device).

[0106] KMS: Key Management Service.

[0107] DID: Decentralized Identifier.

[0108] SCD: Signature Constraint Data (encoding the context of the signature request for policy verification and auditing records within KeyProxy).

[0109] SM3: China's national cryptographic standard SM3 cryptographic hash algorithm (GB / T 32905-2016).

[0110] 4. Main process and sub-processes like Figure 4 As shown, the main process is defined in steps: Main process description: S101 (Node Startup and Configuration Loading): The node loads only the non-sensitive startup configuration and does not load any exportable private key material. The minimum configuration includes non-sensitive information such as the node identifier, policy control address, and encryption machine connection parameters.

[0111] S102-S103 (Policy Retrieval and Signature Verification): KeyProxy retrieves a policy snapshot and verifies its signature to confirm the policy's source is trustworthy and its version is consistent. Policy signature verification uses a digital signature mechanism to identify instances where the policy has been tampered with.

[0112] S104 (Dual-channel service initialization): KeyProxy initializes the session pool that connects to the encryption machine, and simultaneously enables the out-of-band gRPC pre-authorization interface and the in-band standard PKCS#11 interception driver.

[0113] S105-S106 (Out-of-band Pre-authorization): Before conducting a specific transaction or reaching consensus, a node submits a pre-authorization request to KeyProxy via an out-of-band channel. This request includes the node's SessionTicket, the corresponding SCD for the scenario, and the hash value of the data to be signed. KeyProxy performs multi-dimensional verification through its policy engine. If successful, it registers the "authorized credential" (with a very short TTL, defaulting to 3 seconds) corresponding to the hash of the data to be signed in memory, and strongly binds the authorization context to the hash. If unsuccessful, it intercepts and records the audit.

[0114] In-band signature interception and verification: The node calls the standard PKCS#11 interface C_Sign(hSession, hash), passing in the hash value of the data to be signed. The KeyProxy in-band interception driver intercepts this call and searches for the hash value in the in-memory authorized credential cache. If it is found and the credential has not expired, it is determined to be authorized and allowed, and the credential is immediately destroyed in the cache (to prevent replay); if it cannot be matched, it is determined to be an unauthorized spoofing attack, and the in-band cipher call is directly blocked.

[0115] Password execution and result return: After successful interception and verification, KeyProxy calls HSM via the PKCS#11 interface to complete the actual signature. If the signature fails due to device issues, a retry or master / slave failover is performed; if successful, a standard signature is returned.

[0116] Audit anchoring: Call audit records are written to the detailed log, and the audit component periodically writes the summary Merkle root to the blockchain for cross-verification.

[0117] Sub-process A: Key rotation (S201-S207) The key rotation process is used to balance the security of key updates with business continuity: S201 (Initiate Rotation Request): The operations team initiates a rotation request, submitting the target node, the purpose of the target key, and the effective window. The request must clearly specify the rotation scope and timeline.

[0118] S202 (Authorization Approval): The operation and maintenance authorization component performs multi-person approval and multi-factor authentication, so that the rotation operation goes through the preset authorization process.

[0119] S203 (New Key Generation): Generates a new key pair within the encryption machine and returns the new key_id. The new key is generated within the security boundaries of the encryption machine.

[0120] S204 (CSR Generation and Certificate Issuance): The encryption machine uses a new private key to issue a Certificate Signing Request (CSR). After the certificate service verifies the validity of the CSR signature, it issues and distributes a new certificate, establishing a binding relationship between the certificate and the key.

[0121] S205 (Gray-scale Switching): The node is switched to the new key_id in a gray-scale manner, and a parallel observation window for the old and new keys is opened. The observation window is used to verify the availability of the new key.

[0122] S206 (Disable Old Key): The old key is disabled after the observation window passes. The old key is now disabled and will no longer be used for signing operations.

[0123] S207 (Audit Anchoring): The audit component records rotation evidence and anchors it on the blockchain. The entire rotation process is traceable.

[0124] Sub-process B: Exception handling (S301-S306) The exception handling process is used to constrain security degradation in abnormal scenarios: S301 (Anomaly Detection): HSM unreachable or error code exceeding threshold detected. The system continuously monitors the encryption machine status.

[0125] S302 (Entering Degradation Mode): Enters a controlled degradation mode, retaining only whitelist management operations. High-risk operations are restricted in degradation mode.

[0126] S303 (Primary / Backup Switchover): Triggers a switchover to the peer backup HSM and rebuilds the session ticket, forming a controlled failover path.

[0127] S304 (Handover Failure Handling): If the handover fails, suspend high-risk signatures and continue to issue alerts. Maintain minimum available capacity.

[0128] S305 (Conformity Verification): After recovery, a consistency verification (policy version, certificate status, audit continuity) is performed to confirm that the system status meets the recovery conditions.

[0129] S306 (Exit Degraded State): Exits the degraded state and generates an event report. Restores normal operation.

[0130] 5. Core Algorithm / Strategy 5.1 Context-based signature strategy matching algorithm Input: scene_type, node_role, risk_level, request_context Output: policy_decision (ALLOW / DENY / CHALLENGE) and policy_id The strategy matching rules include the following steps: (5.1.1) Scene localization: Locate the candidate strategy set by scene_type. Different signature scenarios correspond to different strategy templates.

[0131] (5.1.2) Domain filtering: Filter cross-domain mismatch policies by node_role and owner_org to limit the organizational boundaries to which the policies apply.

[0132] (5.1.3) Dynamic verification: Verify dynamic conditions based on time window, rate threshold, and request source. Dynamic conditions reflect the real-time operating status.

[0133] (5.1.4) Risk Decisions: Determine whether to add additional challenges (such as MFA or secondary approval) based on the risk level. High-risk operations require additional verification.

[0134] (5.1.5) Decision Output: Output the final decision along with the policy hash. The policy hash is used for subsequent verification.

[0135] This algorithm avoids the lack of adaptability caused by a fixed single strategy and supports "differentiated execution within the same framework".

[0136] 5.2 Construction and Constraint Mechanism of Signature Constraint Data (SCD) Before a node initiates any signing operation, it must undergo pre-authorization via an out-of-band channel in the KeyProxy policy engine. During this process, KeyProxy constructs and verifies Signature Constraint Data (SCD). SCD is a structured cryptographic binding between the signature request context and the hash of the data to be signed. It is used for policy verification and auditing records within KeyProxy. It is transmitted out-of-band and written to the in-memory credential cache, without altering the format of the final signature result returned through the standard interface. This allows all blockchain network signature verification nodes to seamlessly verify standard signatures while ensuring the controllability of the node-side call path.

[0137] SCD Construction Specification (using length prefix encoding to prevent ambiguity attacks from multi-field concatenation): scd_bytes=len(key_id, 2) || key_id || len(node_id, 2) || node_id || len(scene_type, 2) || scene_type || len(policy_hash, 2) || policy_hash || len(message_hash, 2) || message_hash || timestamp_bytes(8) || nonce(16) SCD = SM3(scd_bytes) Where len(field, 2) represents the field length in 2-byte big-endian encoding, || is byte string concatenation, nonce is a 16-byte cryptographically secure random number generated by the node, and timestamp is a 64-bit Unix millisecond timestamp. message_hash is the hash value of the data to be signed (e.g., the SM3 hash of the Chang'an Chain transaction plaintext, with a length of 32 bytes). In Chinese cryptographic scenarios, the hash algorithm SM3 is uniformly used; in international algorithm scenarios, it can be replaced by SHA-256.

[0138] By forcibly embedding message_hash into the SCD constructor, this invention achieves a strong binding between the signature context (scenario, ticket, identity) and the signed data (hash) at the cryptographic level, completely solving the limitation of semantic loss in the signature stage of the general PKCS#11 interface.

[0139] Dual-channel collaborative constraint mechanism workflow: 1. Out-of-band pre-authorization phase (node ​​application process -> KeyProxy gRPC interface); Step A: The node calculates the hash value of the data to be signed, generates a random nonce, and obtains the current millisecond timestamp; Step B: Construct the SCD and send a pre-authorization request to the KeyProxy gRPC interface; KeyProxy's strategy engine handles out-of-band requests: (1) Verify the validity of the SessionTicket signature and its validity period; (2) Recalculate SCD using the request parameters and verify SCD; (3) Verify whether the scene_type in the request is in the scene bitmap authorized by the SessionTicket; (4) Verify whether the time offset exceeds the limit, and verify the nonce deduplication cache; (5) If all verifications pass, register a record in the "Authorized Credentials Cache" in memory; (6) Return a pre-authorization success response to the node.

[0140] 2. In-band signature execution phase (node ​​application process -> standard PKCS#11 interface); Step C: The node initiates a standard PKCS#11 signature call through the loaded KeyProxy interception driver; KeyProxy in-band driver (C_Sign) processing logic: (1) Intercept the call and extract the input parameter message_hash; (2) Retrieve the cached authorized credentials in memory; (3) If no corresponding record is found, or the record has exceeded the 3-second validity period, it is determined to be a deceptive attack (such as an unauthorized call that is "selling dog meat under the guise of mutton") or a replay request, the call is rejected and returned, triggering an emergency audit alarm; (4) If a valid credential is found, extract the logical key_id and scene_type corresponding to that credential: The message_hash record is immediately and once destroyed from the cache (to prevent replay attacks against in-band interfaces). Convert the logical key_id to a physical HSM key handle, and then call the physical HSM to perform the actual signing; The parameter actual_sig is returned to the blockchain node as the parameter standard_sig; Record detailed audit logs.

[0141] Authorized credential sharing strategy under multi-instance KeyProxy: When KeyProxy is deployed in a multi-instance high-availability configuration, to ensure that hash credentials registered by nodes in out-of-band channels can be correctly read by any in-band interception instance, the in-memory "authorized credential cache" adopts the following approach: Single-machine same-process mode (preferred): Blockchain nodes and KeyProxy are deployed one-to-one in the form of sidecar or same machine. Out-of-band channels and in-band interceptors share the same KeyProxy process's memory cache. Its access latency is in the microsecond range and no distributed synchronization is required.

[0142] Dual-machine hot standby shared mode: In dual-machine redundant deployment, the out-of-band pre-authorization interface writes credentials to the local memory while synchronizing them to the standby memory via RDMA or an ultra-low latency multicast channel, ensuring that authorized credentials are not lost during primary-standby switchover.

[0143] By introducing the aforementioned dual-channel design of "out-of-band pre-authorization registration + in-band hash interception verification and destruction", this invention ensures seamless compatibility with standard interfaces, while placing policy and context verification in advance and establishing strong consistency verification during final signature execution, preventing any possibility of bypassing or deceiving policy control.

[0144] 5.3 Auditable Link Anchoring Mechanism The audit component aggregates AuditRecords by fixed window (e.g., by block height window or time window), constructs a Merkle tree summary, and writes it to the on-chain audit contract. Detailed logs are stored off-chain, while summaries and window indexes are stored on-chain.

[0145] Merkle audit tree construction specification: Leaf node: leaf_i = SM3(AuditRecord_i.serialize()), each AuditRecord is serialized in field order and then the SM3 hash is obtained; Sorting rule: Sort by trace_id lexicographical order to ensure the sorting of leaf nodes within the same window; Internal node: node = SM3(left_child||right_child), if the number of leaves is odd, copy the last leaf to make up the number; On-chain record structure: (chain_id, window_start, window_end, root_hash, leaf_count, anchor_txid); Verification method: The auditor provides (AuditRecord, MerkleProof), and the on-chain contract calculates the path hash and compares it with the root_hash; Verification can be performed using the following methods: Summary recalculation: Recalculate the Merkle root of the detailed log window and compare it with the root_hash recorded on the chain; On-chain comparison: Compare multiple window Merkle roots stored on-chain to verify data integrity; Merkle proof verification: Given a single AuditRecord and its Merkle path, the contract verifies in O(log n) time whether the record belongs to the window; Time series verification: Verify the anchor_txid with the time series to check the time sequence of audit records.

[0146] This mechanism provides a verifiable evidence path for determining whether an event has been tampered with.

[0147] 5.4 Encryption Machine Master / Slave Switchover and Consistency Constraints To avoid policy drift or key inconsistency caused by primary / standby switching, this invention stipulates the following consistency constraints: (5.4.1) Version verification: Before switching, verify that the policy version of the backup node is not lower than the effective version of the master node to avoid policy rollback after switching.

[0148] (5.4.2) Key Consistency Verification (Signature-Verification Loopback Test): After the switchover, KeyProxy performs a signature-verification test on each active key_id: a random challenge message is signed using the HSM key corresponding to the key_id, and the signature is verified using the corresponding public key (obtained from the certificate service). If successful, the primary and backup keys are confirmed to be consistent; if unsuccessful, an alarm is triggered and the switchover is prevented to prevent signature verification failure due to inconsistent primary and backup HSM key mappings.

[0149] (5.4.3) Echo Verification: The first batch of requests after the switch will be subject to mandatory policy_hash echo verification to verify policy consistency.

[0150] (5.4.4) Downgrade Maintenance: If version inconsistency or key loopback test failure alarms occur consecutively, the system will maintain controlled downgrade instead of automatically releasing it. This is to avoid the spread of risk.

[0151] 5.5 Session Ticket Issuance and Verification Protocol A Session Ticket is a time-limited authorization credential issued by the Policy Controller to the KeyProxy. The ticket mechanism decouples "policy verification" from "signature execution," allowing the KeyProxy to perform multiple signatures within the ticket's validity period without needing to initiate remote policy queries to the Policy Controller each time, thereby reducing the policy query latency overhead on the consensus critical path.

[0152] Ticket Issuance Agreement (Policy Controller → KeyProxy): (1) When KeyProxy starts up or when the ticket is about to expire, it sends a ticket request to the policy control component, carrying (node_id, node_nonce, requested_scenes[]); (2) After verifying the KeyProxy's identity, the policy control component assembles the ticket message: ticket_msg=ticket_id(16)||node_id||node_nonce|| policy_hash || scene_bitmap(4) || issued_at(8) || expiry(8) (3) Where ticket_id is a 16-byte random identifier, scene_bitmap is a 4-byte bitmap encoding of the set of authorized signature scenes for this node, and expiry and issued_at are 8-byte Unix millisecond timestamps; (4) The policy control component uses its in-memory signing key to sign ticket_msg. ticket.sig=HSM_SIGN(policyControllerKey, ticket_msg); (5) The signature key of the policy control component itself is also hosted in the encryption machine cluster, or shares a different partition of the same HSM cluster with the node key; (6) Return (ticket_msg, ticket.sig) as a ticket to KeyProxy.

[0153] Ticket verification protocol (executed on the KeyProxy side before each signature request): (1) Parse each field of ticket_msg and check if expiry is greater than the current time; (2) Verify the authenticity of ticket.sig using the pre-set public key of the policy control component (obtained through the certificate service or securely pre-set); (3) Verify that the node_id matches the currently requested node; (4) Verify whether the corresponding scene bit in the scene_bitmap is set; (5) Verify that the policy_hash is consistent with the policy version currently loaded by KeyProxy; (6) If any verification fails, the signature is rejected and the audit event is recorded.

[0154] Bill lifecycle management: The expiry-issued_at period is configurable by default, but a value of 5-30 minutes is recommended to balance security and performance.

[0155] KeyProxy proactively renews tickets within one-third of the time window before they expire, and the policy control component reissues new tickets during the renewal process.

[0156] When the policy version is updated, the policy control component actively pushes a policy change notification. KeyProxy verifies the signature of the new policy snapshot, refreshes the local policy, and re-applies for tickets.

[0157] The node_nonce in the ticket is consistent with the nonce recorded by the policy control component, which is used to reduce the risk of replay across tickets.

[0158] 5.6 Dual-channel certificate status verification mechanism This invention introduces a dual-channel verification mechanism before signature execution, separating policy verification (first channel) and certificate status verification (second channel) for separate execution. Signature is rejected if either channel fails verification. This mechanism aims to address the security risk of "a certificate being revoked but the corresponding key still being able to sign," establishing a mandatory linkage between the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) status and key invocation.

[0159] The first channel—policy verification: is executed according to the scenario-based policy matching algorithm described in Section 5.1. The verification content includes scenario permissions, role matching, rate threshold, time window, etc.

[0160] Second Channel – Certificate Status Verification: After the verification policy passes but before calling HSM signing, KeyProxy performs the following certificate status checks: (1) Certificate chain verification: Starting from the node certificate, verify the signature validity, validity period and key usage extension of each CA certificate level along the certificate chain to confirm that the certificate trust chain is complete and has not expired; (2) Revocation Status Check: Query the revocation status of node certificates, supporting two modes: CRL mode: Periodically pull the certificate revocation list, cache the CRL locally and verify its validity period, and check whether the certificate serial number is in the CRL when signing; OCSP mode: Initiates a real-time query to the OCSP responder to obtain the current status of the certificate (Good / Revoked / Unknown). OCSP requests use nonce to prevent replay attacks, and the OCSP response is accepted after signature verification. Hybrid mode: OCSP real-time query is prioritized. If OCSP is unreachable, it falls back to the CRL local cache. If OCSP returns Unknown and there is no record in CRL, you can choose to allow or deny according to the policy configuration (the default is denial in high-risk scenarios and alarm-based allowance in low-risk scenarios).

[0161] (3) DID Binding Verification: Check whether the public key fingerprint referenced in the DID document is consistent with the public key fingerprint of the node certificate to confirm that the DID document is synchronized with certificate changes. If the public key reference in the DID document does not match the certificate public key, refuse to sign and report an alert (this may be due to the DID not being synchronized after certificate rotation, or the existence of an identity forgery attack). Dual-channel coordinated execution process: function signWithDualChannelCheck(req): / / First Channel: Policy Verification policy_decision=policy_engine.evaluate(req.scene_type, req.node_id, req.risk_level) if policy_decision != ALLOW: return DENY_WITH_AUDIT("policy_deny", policy_decision) / / Second channel: Certificate status verification cert_status=certificate_service.check( node_id = req.node_id, check_crl = true, check_ocsp=config.ocsp_enabled, check_did_binding = true ) if cert_status != VALID: return DENY_WITH_AUDIT("cert_invalid", cert_status.detail) / / Both channels passed, proceed with signature execution result=hsm.sign(keyId=policy.keyId, data=req.payload) return {sig: result.sig, traceId: audit.traceId} CRL / OCSP caching strategy: The CRL local cache is updated periodically (by default, hourly, configurable). When signing, the CRL cache time is checked first to see if it is within the validity period plus tolerance window. The OCSP response cache duration follows the nextUpdate field indication in the OCSP response (usually 7 days), combined with the minimum cache time (default 1 hour) to avoid frequent queries; Certificate status change events (revocation, freeze) trigger proactive cache refresh, reducing the risk during the status window.

[0162] 6. Security and Anomaly Handling Mechanisms This invention employs the following security and anomaly handling mechanisms: (6.1) Non-export constraint: All private keys are generated, used, rotated, and destroyed within the encryption machine; the application layer only sees the logical key_id. Key materials are not exported to the node application layer in plaintext.

[0163] (6.2) High availability guarantee of KeyProxy itself: KeyProxy supports multi-instance deployment (such as master-slave or load balancing mode), and the instances maintain consistency through shared policy snapshots and session state synchronization. When a single KeyProxy instance is unavailable, the blockchain node can switch to the standby KeyProxy instance. During the switchover process, the issued SessionTickets can continue to be used within their validity period, reducing the risk of signature service interruption.

[0164] (6.3) Least privilege control: KeyProxy uses the least privilege session account when calling the encryption machine, and does not grant irrelevant management capabilities. The principle of minimizing privileges reduces the risk of misuse.

[0165] (6.4) Dual-channel verification: Policy verification and certificate status verification (including CRL / OCSP revocation status check and DID binding verification) are performed separately. If either fails, the signature is rejected. See Section 5.6 for details.

[0166] (6.5) Rate and Concurrency Protection: Configure QPS and concurrency limits according to the scenario. Requests exceeding the limit will be queued or rejected and the results will be logged for auditing. This prevents resource exhaustion attacks.

[0167] (6.6) Exception Closure: Error codes are mapped to standard handling actions (retry, switchover, degradation, blocking) to avoid inconsistent behavior caused by discretion. Standardized exception handling is used to improve the certainty of handling behavior.

[0168] (6.7) Time Synchronization Constraints: Nodes and policy control components perform time offset verification. When the offset exceeds the threshold (default ±5 seconds), sensitive signature operations are suspended to reduce the risk of time window replay. Time synchronization can be based on the time base provided by NTP or the blockchain consensus network. It is recommended to configure multiple independent time sources to resist single-point NTP attacks.

[0169] 7. Alternative Implementation Paths This invention supports at least the following alternative paths: Alternative Path 1 (Local Proxy): KeyProxy is deployed on the same machine as the node, accessing HSM via Unix Domain Socket or local loopback network, suitable for low-latency consensus scenarios. Local deployment reduces network overhead.

[0170] Alternative Path Two (Side-Mount Proxy): KeyProxy is deployed as a container side-mount, connecting to a physical HSM or HSM gateway via the PKCS#11 standard interface. This is suitable for unified operation and maintenance scenarios in Kubernetes clusters. Containerized deployment improves operational efficiency.

[0171] Alternative Path 3 (Hierarchical Key Domains): Different HSM partitions are allocated according to "Consensus Signature Domain / Endorsement Signature Domain / Management Signature Domain," and key domain isolation is achieved through KeyProxy's PKCS#11 multi-session management. The hierarchical design improves security.

[0172] Alternative Path 4 (Hybrid Hosting): The certificate private key is located in the local HSM (via PKCS#11), the business temporary key is derived from the upper-level KMS and bound by the policy, and KeyProxy connects to both PKCS#11 and KMS API, which is suitable for cross-regional joint deployment.

[0173] Alternative Path 5 (Primary / Backup Heterogeneous): The primary and backup HSMs use equipment from different vendors. KeyProxy uses the PKCS#11 standard interface to shield vendor differences, enabling primary / backup heterogeneous deployment and avoiding vendor lock-in.

[0174] Alternative Path Six (Multi-Chain Shared Type): A single KeyProxy middleware serves multiple blockchain nodes, including Chang'an Chain, Ethereum, and Fabric, achieving independent management of multi-chain keys through policy isolation (by chain type, node ID, and key purpose). Suitable for hybrid deployment scenarios involving cross-chain collaboration and multi-chain coexistence, it reduces the operational complexity caused by the parallel maintenance of multiple adaptable components.

[0175] Different paths share the same policy language and audit anchoring model, thereby maintaining governance consistency when deployment patterns change.

[0176] 8. Differences from existing technologies The differences between this invention and existing technical solutions can be described from the following aspects: Dimension 1: Key Storage and Retrieval Methods. Solution 1 (Software Keystore) encrypts and stores keys on local disk, performs signing in memory, and the key material is visible and exportable at the software layer. Solution 2 (Cloud KMS) hosts keys on a remote service, and invocation depends on the network. Solution 3 (PKCS#11 Direct HSM Access) can migrate some or all key operations to HSM, but lacks upper-layer policy control, lifecycle closure, and audit semantics. This invention generates, uses, rotates, and destroys private keys within the encryption machine. KeyProxy calls HSM through the PKCS#11 standard interface. Key material is not exported to the node application layer in plaintext, and the middleware layer provides policy verification and enhanced audit capabilities.

[0177] Dimension Two: Policy Control Capability. Solution One primarily relies on application-layer code logic. Solution Two provides tenant-level policies but lacks sufficient granularity. Solution Three's policy control is typically scattered across node applications or script adaptation layers, making it difficult to form a consistent policy framework for scenarios such as consensus, endorsement, management commands, and TLS. This invention incorporates a scenario-based policy engine, supporting differentiated configurations for different signing scenarios, versioned policy management, and traceability and rollback capabilities.

[0178] Dimension Three: Auditing Capabilities. Solution 1 relies solely on application logs, which can be tampered with. Solution 2 relies on KMS logs, which are disconnected from business semantics. Solution 3 relies heavily on HSM device logs or application-side supplementary logs, making it difficult to reliably correlate with business scenarios. This invention uses an audit anchoring component to periodically anchor call summaries on the blockchain. Off-chain detailed logs and on-chain summaries can be cross-validated, and audit records include business semantic fields such as trace_id, node_id, scene_type, and policy_id.

[0179] Dimension Four: Deterministic Anomaly Handling and HSM Compatibility. Solutions one through three typically lack a unified handling process for HSM failures, network fluctuations, or certificate status changes, requiring applications to implement their own primary / backup failover and retry logic. This invention defines standardized error code mapping, primary / backup failover constraints, and controlled degradation strategies, supporting primary and backup HSMs using equipment from different vendors (achieving heterogeneous failover through the PKCS#11 standard interface), ensuring predictable anomaly behavior.

[0180] Dimension 5: Multi-Blockchain Adaptability. Solutions 1 through 3 are primarily designed for single-blockchain systems, requiring separate development of an adaptation layer for each blockchain. This invention, KeyProxy, provides a PKCS#11 compatible interface, allowing nodes from different blockchains such as Chang'an Chain, Ethereum, and Fabric to connect via standard interfaces. A single middleware set serves multiple chains simultaneously, and policy isolation enables independent key management for each chain.

[0181] Based on the comparative analysis across the five dimensions above, the core technological advancement of this invention compared to existing solutions lies in converging the key protection capabilities, originally scattered across the software, network, and application layers, into an integrated mechanism encompassing hardware root trust, policy orchestration, and audit anchoring, through the KeyProxy middleware. Dimension one is used to converge key material exposure paths; dimension two is used to alleviate policy governance fragmentation; dimension three is used to enhance the verifiability of audit evidence; dimension four is used to improve the certainty of anomaly handling; and dimension five is used to reduce the complexity of adapting to multiple blockchain systems separately. These improvements collectively constitute an improvement path from "single-point key protection measures" to a "key security governance system."

[0182] Figure 1This diagram illustrates the overall system architecture, showcasing KeyProxy's role as middleware between blockchain nodes and encryption machines, as well as the structural relationship between multiple blockchain systems accessing each other through a unified PKCS#11 interface. Figure 1 This diagram describes KeyProxy's role as middleware between blockchain nodes and encryption machines. It illustrates the structural relationship between the encryption machine cluster, multiple blockchain nodes, and the KeyProxy middleware, as well as the technical approach KeyProxy uses to enhance policy verification and auditing capabilities across the upstream and downstream interfaces of the PKCS#11 standard. This diagram addresses the combined problems of large key exposure, inconsistent policies, fragmented audit evidence, and uncertain anomaly handling in existing technical solutions.

[0183] Figure 2 This diagram illustrates the system's functional and modular architecture, describing the boundary relationships between multi-chain node domains, out-of-band pre-authorization, in-band interception, security control domains, and encryption machine domains, as well as the dual-channel collaboration role of KeyProxy between upper-layer business and lower-layer encryption machines. This diagram addresses the issues of unified access to the encryption machine for multiple blockchain systems, loss of standard cryptographic interface semantics, and avoiding HSM vendor lock-in.

[0184] Figure 3 This diagram illustrates the internal architecture of KeyProxy, describing its interface layer and its three-layer structure: out-of-band channel, in-band interception channel, authorized credential cache, core processing layer, and downward PKCS#11 adaptation layer. This diagram addresses the issues of direct PKCS#11 calls lacking policy context binding and being vulnerable to unauthorized spoofing attacks.

[0185] Figure 4 This diagram serves as the core business process flow diagram, describing the main steps and key verification points of out-of-band policy pre-authorization → hash credential registration → in-band PKCS#11 interception and verification → password call approval → audit anchoring. It also describes the main process from node startup, dual-channel service initialization, out-of-band pre-authorization credential registration, in-band signature interception and verification, and physical HSM signature execution to audit anchoring, including failure paths (rejection, blocking, retry, switchover). This diagram addresses the issues of lost semantics and spoofing bypass of standard cryptographic interfaces in the signature stream.

[0186] like Figure 5 The diagram illustrates in detail the cryptographic interactions between out-of-band pre-authorization and in-band interception. Specifically, it highlights the construction of a bidirectional TLS (mTLS) channel, the transmission and recalculation of the SCD and SessionTicket, the registration and destruction logic of the memory cache, and the complete steps of the physical HSM performing signature using the business private key within the security boundary.

[0187] Figure 5The core interaction sequence diagram describes the message sequence and cryptographic relationship between dual-channel pre-authorization verification, hash cache binding, in-band interception verification, and physical encryption machine signature.

[0188] like Figure 6 As shown, this illustrates the complete lifecycle closed-loop management state of the key generated within the security boundary of the physical cryptographic machine (HSM), as well as the state transition paths of each stage under policy control and governance instructions.

[0189] Figure 6 This is a key lifecycle state machine diagram that describes the triggering conditions and governance boundaries of each state from generation to destruction, solving the problem of decentralized and non-closed-loop lifecycle management.

[0190] In a specific embodiment of the present invention, the present invention will be described below with reference to a production environment example.

[0191] Example Environment: A cross-institutional financial consortium blockchain network adopts the Chang'an Chain multi-organization deployment topology, with each organization containing at least two consensus nodes and several endorsement nodes. Each organization deploys a dual-machine hot-standby encryption machine cluster, and nodes access the encryption machine through a local KeyProxy.

[0192] Initialization phase: During system initialization, operations and maintenance personnel complete multi-factor authentication through the authorization component, triggering the generation of node signature key pairs within the HSM; the public key is submitted to the certificate service to issue node certificates, and the key_id is bound to the node_id and owner_org. The initialization process ensures that the key generation stage is within the hardware security boundary.

[0193] Operation phase: During the runtime signing phase, KeyProxy uses a dual-channel collaborative operation to complete secure signature verification and release.

[0194] When the Chang'an Chain consensus engine initiates a signature: 1. The node first initiates a pre-authorization request to KeyProxy through an out-of-band gRPC channel, submitting parameters such as the SessionTicket it holds, the authorized scenario SCD, and the hash value of the data to be signed, message_hash.

[0195] 2. KeyProxy performs multi-factor policy verification and SCD recalculation on the out-of-band pre-authorization interface. After the verification is successful, the message_hash is registered in the "authorized credential cache" in memory, and a timeout of 3 seconds is set for automatic destruction (TTL).

[0196] 3. The node application then initiates a C_Sign(hSession, message_hash) call through the standard PKCS#11 interface.

[0197] 4. The locally deployed KeyProxy in-band interception driver captures this call and retrieves it from the credential cache using `message_hash` as the key. If the retrieval is successful and does not time out, the cached credential is immediately destroyed to prevent replay, and the logical `key_id` is converted into a physical HSM handle, allowing the call to the physical HSM to complete the actual signature, ensuring a strong binding between the signature payload and the policy context. If the retrieval fails or times out, it is determined to be an unauthorized spoofing attack, and the in-band cipher call is directly blocked.

[0198] Multi-chain adaptation extension implementation example: In cross-chain collaboration scenarios, the same organization simultaneously runs Chang'an Chain nodes, Ethereum nodes, and Fabric nodes. These three sets of nodes share the same KeyProxy middleware instance and connect via a PKCS#11 compatible interface. KeyProxy internally implements isolation strategies based on chain type (the `chain_type` field). Chang'an Chain node signature request: Scenarios include consensus, endorsement, TLS, and management; the strategy is configured according to the consortium blockchain governance rules. Ethereum node signature requests: Scenarios include transaction signing and contract deployment signing, with strategies controlled by account permissions; Fabric node signature requests: Scenarios include endorsement signatures and chaincode lifecycle management signatures, with policies configured based on channel and organization permissions; Audit logs use the `chain_type` field to differentiate call behaviors across different chains, enabling independent traceability and unified management of cross-chain audit evidence. One middleware service serves three chains, reducing the operational costs associated with maintaining multiple adaptation components separately.

[0199] Abnormal handling: If the primary HSM error code continuously exceeds the threshold, the system performs a controlled switchover: suspending high-risk management signatures, maintaining the minimum capacity of the consensus signature whitelist, switching to the backup HSM, and performing a policy consistency review. Normal operation resumes after the review is successful.

[0200] Example pseudocode is as follows: / / 1. Out-of-band channel: The node initiates a pre-authorization to the KeyProxy gRPC interface. function preAuthorize(req): / / Step 1: Policy Loading and SessionTicket Signature Verification policy=verifyAndLoadPolicy(req.sceneType, req.nodeId) ticket=verifySessionTicket(req.nodeId, policy.hash) / / Step 2: Construction and Verification of Cryptographically Strongly Bound SCD scd=buildSCD(req.nodeId, req.sceneType, policy.hash, req.messageHash, ticket.nonce) if not policy_controller.allow(req.sceneType, req.nodeId, scd): return DENY("policy_deny") / / Step 3: Dual-channel verification of certificate status (second channel) cert_status=checkCertificateStatus( nodeId = req.nodeId, checkCRL=true, checkOCSP=config.ocsp_enabled, checkDIDBinding=true ) if cert_status != VALID: return DENY("cert_invalid") / / Step 4: Verification passed, register the authorized hash credential in the very short-lived (TTL=3s) cache. memory_cache.set(req.messageHash, { keyId: policy.keyId, sceneType: req.sceneType, expiresAt: now() + 3000 }) return ALLOW / / 2. In-band channel: PKCS#11 C_Sign interface interception verification function C_Sign(hSession, message_hash): / / Step 1: Intercept the call and retrieve the credential corresponding to the hash to be signed from the memory cache. credential=memory_cache.get(message_hash) if not credential or credential.expiresAt <now(): audit.write_alert(message_hash, "P11_INTERCEPT_BYPASS_ATTEMPT") return CKR_GENERAL_ERROR / / Reject unauthorized or excessive signature requests. / / Step 2: If a match is successful, immediately destroy the cached credentials in a single transaction to prevent replay. memory_cache.delete(message_hash) / / Step 3: Convert the logical key_id and allow calls to the physical HSM physicalKeyHandle=getPhysicalKey(credential.keyId) sig=physical_hsm.sign(hSession, physicalKeyHandle, message_hash) audit.write_log(message_hash, credential.sceneType, sig) return sig This embodiment is only used to explain the principles of the present invention. For those skilled in the art, adjustments to the deployment configuration, strategy parameters, audit window granularity, and switching threshold without departing from the core ideas of the present invention will all fall within the protection scope of the present invention.

[0201] The core technical concept of this invention lies in the following: while maintaining the compatibility of the existing PKCS#11 standard signature interface of blockchain nodes such as Chang'an Chain, a key proxy KeyProxy is set up between the node and the encryption machine. Through a dual-channel collaborative mechanism of "out-of-band pre-authorization + in-band interception and verification", the context such as signature scenario, policy version, node identity, hash to be signed, timestamp and random number are cryptographically bound with signature constraint data SCD. The temporary authorization certificate is verified when the standard PKCS#11 signature is called, thereby reducing the risk of unauthorized spoofing and replay caused by the standard PKCS#11 interface only receiving hashes and being unable to recognize upper-layer business semantics.

[0202] The inventive aspect of this invention lies not in simply "blockchain calling the encryption machine" or "storing signature rules within the hardware module," but in establishing a verifiable correspondence between upper-layer business semantics and lower-layer hash signature calls through mechanisms such as out-of-band pre-authorization, in-band C_Sign interception and verification, SCD constraint binding, and short-term credential single destruction, while maintaining compatibility with the PKCS#11 standard signature interface. Therefore, the technical solution of this invention can be further supplemented with technical descriptions from the perspectives of "signature semantic binding under standard interface compatibility," "temporary authorization credential and in-band hash verification," and "policy version, certificate status, DID binding, and audit anchoring collaborative constraints."

[0203] The core technical features of this invention can be summarized into the following six groups: 1. Dual-channel collaborative control mechanism. The KeyProxy in this invention simultaneously includes an out-of-band pre-authorization channel and an in-band PKCS#11 interception channel: Before formal signing, the node submits the session ticket, signature scenario, hash to be signed, and SCD through the out-of-band channel; after KeyProxy verifies the information, it registers a very short-lived temporary authorization credential; when the node subsequently initiates a standard C_Sign call, KeyProxy intercepts and checks whether a valid credential exists for the same hash, and if a match is found, immediately destroys the credential once and calls the physical HSM for signing. This mechanism is not a typical interface forwarding or load balancing mechanism.

[0204] 2. Cryptographic binding mechanism for SCD signature constraint data. When constructing the SCD, the technical solution of this invention encodes key_id, node_id, scene_type, policy_hash, message_hash, timestamp, and nonce using a length prefix and then hashes them, forming a recalculable binding relationship between "who, in what scenario, according to which policy version, and on which hash".

[0205] 3. Supplementing business semantics without changing the standard signature result format. The technical solution of this invention addresses the deficiency of the PKCS#11 standard C_Sign, which only accepts hashes and HSMs and cannot recognize upper-layer business semantics. It adopts out-of-band SCD verification and in-band hash verification, so that the final signature result returned to blockchain nodes such as Chang'an Chain is still the standard signature result, without affecting the overall network signature verification compatibility.

[0206] 4. Session Ticket and Policy Versioning Governance. The SessionTicket of the technical solution of this invention is issued by the policy control component and includes ticket_id, node_id, node_nonce, scene_bitmap, policy_hash, issued_at, and expiry. The signature, validity period, node identity, authorization scenario, and policy hash consistency are verified during each pre-authorization.

[0207] 5. Certificate status and DID-linked pre-signature verification. The technical solution of this invention incorporates certificate status verification as part of the pre-authorization process. If any channel verification fails, the registration of the authorization hash certificate will be rejected, thereby reducing the risk of "the certificate has been revoked but the key can still be used for signing".

[0208] 6. On-chain and off-chain collaborative audit anchoring. The technical solution of this invention aggregates AuditRecord by window, constructs a Merkle root and anchors it to the on-chain, so that off-chain details such as trace_id, node_id, scene_type, policy_id, result_code, etc. can be cross-verified with on-chain digests to form a traceable evidence chain for signature call behavior.

[0209] The specific technical problem actually solved by the technical solution of this invention is not "how to enable the blockchain to call the encryption machine", but "how to establish verifiable constraint binding between the upper-layer signature business semantics and the final hash signature call while maintaining the compatibility of the PKCS#11 standard signature interface".

[0210] The dual-channel core link includes "out-of-band pre-authorization registration authorization hash certificate" and "in-band C_Sign interception, verification and single destruction of certificate". Among them, TTL, single destruction, and rejection of signature if message_hash matching fails are important execution details that distinguish it from ordinary adapter forwarding.

[0211] The field composition and length prefix encoding of SCD can further illustrate its role in preventing splicing, preventing cross-scenario replacement, and preventing policy version mismatch.

[0212] SessionTicket is bound to policy_hash, scene_bitmap, node_nonce, and expiry, and the policy control component can use the signature key in the encryption machine to issue tickets.

[0213] Certificate status linkage verification includes certificate chain verification, CRL / OCSP revocation query, and DID document public key fingerprint consistency verification, which are prerequisites for authorized hash credential registration.

[0214] The audit anchor structure may include the AuditRecord field, sorting by trace_id, Merkle tree construction, on-chain record window start and end, root_hash, leaf_count and anchor_txid, and Merkle proof verification for a single audit record.

[0215] Multi-chain policy isolation is not simply about "being compatible with multiple blockchains," but rather about implementing key, policy, and audit domain isolation within the same KeyProxy instance based on chain_type, node_id, key_id, scene_type, and policy_hash.

[0216] The technical problem actually addressed by the technical solution of this invention is that when consortium chain nodes such as Chang'an Chain call the encryption machine to sign through the PKCS#11 standard interface, the standard C_Sign interface usually only passes in the hash to be signed, lacking business context such as node identity, signing scenario, policy version and certificate status. Therefore, it is necessary to establish a verifiable constraint relationship between the above business context and the hash to be signed without changing the standard signature interface and the network-wide signature verification compatibility.

[0217] This invention features a dual-channel KeyProxy processing link: KeyProxy includes an out-of-band pre-authorization channel and an in-band PKCS#11 interception channel; the out-of-band pre-authorization request carries SessionTicket, scene_type, message_hash, timestamp, nonce, and SCD; after KeyProxy verifies the request, it registers a short-term authorization credential using message_hash as the key; the in-band C_Sign call is intercepted and compared with the credential; if the verification is successful, the credential is destroyed once and HSM signing is called; if the verification fails, the signing is rejected.

[0218] The SCD field of this invention includes at least key_id, node_id, scene_type, policy_hash, message_hash, timestamp, and nonce; the field uses length prefix encoding; the authorization credential is set with a short TTL and is destroyed immediately after a successful verification; the SessionTicket contains an authorization scene bitmap, policy hash, issuance time, and validity period; certificate status verification can cover certificate chain, CRL / OCSP, and DID public key fingerprint consistency.

[0219] The abnormal or unauthorized call scenarios of this invention include: replacing high-risk hashes after authorization in low-risk scenarios, directly calling C_Sign by bypassing out-of-band pre-authorization, reusing authorized hashes, continuing to sign after certificate revocation, using old tickets during policy version updates, and multi-chain nodes misusing other chain policies. The technical solution of this invention provides constraints through SCD, temporary credentials, single destruction, certificate status verification, and policy_hash binding.

[0220] This invention, through a combined design of "strong encryption machine protection + policy orchestration + audit anchoring," can achieve the following technical effects within the established boundaries of consortium blockchain deployment: Effect 1: Key exposure surface convergence. Since the private key does not leave the encryption machine boundary, and the node application layer only holds the logical identifier and session handle, the risk of leakage caused by the plaintext key contact surface can be reduced in common operation and maintenance and application anomaly scenarios. The key exposure path can be effectively converged.

[0221] Effect 2: Enhanced consistency in policy execution. Through a unified policy language and versioned release mechanism, different signature scenarios can be executed under the same rule system, reducing policy discrepancies caused by differences in component implementation. Policy consistency improves governability.

[0222] Effect 3: Multi-blockchain system adaptability. KeyProxy provides a PKCS#11 compatible interface, allowing blockchain nodes to connect via a standard interface, reducing the need to develop separate adaptation layers for each blockchain. A single middleware set can simultaneously support the signature requirements of different blockchains such as Chang'an Chain, Ethereum, and Fabric, achieving independent management of multi-chain keys through policy isolation, thus reducing development and operation costs in cross-chain scenarios.

[0223] Benefit 4: HSM Vendor Compatibility and Heterogeneous Primary / Backup Capabilities. Based on the PKCS#11 standard interface, the KeyProxy middleware can shield the underlying implementation differences between different HSM vendors, supporting the use of different vendor equipment for primary and backup, thus avoiding vendor lock-in risks. Heterogeneous deployment of primary and backup can reduce the risk of single point of failure caused by the failure of a single vendor's equipment.

[0224] Effect 5: Improved Audit and Verification Efficiency. By linking on-chain anchored summaries with off-chain detailed logs, a traceable chain of evidence can be formed in compliance audits and event debriefings, reducing the uncertainty of manually piecing together multi-source logs. Audit and verification efficiency can thus be improved.

[0225] Effect Six: Improved Predictability of Anomaly Recovery. Through standard error code mapping, primary / backup switchover constraints, and controlled degradation strategies, critical business continuity can be maintained within predetermined risk thresholds during encryption machine fluctuations or network anomalies. The predictability of anomaly recovery behavior enhances system resilience.

[0226] Effect 7: Improved Cross-Organizational Governance Implementability. In multi-organizational consortium blockchain scenarios, node roles, organizational boundaries, and authorization processes can be implemented through policy configuration, reducing reliance on a single hard-coded path. Improved cross-organizational governance implementability enhances the scalability of the consortium blockchain.

[0227] This invention, through the aforementioned technical solution, can improve the continuity of the signature process in certain implementation scenarios, reduce the possibility of unexpected signature releases during abnormal periods, and enhance the clarity of audit evidence retrieval and verification paths. The specific degree of improvement depends on implementation conditions such as deployment topology, load intensity, device specifications, and policy configuration.

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

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

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

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

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

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

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

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

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

[0237] The present invention employs a method, system, apparatus, processor, and computer-readable storage medium for secure protection of Chang'an Chain node keys by combining an encryption machine. This reduces the risk of inconsistency between out-of-band authorization context and in-band signature hash; reduces the risk of standard PKCS#11 calls being bypassed or replayed; reduces the risk of continued signing with the corresponding key after certificate revocation; improves the provability of signature event audit verification; and reduces the risk of policy field misuse when multiple chains share an encryption machine.

[0238] 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 securing the key of a Chang'an Chain node by combining an encryption machine, characterized in that, The method includes the following steps: (1) The node private key is generated and stored in the encryption machine. The blockchain node application side only uses the logical key identifier key_id to refer to the node private key for cryptographic operations; (2) Deploy a key proxy component between the blockchain node and the encryption machine. The key proxy component includes an out-of-band pre-authorization channel and an in-band interception channel. (3) Before initiating a signature operation, the blockchain node sends a pre-authorization request to the out-of-band pre-authorization interface of the key broker component through the out-of-band pre-authorization channel. The pre-authorization request includes the node session ticket, the hash value of the data to be signed, and the signature constraint data SCD. (4) The key proxy component verifies the signature constraint data SCD. After the verification is successful, it registers the authorization certificate that is bidirectionally bound to the hash value of the data to be signed in the authorized certificate cache, and sets the validity period of the authorization certificate. (5) The key broker component captures the standard PKCS#11 interface initiated by the blockchain node through the in-band interception channel, obtains the hash value of the data to be signed, and matches the hash value of the data to be signed in the authorized credential cache; (6) If the match is successful and within the validity period, the corresponding authorization certificate in the authorized certificate cache is destroyed once, and the logical key identifier key_id is converted into a physical encryption machine key handle, and the physical PKCS#11 interface is used to allow the process and call the encryption machine to perform the signature, and return the standard signature result; If the match fails or the validity period expires, it is determined to be an unauthorized spoofing attack, and the key proxy component directly blocks and rejects the in-band cipher call; (7) Record detailed audit logs for each signature call, generate audit summaries, and periodically anchor the Merkle root value of the audit summaries to the blockchain to establish a verifiable correspondence between off-chain logs and on-chain summaries.

2. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The key broker component adopts a three-tier architecture, including: The interface layer includes an out-of-band gRPC or UDS pre-licensed interface and an in-band PKCS#11 compatible interface; The core processing layer includes a policy engine, an authorized credential cache, an interceptor verifier, a session management module, an auditing module, and an exception handling module. The policy engine is used to perform out-of-band pre-authorization verification, and the interceptor verifier is used to perform in-band hash matching and single-time destruction of authorized credentials. The physical adaptation layer is used to manage the encryption machine connection session pool through the physical PKCS#11 interface, perform the conversion between logical key_id and encryption machine hardware handle, and adapt to encryption machines from different manufacturers.

3. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The key broker component supports access from multiple blockchain systems. Through a strategy isolation mechanism based on blockchain type and node identifier, it enables independent management and auditing of keys for different blockchain systems. Audit records of different blockchain nodes are distinguished by the blockchain type field.

4. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The signature constraint data SCD is constructed by the blockchain node, specifically as follows: The key_id, node_id, scene_type, policy_hash, message_hash of the data to be signed, timestamp, and nonce are concatenated using length prefix encoding. The concatenated byte string is then subjected to cryptographic hash operation to generate an SCD value. The length prefix of each field uses fixed-byte big-endian encoding to indicate the byte length of the field.

5. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, Step (3) further includes the following steps: After receiving the pre-authorization request, the key broker component verifies the session ticket. The verification includes verifying the signature validity of the session ticket, whether the session ticket is within its validity period, whether the node identifier in the session ticket matches, whether the scenario authorization bitmap in the session ticket contains the scenario type for this signature, and whether the policy hash in the session ticket is consistent with the currently loaded policy version. The session ticket is issued by the policy control component using its internal signature key.

6. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 4, characterized in that, In step (4), the key proxy component verifies the signature constraint data SCD, specifically as follows: The signature constraint data SCD is recalculated using the parameters in the pre-authorization request and compared with the signature constraint data SCD in the request. It is also verified whether the offset between the timestamp and the current time is within the allowed range and whether the random number has been used.

7. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, Step (4) also includes a dual-channel verification mechanism, wherein the first channel performs scenario-based strategy verification and the second channel performs certificate status verification; The aforementioned scenario-based strategy verification specifically includes: The strategy is matched according to the signature scenario type, node role and risk level, and the request is verified to meet the set time window and rate threshold conditions. The certificate status verification specifically includes: The validity of the CA signature and the certificate validity period are verified step by step along the certificate chain. The certificate revocation status is obtained by querying the local Certificate Revocation List (CRL) or the Online Certificate Status Protocol (OCSP). At the same time, the consistency between the public key fingerprint referenced in the Distributed Identity Identifier (DID) document and the certificate public key fingerprint of the blockchain node is verified. If both the first channel and the second channel pass verification, the authorization credential is registered in the authorized credential cache; if either channel fails verification, the registration of the authorization credential is rejected. The revocation status query supports Certificate Revocation List (CRL) mode and Online Certificate Status Protocol (OCSP) mode. When OCSP is unreachable, it falls back to the locally cached CRL to determine the revocation status.

8. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The method also includes the step of generating auditable link anchors, specifically including the following processing steps: Collect audit records generated by signature calls according to the set window, serialize each audit record in the window according to the field order, calculate the password hash value, and use it as the leaf node of the Merkle tree; The leaf nodes are arranged in lexicographical order according to the record identifier trace_id to construct a Merkle tree, and the Merkle root value is calculated. An on-chain record structure containing the window start and end identifiers, the Merkle root value, the number of leaves, and the anchor transaction identifier is written into the blockchain audit contract. During verification, the record ownership is verified by providing a single audit record and its Merkle proof path.

9. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The method also includes a key rotation process, specifically comprising the following steps: After authorization by multiple parties and / or multi-factor authentication, a new key pair is generated within the encryption machine; The certificate signing request is issued using the private key of the new key pair, and the new certificate is issued after verification by the certificate service component, thus establishing a binding relationship between the new key and the new certificate. Open a grayscale observation window where new and old keys are available in parallel, and control the blockchain node to perform grayscale switching; After the grayscale observation window ends, the old key is deactivated, and the rotation process is recorded in the audit log and anchored on the chain.

10. The method for implementing key security protection of Chang'an Chain nodes by combining an encryption machine according to claim 1, characterized in that, The method also includes a key broker component executing a controlled degradation strategy when the encryption machine is unreachable, specifically including the following steps: Entering a controlled downgrade state, the signature capability configured for high-risk scenarios is suspended, and only management operations and consensus signatures within the whitelist are retained; Trigger a switchover operation from the primary encryption machine to the backup encryption machine. After the switchover, perform a loopback test for signing and verifying the signature and a policy version consistency check for each active logical key identifier. If the test passes, rebuild the node session ticket. If the test fails or the policy version is inconsistent, maintain the controlled degradation state and trigger an alarm. If the primary encryption machine and the backup encryption machine are from different manufacturers, the key proxy component encapsulates and shields the manufacturer differences through a standard PKCS#11 interface.

11. A system for implementing the method of claim 1 by combining an encryption machine to achieve secure protection of the key of a Chang'an Chain node, characterized in that, The system includes: The node runtime component is used to send a pre-authorization request to the key broker component through an out-of-band channel and initiate a signature call through the in-band standard PKCS#11 interface; the pre-authorization request contains the hash value of the data to be signed and the signature constraint data SCD. A key broker component is deployed between the blockchain node and the encryption machine; The policy control component is used for policy configuration, version release and integrity verification, as well as for issuing session tickets using its cryptographic in-machine signature key; An encryption machine cluster is used to generate and securely store node private keys and provide physical signature execution. The audit anchoring component is used to record audit logs of signature calls, generate audit summaries, and anchor the audit summaries to the blockchain.

12. The system for protecting the key security of Chang'an Chain nodes by combining an encryption machine according to claim 11, characterized in that, The key proxy component includes an out-of-band pre-authorization interface, an in-band standard PKCS#11 interception driver, and a physical encryption machine adapter module. The out-of-band pre-authorization interface is used to receive the pre-authorization request and verify the signature constraint data SCD. After the verification is successful, the authorization credential is registered in the authorized credential cache with the hash value of the data to be signed as the key. The in-band standard PKCS#11 interception driver is used to capture the signature call and obtain the hash value of the data to be signed, and match it with the authorized credential cache. If the match is successful and the data is within the validity period, the corresponding credential is destroyed in one go, and the logical key identifier key_id is converted into a physical encryption machine key handle. The encryption machine cluster is then called through the physical encryption machine adaptation module to perform the signature. If the match fails, the request is blocked. The physical encryption machine adaptation module is used to convert the logical key_id into a physical encryption machine key handle, and call the encryption machine to perform signing through the physical PKCS#11 interface.

13. The system for protecting the key security of Chang'an Chain nodes by combining an encryption machine according to claim 11, characterized in that, The system also includes a certificate and identity service component for maintaining the mapping relationship between node certificates, Distributed Identity Identifier (DID) documents, and organizational roles. The DID document records the public key information and service endpoints of the node identity. A two-way binding is established between the node certificate and the DID document through public key fingerprints, and the public key reference in the DID document is updated synchronously when the certificate is updated or rotated.

14. The system for implementing secure protection of Chang'an Chain node keys by combining an encryption machine according to claim 11, characterized in that, The system also includes an operation and maintenance authorization component, which provides multi-user authorization and multi-factor authentication control for key rotation, key revocation and emergency switching operations, and writes the authorization events into the audit log, which is then anchored to the blockchain by the audit anchoring component.

15. A device for securing the key of a Chang'an Chain node by combining an encryption machine, 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 securing the key of a Chang'an Chain node in conjunction with an encryption machine as described in any one of claims 1 to 10.

16. A processor that combines an encryption machine to achieve secure protection of the key of a Chang'an Chain node, 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 securing the key of a Chang'an Chain node in conjunction with an encryption machine as described in any one of claims 1 to 10.

17. 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 securing the key of a Chang'an Chain node in conjunction with an encryption machine, as described in any one of claims 1 to 10.

Images