Quantum-resistant hierarchical wallet key derivation method and system compatible with hierarchical path semantics

Abstract

The application relates to the technical field of key management, and particularly discloses a quantum-resistant hierarchical wallet key derivation method and system compatible with hierarchical path semantics, which comprises the following steps: generating root seeds based on multiple random sources, establishing seed time numbers for each root seed, and generating root commitments; taking the seed time number and the root commitment as the root identifier of the current derivation request, encoding complete hierarchical path information carried by the current derivation request into a fixed-length standard path code; calculating a domain context digest; generating a target path seed based on the current hierarchical parent seed, the standard path code and the domain context digest; converting the target path seed into a quantum-resistant signature key pair containing a child private key and a child public key, and calculating a child public key digest; and generating a path ownership proof record using the root commitment, a path commitment, the child public key digest and a derivation proof label. The application reduces the cross-use key association and reuse risk while retaining the hierarchical path management semantics.

Description

Technical Field

[0001] This invention relates to the field of key management technology, and more specifically to a quantum-resistant hierarchical wallet key derivation method and system compatible with hierarchical path semantics. Background Technology

[0002] With the rapid development of quantum computing technology, it poses a fundamental challenge to the key management system of traditional wallets. Shor's algorithm can solve the elliptic curve discrete logarithm problem in polynomial time, rendering the BIP32 derivation relationship built on elliptic curves such as secp256k1 completely invalid. Not only can the private key of an existing address be recovered, but more seriously, attackers can use the homomorphic property of elliptic curve scalar addition to reverse deduce the algebraic relationship between the parent public key and the child private key, thereby threatening the confidentiality of the entire derivation tree. Furthermore, the hierarchical derivation logic of traditional BIP32 cannot be directly transferred to a quantum-resistant signature key system.

[0003] Existing solutions suffer from the following problems: 1) Traditional layered deterministic wallets typically rely on elliptic curve scalar relationships, making direct migration to quantum-resistant signature keys with different structures impossible. 2) Simply inputting path indices into ordinary key derivation functions easily overlooks the isolation of chains, assets, roles, and security domains, leading to cross-purpose key reuse risks. 3) Existing recovery solutions mostly recover complete mnemonic phrases, complete private keys, and account ownership, but cannot provide verifiable recovery for single branches. 4) There is a lack of mechanisms to prove that a sub-public key belongs to a specified derivation path without revealing the root seed. 5) After the root seed is rotated, there is a lack of verifiable continuous management between the old address, unspent assets, and new derived branches. 6) Branch freezing, recovery authorization, and derivation events typically rely on centralized logs, making it difficult to provide non-repudiable long-term audit evidence.

[0004] Therefore, how to construct a new framework that preserves the semantics of hierarchical path management without relying on traditional elliptic curve derivation relations is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention proposes a quantum-resistant hierarchical wallet key derivation method and system compatible with hierarchical path semantics, so as to overcome the above problems or at least partially solve the above problems.

[0006] To achieve the above objectives, the present invention adopts the following technical solution:

[0007] In a first aspect, the present invention provides a quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics, comprising the following steps: S1. Collect multiple random sources, generate root seeds after health detection and mixed extraction, assign a seed number to each root seed when establishing the seed, and generate a root commitment; S2. Using the seed time number and root commitment as the root identifier of this derivation request, encode the complete hierarchical path information carried by this derivation request into a fixed-length canonical path code. S3. Encode the wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation pattern into a fixed-length field separation context, and calculate the field context digest; S4. Within the protected environment, based on the current level parent seed, the canonical path code, and the domain context summary, deterministically generate child node seeds, and pass the currently generated child node seeds as the parent seeds of the next level of derivation until the target path seed is generated. S5. Convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and calculate the sub-public key digest; S6. Generate a path ownership proof record using the root commitment, path commitment, sub-public key digest, and derived proof label.

[0008] Furthermore, S1 includes: S101. Using hardware random numbers, operating system security random numbers, device noise, and user operation timing as random sources, extract random blocks from each random source, perform health checks on the random blocks, and input the random blocks that pass the checks into the extended output function after normalization according to the source number and collection time to obtain a root seed of fixed length. The normalization method for the random blocks that pass the test is as follows: the source number, collection time, random block collection sequence number, random block length, random block summary and health test results are encoded in a fixed field order, and then sorted by source number and collection sequence number. S102. Process the root seed digest label, seed timecode, and root seed using a secure hash function to obtain the root seed digest; process the root commitment label, wallet instance identifier, seed timecode, public perturbation value, and root seed digest using a secure hash function to obtain the root commitment.

[0009] Furthermore, S2 includes: S201. Receive the complete hierarchical path information carried in this derivation request, including the destination, chain identifier, asset type, account, role, change flag, and address index, as the set of path fields to be encoded; S202. Perform multiple validations on each field in the set of fields to be encoded. The validation process includes: checking whether each path field is missing, confirming whether the value of each field is within the predefined legal range, and verifying whether the order of each field meets the hierarchical specification. S203. If any check fails, reject the current derivative request and record the reason for the failure. S204. After all verifications pass, the set of path fields to be encoded is encoded into a fixed-length canonical path code carrying a length marker and field labels in a fixed field order, and the seed time number and root commitment are used as the context header of this derived request.

[0010] Furthermore, S3 includes: S301. Receive multi-dimensional semantic fields related to this derivation request, including: wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation mode; S302. Perform multiple validations on each field. The validation methods include: checking for missing fields, checking for registered chain identifiers, and checking for matching roles and security domains. If any validation fails, the validation fails, the current derivation request is rejected, and the reason for failure is recorded. S303. After all validations pass, the field names, field lengths, and field values ​​are encoded in a fixed order to obtain the domain separation context. S304. Perform one-way computation on the domain separation context to obtain the domain context summary.

[0011] Furthermore, in S4, the child node derivation label, the current level parent seed, the current canonical path code, the domain context summary, the seed time code, and the node level number are input into the extended output function to obtain the child node seed of the current level; if the canonical path code is missing or the domain context summary is inconsistent with the business domain, the derivation request is rejected and the reason for failure is recorded.

[0012] Furthermore, S5 includes: S501. Using the target path seed, parent key material digest, domain context digest, and algorithm version as key generation inputs to the extended output function, generate a private key random material of the required length; wherein, the parent key material digest is calculated based on the parent path seed of the layer above the target path; S502. Input the random material of the private key into the quantum-resistant signature algorithm to generate a sub-private key and a sub-public key; wherein, the sub-private key is the quantum-resistant signature private key corresponding to the target business path, and the sub-public key is the signature verification public key corresponding to the sub-private key; S503. Perform a one-way digest calculation on the algorithm version, sub-public key length, and sub-public key content to obtain the sub-public key digest; keep the sub-private key in a protected environment, and transmit the sub-public key and sub-public key digest to S6 for proof registration.

[0013] Furthermore, it also includes: S7. Freeze and restore the specified path, specifically including: S701. Determine the path prefix of the specified path and all its subsequent child nodes as the frozen branch, and set the state machine of the frozen branch to the frozen state, prohibiting the frozen branch from performing seed derivation and key generation operations. S702. Dynamically calculate the recovery threshold based on the total number of participants, asset risk level, and compliance role requirements; S703. When the recovery threshold is reached, a recovery event number and a recovery domain context are generated. The recovery event number is generated by a secure hash function using the wallet instance identifier, old path commitment, trigger time, approval record digest, and event sequence number. The recovery domain context is generated by a secure hash function using the recovery event number, old path commitment, recovery strategy number, participant set digest, and recovery threshold. S704. Backtrack towards the root direction to locate the unaffected parent seed. The unaffected parent seed is the nearest parent path seed that does not belong to the frozen branch, is not marked as risk, and has proven the chain to be valid. Call the extended output function, taking the branch recovery label, the unaffected parent seed, the recovery event number, the recovery domain context, and the new path code as input, to deterministically derive the new branch seed. S705. Establish a mapping record from old path commitments to new path commitments. The mapping record includes the old path commitment, the new path commitment, the recovery event number, the approval record summary, and the signatures of the recovery participants.

[0014] Furthermore, it also includes: S8. Establish a rotation proof for old and new seeds, specifically including: S801: Receive the rotation instruction, determine the set of unused paths to be migrated, and generate a new root seed and its corresponding new root commitment; S802. Input the old root commitment, new root commitment, migration path commitment set, overlap window start and end heights, and rotation event number into a secure hash function to generate a rotation label. Sign the rotation label using the old root control path private key and the new root control path private key respectively to form a rotation proof. The old root control path private key is a quantum-resistant signature private key obtained by the deterministic derivation process of the preset rotation control path under the old root according to S4-S5. The new root control path private key is a quantum-resistant signature private key obtained by the deterministic derivation process of the preset rotation control path under the new root according to S4-S5. S803. Write the rotation proof into the trusted ledger, use the block height of the block written into the trusted ledger as the starting height of the overlapping window, and use the starting height of the overlapping window plus the preset confirmation height as the ending height, and enter the overlapping window where the old and new roots coexist; within the overlapping window, the old root only allows signature verification operations and restricted expenditure operations for historical addresses, and prohibits new path derivation, while the new root takes over all new path derivation and signature permissions. S804. When the overlapping window reaches the end height, revoke all derivation permissions of the old root, and the new root becomes the only valid root.

[0015] Furthermore, it also includes: S9. When freeze, recovery, or rotation events occur, change the corresponding branch status and form an audit record. Integrate the derivation, freeze, recovery, and rotation events into structured transactions and record them on the blockchain in real time to form an immutable long-term audit trail record.

[0016] Secondly, the present invention provides a quantum-resistant hierarchical wallet key derivation system compatible with hierarchical path semantics, which employs the quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described above, including: The root seed module is used to collect multiple random sources, generate root seeds after health detection and mixed extraction, number each root seed when establishing the seed, and generate root commitments; The path encoding module is used to encode the complete hierarchical path information carried in this derivation request into a fixed-length canonical path code, using the seed time number and root commitment as the root identifier of this derivation request. The domain separation context generation module is used to encode wallet instances, path prefixes, chain identifiers, asset types, roles, security domains, and derivation patterns into fixed-length domain separation contexts and to calculate domain context digests. The seed derivation module is used to deterministically generate child node seeds within a protected environment based on the current level parent seed, canonical path encoding, and domain context summary. The currently generated child node seed is then passed down level by level as the parent seed for the next level of derivation until the target path seed is generated. The quantum-resistant computing module is used to convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and to compute the sub-public key digest; The parent-child relationship proof module is used to generate path ownership proof records using root commitment, path commitment, child public key digest, and derived proof label.

[0017] As can be seen from the above technical solution, compared with the prior art, the present invention has the following beneficial effects: 1. This invention first generates a root seed and a root commitment, then encodes each level of path and its business context into a domain separation context, uses a quantum-safe key derivation function to generate a sub-seed, and then calls a quantum-safe key generation algorithm to generate a sub-key pair. It can simultaneously generate a derived proof digest, enabling verifiers to verify the binding relationship between the sub-public key and the path and the root commitment, reducing the risk of cross-purpose key association and reuse.

[0018] 2. This invention significantly improves the entropy quality and anti-predictability of the root key by collecting multiple random sources and extracting them through health detection and normalization. Even if a single random source deteriorates, it does not affect the overall security.

[0019] 3. This invention introduces a domain separation context to cryptographically isolate derived inputs of the same path index in different business scenarios. Even if the path numbers are the same or there is an inclusion relationship, as long as any business context is different, the derived key materials are mathematically completely unrelated, effectively resisting cross-chain, cross-asset, and cross-role key reuse and clustering analysis attacks.

[0020] 4. This invention supports setting a frozen state for any specified path prefix and all its subsequent child nodes. Once frozen, the branch is immediately prohibited from performing any seed derivation and signature generation operations, retaining only the signature verification capability of historical addresses. This mechanism achieves fine-grained and immediate blocking of key permissions without affecting the normal operation of other branches of the wallet, effectively addressing scenarios involving violations in specific business lines, isolation of risky accounts, or temporary compliance control.

[0021] 5. After a branch is frozen, this invention activates the recovery process through a multi-party recovery share threshold approval mechanism. It introduces an unaffected parent seed backtracking strategy and a recovery domain context isolation construction, ensuring that the recovery operation only utilizes the healthy parent seed upstream of the frozen branch to derive a completely new branch and establishes a mapping from the old path commitment to the new path commitment. The entire recovery process does not expose or involve any private material from other unauthorized branches, achieving a unified approach of targeted rebirth of damaged branches and global security isolation.

[0022] 6. This invention integrates all governance events such as derivation, freezing, recovery, and rotation into structured transactions, and records them on the blockchain in real time, forming a closed-loop, tamper-proof, and traceable audit evidence chain, providing a solid foundation for secure evidence collection and anomaly backtracking after the fact. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0024] Figure 1 A flowchart of one embodiment of the quantum-resistant hierarchical wallet key derivation method with compatible hierarchical path semantics provided by the present invention; Figure 2 A flowchart in another embodiment of the quantum-resistant hierarchical wallet key derivation method with compatible hierarchical path semantics provided by the present invention; Figure 3 This is a structural framework diagram of a quantum-resistant hierarchical wallet key derivation system that is compatible with hierarchical path semantics, as provided in an embodiment of the present invention. Detailed Implementation

[0025] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] like Figure 1 As shown, this embodiment of the invention discloses a quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics, comprising the following steps: S1. Collect multiple random sources, generate root seeds after health detection and mixed extraction, assign a seed number to each root seed when establishing the seed, and generate a root commitment; S2. Using the seed time number and root commitment as the root identifier of this derivation request, encode the complete hierarchical path information carried by this derivation request into a fixed-length canonical path code. S3. Encode the wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation pattern into a fixed-length field separation context, and calculate the field context digest; S4. Within the protected environment, based on the current level parent seed, the canonical path code, and the domain context summary, deterministically generate child node seeds, and pass the currently generated child node seeds as the parent seeds of the next level of derivation until the target path seed is generated. S5. Convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and calculate the sub-public key digest; S6. Generate a path ownership proof record using the root commitment, path commitment, sub-public key digest, and derived proof label.

[0027] The following is a further explanation of the specific implementation process of each of the above steps.

[0028] S1. Collect multiple random sources, perform health checks and mixed extraction to generate root seeds, assign a number to each root seed when creating the seed, and generate a root commitment that does not reveal the root seed. The root commitment is used to bind subsequent derivation proofs, rotation relationships, and restoration authorization. Specifically, this includes: S101. Using hardware random numbers, operating system security random numbers, device noise, and user operation timing as random sources, extract random blocks from each random source and perform health checks on the random blocks; the health checks include three categories: duplicate value detection, proportional deviation detection, and consecutive failure count detection. The duplicate value detection process is as follows: the current random block is compared bit by bit with the previous random block. If the number of consecutive identical data blocks reaches a preset threshold, the duplicate value detection of the current random block is deemed to have failed; otherwise, it is deemed to have passed. The proportional deviation detection process is as follows: taking the current random block as the center, count the number of occurrences of bit 0 and bit 1 in all random blocks within a sliding window of a fixed length. If the proportion of bit 1 exceeds the preset upper and lower limits, the proportional deviation detection of the current random block is determined to be unsuccessful; otherwise, it is determined to be successful. The random block is considered valid for extraction only if it passes both of the above instantaneous content checks; if either check fails, the random block is considered invalid for extraction.

[0029] The continuous failure counting detection process is as follows: An independent failure counter is maintained for each random source. This counter is used to track continuous anomalies of that random source over time. The specific update rules are as follows: If the current random block is deemed valid for extraction, the failure counter corresponding to the random source is reset to zero, and the source is restored to a healthy state. If the current random block is deemed invalid for extraction, the failure counter corresponding to the random source is incremented. After each counter update, the failure counter value of the random source is checked. If it reaches or exceeds the preset isolation threshold, the random source is determined to be an untrusted source and is immediately isolated. All random blocks subsequently generated by this random source will no longer participate in normalized mixed extraction until the administrator intervenes manually or the source passes external health verification.

[0030] The random blocks that pass the test are normalized according to their source number and collection time and then input into the extended output function to obtain a root seed of fixed length. In this embodiment, the extended output function outputs a 64-byte root seed. The normalization method for the random blocks that pass the test is as follows: the source number, collection time, random block collection sequence number, random block length, random block summary and health test result are encoded in a fixed field order and then sorted according to the source number and collection sequence number.

[0031] The extended output function (XOF) is used to generate output data of a specified length based on the input data. The extended output function can be SHAKE128, SHAKE256, cSHAKE128, cSHAKE256, KMAC, TupleHash, ParallelHash, or other cryptographic functions capable of outputting data of a specified length.

[0032] S102. Process the root seed digest label, seed timecode, and root seed using a secure hash function to obtain the root seed digest; process the root commitment label, wallet instance identifier, seed timecode, public perturbation value, and root seed digest using a secure hash function to obtain the root commitment. Both the root seed digest and root commitment are one-way computation results. The public perturbation value is stored with the root commitment and is not kept confidential.

[0033] The secure hash function in this embodiment is an existing cryptographic hash algorithm used to compress an input of arbitrary length into a fixed-length digest; specifically, it can be implemented using existing algorithms such as SHA-256, SHA3-256, and SM3.

[0034] S2. Using the seed time number and root commitment as the root identifier of this derivation request, the complete hierarchical path information carried by this derivation request is used. The path adopts a hierarchical wallet readable form, but the internal encoding is a fixed-length canonical path encoding.

[0035] A hierarchical path is an ordered path within a wallet from the root node to the target account node and address node. It is used to preserve the hierarchical semantics between the custodian organization, chain, assets, account roles, and address indexes. A hierarchical wallet is a wallet instance that deterministically generates multiple child node keys according to this ordered path. Externally readable paths are only used to identify business levels, while internal derivation is based on canonical data encoded with length markers and field tags.

[0036] Specifically, it includes: S201. Receive the complete hierarchical path information carried in this derivation request, including the destination, chain identifier, asset type, account, role, change flag, and address index, as the set of path fields to be encoded; S202. Perform multiple validations on each field in the set of fields to be encoded. The validation process includes: checking whether each path field is missing, confirming whether the value of each field is within the predefined legal range, and verifying whether the order of each field meets the hierarchical specification. S203. If any check fails, reject the current derivative request and record the reason for the failure. S204. After all verifications pass, the set of path fields to be encoded is encoded into a fixed-length canonical path code carrying a length marker and field labels in a fixed field order, and the seed time number and root commitment are used as the context header of this derived request.

[0037] S3. Encode the wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation pattern into a fixed-length field separation context, and calculate the field context digest.

[0038] Here, a wallet instance represents a custodian tenant and a collection of wallets; a path prefix indicates a parent path that needs to be frozen, restored, or rotated; a chain identifier represents the target blockchain network; an asset type represents the category of native assets, contract assets, and custodian assets; a role represents purposes such as operation, auditing, aggregation, and cold backup; a security domain represents hot wallets, warm wallets, cold wallets, and hardware protection zones; and a derivation pattern represents normal derivation, hardened derivation, and restored derivation. The domain separation module encodes field names, field lengths, and field values ​​in a fixed order and then calculates the domain context digest; for the same address index, the digest will be different if the purpose, chain, asset, and role are different, and the subsequent seed input will also be different, thus preventing cross-purpose associations.

[0039] This step specifically includes: S301. Receive multi-dimensional semantic fields related to this derivation request, including wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation mode; S302. Perform multiple validations on each field. The validation methods include: checking for missing fields, checking for registered chain identifiers, and checking for matching roles and security domains. If any validation fails, the validation fails, the current derivation request is rejected, and the reason for failure is recorded. S303. After all validations pass, the field names, field lengths, and field values ​​are encoded in a fixed order to obtain the domain separation context. S304. Perform a one-way computation on the domain separation context to obtain the domain context digest. The domain context digest is obtained by using a secure hash function based on the wallet instance, chain identifier, asset type, role, security domain, derivation mode, and algorithm version.

[0040] S4. Within the protected environment, based on the current-level parent seed, canonical path encoding, and domain context digest, deterministically generate child node seeds. Considering that ordinary derivation exposes necessary public path information, this embodiment adopts hard derivation, using parent secret material available only within the protected environment.

[0041] In the specific derivation process, the previous level seed is used as the secret input, and the current path node encoding, domain context digest, seed time code, and node level number are used as the public constraint input. The 64-byte child node seed is obtained by expanding the output function. Each level of derivation uses the output of the previous level as the input of the next level until the target path seed is obtained. The target path seed is not publicly disclosed.

[0042] In the specific calculation, the child node derivation label, the current level parent seed, the current canonical path code, the domain context summary, the seed time code, and the node level number are input into the extended output function to obtain the child node seed of the current level. If the canonical path code is missing or the domain context summary is inconsistent with the business domain, the derivation request is rejected and the reason for failure is recorded.

[0043] S5. Calculation of quantum-resistant signature key pairs: Quantum-resistant signature key pairs are obtained through a deterministic key generation process driven by the target path seed. The key generation process first expands the private key random material required by the algorithm, and then calculates the corresponding sub-public key and sub-public key digest. Specifically, this includes: S501. Take the target path seed, parent key material digest, domain context digest and algorithm version as key generation inputs to the extended output function to generate private key random material of the required length. The parent key material digest is calculated based on the parent path seed of the layer above the target path. The specific generation process is as follows: The process derives from the root seed level by level along the hierarchical path. Before obtaining the target path seed, it is necessary to first obtain the parent path seed of the previous level. Based on this parent path seed, the parent signature private key and parent signature public key are generated according to the deterministic quantum-resistant signature key generation process. Specifically, the parent path seed, parent path commitment, domain context digest, and algorithm version are first input into a variable-length output key derivation function to generate random material for the parent signature private key. Then, the random material for the parent signature private key is input into a specified quantum-resistant signature algorithm to obtain the parent signature private key and parent signature public key. Next, the parent signing public key, parent signing public key digest, parent path commitment, parent algorithm version, parent key identifier, and parent domain context digest are encoded in a fixed field order and input into a secure hash function to obtain the parent key material digest.

[0044] S502. Input the random material of the private key into the quantum-resistant signature algorithm to generate a sub-private key and a sub-public key; wherein, the sub-private key is the quantum-resistant signature private key corresponding to the target business path, and the sub-public key is the signature verification public key corresponding to the sub-private key; the quantum-resistant signature algorithm can be ML-DSA or SLH-DSA.

[0045] S503. Perform a one-way digest calculation on the algorithm version, sub-public key length, and sub-public key content to obtain the sub-public key digest; keep the sub-private key in a protected environment, and transmit the sub-public key and sub-public key digest to S6 for proof registration.

[0046] S6. Generate a path ownership proof record using the root commitment, path commitment, sub-public key digest, and derived proof label. The proof is implemented using signatures, commitment proofs, and zero-knowledge proofs.

[0047] Specifically, the path commitment is calculated from the canonical path code and the domain context digest; the sub-public key digest is calculated one-way from the sub-public key; and the derived proof label is calculated jointly from the root commitment, path commitment, sub-public key digest, algorithm version, and seed timecode. The canonical path code is generated in a fixed order based on the wallet instance, path prefix, chain identifier, asset type, role, security domain, and address index, with each field carrying length information. The path commitment is generated by a secure hash function processing the path commitment label, canonical path code, domain context digest, seed timecode, and algorithm version.

[0048] The parent signature private key is the signature private key obtained from the parent path seed through a deterministic quantum-resistant key generation process. It is used to sign the derived proof tag only within a protected environment. The verifier uses the parent signature public key to verify the signature.

[0049] In this step, a path ownership proof is generated using a root commitment, a path commitment, a child public key digest, and a derived proof label, and the child public key digest is registered. Without exposing the root seed and the parent signing private key, a third party is allowed to verify the binding relationship between the child public key and the specified derived path and root commitment. The goal of third-party verification is to confirm that the publicly disclosed child public key is indeed bound to the specified root commitment and the specified path, and has not been replaced by other path public keys or other root seed public keys. The verifier receives the root commitment, path commitment, child public key digest, derived proof label, parent signing public key, and parent signature, recalculates each digest, and verifies the signature. After successful verification, only the ownership relationship is confirmed; the root seed, parent signing private key, and child private key are not obtained.

[0050] In other embodiments, such as Figure 2 As shown, the method of the present invention further includes: S7. Freeze the specified path prefix to prevent further signature derivation; after the recovery threshold is met, generate a new recovery seed branch mapping for this branch without exposing other branches, specifically including: S701. The path prefix of the specified path and all its subsequent child nodes are identified as frozen branches, and the state machine of the frozen branches is set to the frozen state, prohibiting the frozen branches from performing seed derivation and key generation operations; wherein, the specified path is jointly determined by the wallet instance, path prefix, chain identifier, asset type, role and address index in the business request; S702. Dynamically calculate the recovery threshold based on the total number of participants, asset risk level, and compliance role requirements. The recovery threshold represents the minimum number of effective recovery shares required to allow branch recovery, and is determined based on the total number of participants, asset risk level, and compliance role requirements. For example, when the total number of participants is 5, the recovery threshold is 3; when the total number of participants in a high-risk branch is 7, the recovery threshold is 5. S703. When the recovery threshold is reached, a recovery event number and a recovery domain context are generated. The recovery event number is generated by a secure hash function using the wallet instance identifier, old path commitment, trigger time, approval record digest, and event sequence number. The recovery domain context is generated by a secure hash function using the recovery event number, old path commitment, recovery strategy number, participant set digest, and recovery threshold. S704. Backtrack towards the root direction to locate the unaffected parent seed, and derive a new branch seed using the unaffected parent seed and the recovery event number; wherein, the unaffected parent seed is the nearest parent path seed that does not belong to the frozen branch, is not marked with risk, and has proven the chain to be valid; call the extended output function, and deterministically derive a new branch seed with the branch recovery label, the unaffected parent seed, the recovery event number, the recovery domain context, and the new path code as input; S705. Establish a mapping record from old path commitments to new path commitments. The mapping record includes the old path commitment, the new path commitment, the recovery event number, the approval record summary, and the signatures of the recovery participants.

[0051] In other embodiments, the method of the present invention further includes: S8. Establish a rotation certificate for the old and new seeds, migrate unused paths to the new root, and retain the old address's signature-only and restricted spending capabilities. Revoke the old root's derivation permissions after the rotation is complete. Specifically, this includes: S801: Receive the rotation instruction, determine the set of unused paths to be migrated, and generate a new root seed and its corresponding new root commitment; S802. Input the old root commitment, new root commitment, migration path commitment set, overlap window start and end height, and rotation event number into a secure hash function to generate a rotation label. Sign the rotation label using the old root control path private key and the new root control path private key respectively to form a rotation proof. The overlap window is a transition interval where the old root and the new root are simultaneously valid. The old root control path private key is a quantum-resistant signature private key obtained from the preset rotation control path under the old root according to the deterministic derivation process of S4-S5. The new root control path private key is a quantum-resistant signature private key obtained from the preset rotation control path under the new root according to the deterministic derivation process of S4-S5. This is not a sub-private key of a normal business path and cannot be directly signed using the root seed.

[0052] The quantum-resistant signature private key in this step and the sub-private key in S5 belong to the same key type. Both are signature private keys obtained from a deterministic quantum-resistant signature key generation process using a specified path seed, but they are not the same key instance. The sub-private key in S5 corresponds to the target business path and is used for sub-key registration and subsequent business signing of the target path. The old root control path private key and the new root control path private key in S802 correspond to the preset rotation control paths under the old root and the new root, and are only used to sign the rotation tag to prove that the old root control right and the new root control right jointly confirm the rotation. Therefore, the control path private key is a dedicated sub-private key derived from the rotation control path. It belongs to the quantum-resistant signature private key, but it is different from the sub-private key of the ordinary business path.

[0053] S803. Write the rotation proof into the trusted ledger, use the block height of the block written into the trusted ledger as the starting height of the overlapping window, and use the starting height of the overlapping window plus the preset confirmation height as the ending height, and enter the overlapping window where the old and new roots coexist; within the overlapping window, the old root only allows signature verification operations and restricted expenditure operations for historical addresses, and prohibits new path derivation, while the new root takes over all new path derivation and signature permissions. S804. When the overlapping window reaches the end height, revoke all derivation permissions of the old root, and the new root becomes the only valid root.

[0054] More advantageously, the method of the present invention further includes: S9. When freeze, recovery, or rotation events occur, change the corresponding branch status and form an audit record. Integrate the derivation, freeze, recovery, and rotation events into structured transactions and record them on the blockchain in real time to form an immutable long-term audit trail record.

[0055] The state machine includes states such as pending derivation, encoded, derived, registered, frozen, recovering, recovered, rotating, and revoked. Upon receiving a valid derivation request, it enters the encoded state; upon successful seed derivation and key self-check, it enters the derived state; upon successful proof writing, it enters the registered state; upon receiving a freeze instruction, it enters the frozen state; upon reaching the recovery share threshold, it enters the recovering state and generates a new branch; upon completion of proof rotation, it enters the rotating state; and upon the end of the overlapping window, it enters the revoked state.

[0056] like Figure 3 As shown, this embodiment of the invention also provides a quantum-resistant hierarchical wallet key derivation system compatible with hierarchical path semantics, which employs the quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described above, including: The root seed module is used to collect multiple random sources, generate root seeds after health detection and mixed extraction, number each root seed when establishing the seed, and generate root commitments; The path encoding module is used to encode the complete hierarchical path information carried in this derivation request into a fixed-length canonical path code, using the seed time number and root commitment as the root identifier of this derivation request. The domain separation context generation module is used to encode wallet instances, path prefixes, chain identifiers, asset types, roles, security domains, and derivation patterns into fixed-length domain separation contexts and to calculate domain context digests. The seed derivation module is used to deterministically generate child node seeds within a protected environment based on the current level parent seed, canonical path encoding, and domain context summary. The currently generated child node seed is then passed down level by level as the parent seed for the next level of derivation until the target path seed is generated. The quantum-resistant computing module is used to convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and to compute the sub-public key digest; The parent-child relationship proof module is used to generate path ownership proof records using root commitment, path commitment, child public key digest, and derived proof label.

[0057] The system also includes a branch freeze and restore module, a root seed rotation module, and an audit module; wherein, the branch freeze and restore module is configured to execute steps S701-S705, the root seed rotation module is configured to execute steps S801-S804, and the audit module is configured to execute step S9.

[0058] The specific application implementation conditions of the system of this invention are as follows: In the custodial wallet embodiment, the path can be encoded as destination, chain, asset, account, role, change, and index; the recovery threshold can be set as the proportion of the total number of participants; and the rotation overlap window can be set according to the block confirmation time and asset risk. In the implementation conditions, the wallet instance is set as custodial platform 1, the chain is identified as the main business chain and the backup business chain, the security domain is divided into hot wallet domain, cold wallet domain and recovery domain, the total number of recovery participants is 5, the recovery threshold is 3, and the rotation overlap window is 7200 block confirmations.

[0059] Example 1: Derivation of a multi-chain custodial wallet.

[0060] The system assigns different chain identifiers to the main business chain and the backup business chain, and sets different roles for the operation account, audit account, and aggregation account. Even if the address index is the same, the generated derived seeds and quantum-resistant key pairs are isolated from each other due to the different chain identifiers. For example, the stablecoin operation account on the main business chain of the same custody platform uses address index 5, and the stablecoin operation account on the backup business chain also uses address index 5; because the chain identifier enters the domain context digest, the child node seeds, public keys, and public key digests obtained by the two paths are all different. Auditors can confirm that the two belong to the corresponding chains through path commitments and child public key digests.

[0061] Example 2: Specifying branch freezing and restoration.

[0062] When a device branch is suspected of being compromised, the system freezes the corresponding path prefix, prohibiting subsequent address derivation and signing. Once the recovery participants reach a threshold, the branch is mapped to a new recovery path, and a recovery proof from the old branch to the new branch is generated. For example, if the device branch corresponds to address indices 0 to 99 under the cold wallet domain, the system freezes the path prefix and rejects new address derivation and signing requests. When 3 out of 5 recovery participants submit valid recovery shares, the system generates a recovery event number, derives a new branch seed, and maps the old path commitment to the new path commitment.

[0063] Example 3: Root seed rotation.

[0064] When the system creates a new seed, it allows old addresses to complete restricted asset migrations within a window, but prohibits old roots from continuing to derive. After the window ends, old roots are only used for historical verification. For example, after a new root is established, the system generates a rotation label and sets an overlap window of 7200 block confirmations; within the window, old addresses can only complete registered restricted migration transactions, and new addresses continue to derive from the new root. After the window ends, the derivation status of the old root changes to "revoked".

[0065] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0066] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics, characterized in that, Includes the following steps: S1. Collect multiple random sources, generate root seeds after health detection and mixed extraction, assign a seed number to each root seed when establishing the seed, and generate a root commitment; S2. Using the seed time number and root commitment as the root identifier of this derivation request, encode the complete hierarchical path information carried by this derivation request into a fixed-length canonical path code. S3. Encode the wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation pattern into a fixed-length field separation context, and calculate the field context digest; S4. Within the protected environment, based on the current level parent seed, the canonical path code, and the domain context summary, deterministically generate child node seeds, and pass the currently generated child node seeds as the parent seeds of the next level of derivation until the target path seed is generated. S5. Convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and calculate the sub-public key digest; S6. Generate a path ownership proof record using the root commitment, path commitment, sub-public key digest, and derived proof label.

2. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, S1 includes: S101. Using hardware random numbers, operating system security random numbers, device noise, and user operation timing as random sources, extract random blocks from each random source, perform health checks on the random blocks, and input the random blocks that pass the checks into the extended output function after normalization according to the source number and collection time to obtain a root seed of fixed length. The normalization method for the random blocks that pass the test is as follows: the source number, collection time, random block collection sequence number, random block length, random block summary and health test results are encoded in a fixed field order, and then sorted by source number and collection sequence number. S102. Process the root seed digest label, seed timecode, and root seed using a secure hash function to obtain the root seed digest; process the root commitment label, wallet instance identifier, seed timecode, public perturbation value, and root seed digest using a secure hash function to obtain the root commitment.

3. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, S2 include: S201. Receive the complete hierarchical path information carried in this derivation request, including the destination, chain identifier, asset type, account, role, change flag, and address index, as the set of path fields to be encoded; S202. Perform multiple validations on each field in the set of fields to be encoded. The validation process includes: checking whether each path field is missing, confirming whether the value of each field is within the predefined legal range, and verifying whether the order of each field meets the hierarchical specification. S203. If any check fails, reject the current derivative request and record the reason for the failure. S204. After all verifications pass, the set of path fields to be encoded is encoded into a fixed-length canonical path code carrying a length marker and field labels in a fixed field order, and the seed time number and root commitment are used as the context header of this derived request.

4. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, S3 includes: S301. Receive multi-dimensional semantic fields related to this derivation request, including: wallet instance, path prefix, chain identifier, asset type, role, security domain, and derivation mode; S302. Perform multiple validations on each field. The validation methods include: checking for missing fields, checking for registered chain identifiers, and checking for matching roles and security domains. If any validation fails, the validation fails, the current derivation request is rejected, and the reason for failure is recorded. S303. After all validations pass, the field names, field lengths, and field values ​​are encoded in a fixed order to obtain the domain separation context. S304. Perform one-way computation on the domain separation context to obtain the domain context summary.

5. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, In S4, the child node derivation label, the current level parent seed, the current canonical path code, the domain context summary, the seed time code, and the node level number are input into the extended output function to obtain the child node seed of the current level. If the canonical path code is missing or the domain context summary is inconsistent with the business domain, the derivation request is rejected and the reason for failure is recorded.

6. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, S5 include: S501. Using the target path seed, parent key material digest, domain context digest, and algorithm version as key generation inputs to the extended output function, generate a private key random material of the required length; wherein, the parent key material digest is calculated based on the parent path seed of the layer above the target path; S502. Input the random material of the private key into the quantum-resistant signature algorithm to generate a sub-private key and a sub-public key; wherein, the sub-private key is the quantum-resistant signature private key corresponding to the target business path, and the sub-public key is the signature verification public key corresponding to the sub-private key; S503. Perform a one-way digest calculation on the algorithm version, sub-public key length, and sub-public key content to obtain the sub-public key digest; keep the sub-private key in a protected environment, and transmit the sub-public key and sub-public key digest to S6 for proof registration.

7. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, Also includes: S7. Freeze and restore the specified path, specifically including: S701. Determine the path prefix of the specified path and all its subsequent child nodes as the frozen branch, and set the state machine of the frozen branch to the frozen state, prohibiting the frozen branch from performing seed derivation and key generation operations. S702. Dynamically calculate the recovery threshold based on the total number of participants, asset risk level, and compliance role requirements; S703. When the recovery threshold is reached, a recovery event number and a recovery domain context are generated. The recovery event number is generated by a secure hash function using the wallet instance identifier, old path commitment, trigger time, approval record digest, and event sequence number. The recovery domain context is generated by a secure hash function using the recovery event number, old path commitment, recovery strategy number, participant set digest, and recovery threshold. S704. Backtrack towards the root direction to locate the unaffected parent seed. The unaffected parent seed is the nearest parent path seed that does not belong to the frozen branch, is not marked as risk, and has proven the chain to be valid. Call the extended output function, taking the branch recovery label, the unaffected parent seed, the recovery event number, the recovery domain context, and the new path code as input, to deterministically derive the new branch seed. S705. Establish a mapping record from old path commitments to new path commitments. The mapping record includes the old path commitment, the new path commitment, the recovery event number, the approval record summary, and the signatures of the recovery participants.

8. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 7, characterized in that, Also includes: S8. Establish a rotation proof for old and new seeds, specifically including: S801: Receive the rotation instruction, determine the set of unused paths to be migrated, and generate a new root seed and its corresponding new root commitment; S802. Input the old root commitment, new root commitment, migration path commitment set, overlap window start and end heights, and rotation event number into a secure hash function to generate a rotation label. Sign the rotation label using the old root control path private key and the new root control path private key respectively to form a rotation proof. The old root control path private key is a quantum-resistant signature private key obtained by the deterministic derivation process of the preset rotation control path under the old root according to S4-S5. The new root control path private key is a quantum-resistant signature private key obtained by the deterministic derivation process of the preset rotation control path under the new root according to S4-S5. S803. Write the rotation proof into the trusted ledger, use the block height of the block written into the trusted ledger as the starting height of the overlapping window, and use the starting height of the overlapping window plus the preset confirmation height as the ending height, and enter the overlapping window where the old and new roots coexist; within the overlapping window, the old root only allows signature verification operations and restricted expenditure operations for historical addresses, and prohibits new path derivation, while the new root takes over all new path derivation and signature permissions. S804. When the overlapping window reaches the end height, revoke all derivation permissions of the old root, and the new root becomes the only valid root.

9. The quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in claim 1, characterized in that, Also includes: S9. When freeze, recovery, or rotation events occur, change the corresponding branch status and form an audit record. Integrate the derivation, freeze, recovery, and rotation events into structured transactions and record them on the blockchain in real time to form an immutable long-term audit trail record.

10. A quantum-resistant hierarchical wallet key derivation system compatible with hierarchical path semantics, characterized in that, It employs a quantum-resistant hierarchical wallet key derivation method compatible with hierarchical path semantics as described in any one of claims 1-9, comprising: The root seed module is used to collect multiple random sources, generate root seeds after health detection and mixed extraction, number each root seed when establishing the seed, and generate root commitments; The path encoding module is used to encode the complete hierarchical path information carried in this derivation request into a fixed-length canonical path code, using the seed time number and root commitment as the root identifier of this derivation request. The domain separation context generation module is used to encode wallet instances, path prefixes, chain identifiers, asset types, roles, security domains, and derivation patterns into fixed-length domain separation contexts and to calculate domain context digests. The seed derivation module is used to deterministically generate child node seeds within a protected environment based on the current level parent seed, canonical path encoding, and domain context summary. The currently generated child node seed is then passed down level by level as the parent seed for the next level of derivation until the target path seed is generated. The quantum-resistant computing module is used to convert the target path seed into a quantum-resistant signature key pair containing a sub-private key and a sub-public key, and to compute the sub-public key digest; The parent-child relationship proof module is used to generate path ownership proof records using root commitment, path commitment, child public key digest, and derived proof label.

Images