Trusted DHT network protocol architecture based on TEE authentication

Abstract

The invention discloses a trusted DHT network protocol architecture based on TEE authentication. A TEE authentication module is responsible for initializing a TEE environment, generating an identity certificate of a node, executing remote certification and verifying an authentication report of the node; the trusted routing management module maintains a trust weighted K-Buck structure, manages a connection relationship between nodes, and dynamically adjusts a routing strategy according to a trust score; the trust evaluation module collects node behavior data, calculates and updates trust scores of the nodes, and realizes a time attenuation mechanism of trust; the security protocol execution module realizes node addition, searching, storage and retrieval of a core protocol, and a TEE authentication and trust evaluation mechanism is integrated in each link; the defense mechanism module is used for realizing a defense algorithm aiming at specific security threats of the Sybil attack and the Eclipse attack; and the performance optimization module manages the authentication cache, executes hierarchical query optimization and adaptive parameter adjustment, and improves the system performance.

Description

Technical Field

[0001] This invention relates to the fields of distributed systems, network security, and trusted computing technologies, specifically to a trusted DHT network protocol architecture based on TEE certification, applicable to scenarios requiring high security and high trust, such as distributed storage, data exchange, and blockchain. Background Technology

[0002] Distributed Hash Tables (DHTs), as a decentralized distributed storage and routing protocol, have been widely used in various distributed systems. However, traditional DHT protocols face significant security challenges, including: 1) Sybil attacks: Malicious nodes can generate a large number of fake identities, undermining the trust foundation of the network; 2) Eclipse attacks: Attackers can isolate the routing table of a target node, preventing it from communicating only with malicious nodes and thus preventing it from establishing connections with other legitimate nodes; 3) Storage pollution: Malicious nodes store incorrect or malicious data, affecting data integrity and availability; 4) Route poisoning: Nodes return false routing information, interfering with normal data lookup and transmission. Existing DHT protocols such as Kademlia and Chord lack effective authentication mechanisms and trust models, failing to fundamentally solve these security problems. While some improvements attempt to introduce reputation systems or cryptographic mechanisms, these methods either cannot resist hardware-level attacks or significantly degrade system performance, making it difficult to achieve a balance between security and efficiency. Summary of the Invention

[0003] The purpose of this invention is to provide a trusted DHT network protocol architecture based on TEE authentication. By integrating the remote authentication mechanism of TEE and designing a novel DHT algorithm (T-Kademlia), it solves a series of security problems existing in traditional DHT networks, ensuring both high security and maintaining the efficiency of distributed systems.

[0004] To achieve the above objectives, the technical solution of the present invention is as follows: the trusted DHT network protocol architecture includes:

[0005] The TEE authentication module is responsible for initializing the TEE environment, generating node identity credentials, performing remote authentication, and verifying node authentication reports.

[0006] The trusted routing management module maintains a trust-weighted K-Bucket structure, manages the connection relationships between nodes, and dynamically adjusts routing policies based on trust scores.

[0007] The trust assessment module collects node behavior data, calculates and updates the node's trust score, and implements a trust decay mechanism over time.

[0008] The security protocol execution module implements the core protocols for node joining, searching, storing, and retrieving, and incorporates TEE authentication and trust assessment mechanisms at each stage;

[0009] The defense mechanism module implements defense algorithms against specific security threats such as Sybil attacks and Eclipse attacks;

[0010] The performance optimization module manages authentication caching, optimizes tiered queries, and adaptively adjusts parameters to improve system performance.

[0011] The steps for multiple nodes to be authenticated by the TEE authentication module before joining the DHT network are as follows:

[0012] S1. During initialization, multiple nodes generate asymmetric key pairs SK and PK within the TEE environment; and make the private key SK visible only within the TEE authentication module; generate a remote authentication report, which includes TEE instance information and the public key PK;

[0013] The S2 and TEE authentication modules send the remote authentication report to IntelIAS for authentication services and obtain the IAS signature; the compute node ID = H(PK||Attestation||Genesis_Hash), where Genesis_Hash is the network genesis parameter;

[0014] S3, Trust Establishment Phase: Send a join request to the bootstrapping node. The request includes the node ID, network endpoint information, remote authentication report, timestamp, and message digest signed with SK.

[0015] The bootstrap node verifies the received information by: verifying the validity of the IAS signature; checking if the MRENCLAVE value is in the pre-configured whitelist; verifying if the TCB version meets security requirements; checking if the timestamp is within the allowed time window to prevent replay attacks; and verifying if the message signature matches the public key PK.

[0016] If the verification is successful, the bootstrap node returns the initial neighbor list, network configuration parameters, and trusted anchor list;

[0017] S4. During the route table construction phase, a node lookup operation is performed to find other nodes with similar node IDs; asynchronous authentication is performed on each returned node to verify its authenticity; the returned nodes are sorted and inserted into the corresponding K-Bucket; a periodic refresh task is started to ensure the freshness and accuracy of the route table.

[0018] S5. Announce your presence to neighboring nodes, including the node ID, endpoint information, and authentication digest; request to be added to the routing table of the neighboring node; establish heartbeat connections with nodes with higher trust scores and maintain active monitoring.

[0019] As an improvement to the above technical solution, the step of multiple nodes being authenticated by the TEE authentication module further includes a data storage phase, and the steps of the data storage phase are as follows:

[0020] S6. Replica node selection, perform a node lookup operation to find the node responsible for storing the data, requiring the trust score of the node to be not less than 70; select the top replication high-trust nodes from the returned nodes as storage targets; if the number of trustworthy nodes is insufficient, increase the number of replicas to compensate for potential storage risks;

[0021] S7. Data encapsulation, construct a data packet, including a key, a value, a timestamp, a digest signed with the publisher's private key, and a storage proof (including publisher authentication information and the required trust level);

[0022] S8. Distribution and verification, send a STORE_REQUEST message containing the data packet to each target node; the target node verifies the received information: verify the authentication validity of the publisher; check whether the key is within its own responsibility scope; verify the integrity of the data; store the sensitive data part in the TEE; the target node returns a STORE_ACK message, including an operation success flag, a storage receipt (a hash digest of the key and value signed with the node's private key), and a storage proof (proving that the data is stored in the TEE);

[0023] S9. Confirmation and monitoring, count the number of successfully responded nodes stored_count; if stored_count < replication, select additional nodes for retry; record the storage mapping: key -> [stored node, storage credentials] for subsequent retrieval and verification.

[0024] As an improvement to the above technical solution, the step of multiple nodes being authenticated by the TEE authentication module further includes a data retrieval process, and the steps of the data retrieval process are as follows:

[0025] S10. Locate the storage node, perform a node lookup operation to find the nodes that may store the data, requiring the trust score of the nodes to be not less than 60;

[0026] S11. Parallel query, send RETRIEVE_REQUEST messages to multiple storage nodes in parallel, requesting to obtain the data corresponding to the key; the storage node responds with a RETRIEVE_RESPONSE message, including the value, the timestamp, the original publisher's signature, the TEE storage proof, and the access log commitment; the retrieval node verifies the received information: verify whether the hash of the value matches the key; verify the signature of the original publisher; verify the TEE storage proof; check whether the timestamp is reasonable; collect valid responses, record the sending node, the returned value, the proof, and the trust score.

[0027] S12. Consensus and selection: Group the responses according to the returned values; b. Calculate the trust weight of each group: consensus_weight=Σ(trust_score_i); Select the group with the highest trust weight as the final result; If the weight is lower than the threshold, trigger the VERIFY_STORAGE operation to further verify the authenticity of the data.

[0028] S13. Cache and routing table update: For nodes that respond successfully, their trust score is appropriately increased; for nodes that fail or return inconsistent data, their trust score is appropriately decreased; return the final result, which includes the data value, confidence level, and proof chain.

[0029] As an improvement to the above technical solution, the trust-weighted K-Bucket structure includes node ID, node network address, trust score, authentication timestamp, authentication level, and performance indicators; the distance range is [2^i, 2^(i+1)); and the dynamic capacity strategy is adaptive_k(trust_distribution).

[0030] The distance range is defined based on the XOR distance between node IDs and is used for grouping and managing K-Buckets. This range indicates that if the XOR distance between the current node and other nodes falls within this interval, these nodes will be classified into the i-th K-Bucket. Furthermore, XOR distance is a commonly used method for calculating node ID distance in DHT networks. It is obtained by performing a bitwise XOR operation on two node IDs; the smaller the result, the closer the nodes are.

[0031] As an improvement to the above technical solution, the adaptive capacity algorithm for dynamic capacity takes the following steps:

[0032] The algorithm takes a K-Bucket as input parameter and first sets the basic capacity value to 20.

[0033] The algorithm then calculates the average trust score of all nodes in the bucket and divides it by 100 to obtain the trust multiplier.

[0034] Next, the actual capacity value is calculated, where the trust multiplier is used as an adjustment factor and is proportional to the node trust level;

[0035] Finally, to ensure system stability, the algorithm limits the calculation results to a reasonable range and returns the smaller of the actual capacity value and the maximum capacity limit.

[0036] As an improvement to the above technical solution, the trust establishment phase is based on a multi-dimensional trust scoring model, where the multi-dimensional score TrustScore = α·A + β·R + γ·U + δ·P.

[0037] in:

[0038] A (Attestation) represents the certification strength score.

[0039] =level_weight[L0:0,L1:20,L2:30,L3:40]×freshness_factor(time_since_attestation);

[0040] R (Reputation) represents historical behavior reputation.

[0041] =success_rate×response_quality×(1-malicious_reports);

[0042] U(Uptime) is the availability score = online_time / total_time × stability_factor;

[0043] P(Performance) is the performance score = 1 / avg_latency × bandwidth_score;

[0044] The weights are configured as follows: α=0.5, β=0.25, γ=0.15, δ=0.1;

[0045] The time decay function is freshness_factor(t) = exp(-λ·t);

[0046] λ can be L1: 0.001 (24-hour half-life); or L2: 0.0005 (48-hour half-life); or L3: 0.0002 (120-hour half-life, continuously certified).

[0047] As an improvement to the above technical solution, the node search algorithm steps are:

[0048] The α nearest local nodes (trust score ≥ minimum trust value) are used as the candidate node set, the candidate short list = priority queue (sorted by distance value), and the searched node set = ∅;

[0049] Perform parallel iterative queries when |candidate node set| > 0 and the query has not converged:

[0050] a. Select β nearest candidate nodes that have not been queried, and the selected node = top_β(candidate node set - searched node set, sorted by: distance value × trust score);

[0051] b. Send node search requests in parallel: FIND_NODE_REQUEST{target node ID, minimum trust value};

[0052] c. For each response Response{nodes[], remote attestation}:

[0053] Verify the authentication chain of the response nodes, for each node in nodes[]:

[0054] Verify whether the attestation is fresh (t < threshold), verify the validity of the IAS signature, calculate the trust score, and if the trust score < the minimum trust value, discard it;

[0055] Update the candidate node set and the candidate shortlist; mark the nodes in the searched node set as searched;

[0056] Convergence detection, if the candidate shortlist.top_α remains unchanged for k consecutive rounds, then break out of the loop;

[0057] The final node set = candidate shortlist.top_α, perform real-time authentication verification (if the cache has expired) for each node in the final node set, and update the local routing table;

[0058] Return the final node set (sorted by distance value).

[0059] As an improvement to the above technical solution, the steps of the data storage algorithm are:

[0060] Set the target node set = T-Kademlia_FIND_NODE(key, minimum trust value = 70), select the top replication high-trust nodes, and if the number of trusted nodes is insufficient, increase the number of replicas for compensation;

[0061] Encapsulate the data, including the data key, data value, storage timestamp, and the trust level required for publisher authentication;

[0062] For each target node in the target node set, send STORE_REQUEST{data packet}, then perform node verification, verify the authentication validity of the publisher, check whether the key is within its own responsibility scope, verify the data integrity, and store sensitive data in the TEE;

[0063] The node returns to prove that the data is in the TEE.

[0064] As an improvement to the above technical solution, the steps of the Sybil attack defense are:

[0065] Set the initial trust score of the new node = 20, and prohibit the new node from quickly obtaining key positions;

[0066] Identity cost mechanism, each node ID must be bound to a unique TEE instance, the TEE instance requires hardware support (physical scarcity), and perform periodic re-authentication (time cost);

[0067] Identity entropy detection checks the entropy distribution of node IDs for each new node. If the entropy of the node-th node is less than the threshold, the suspicious score is increased by 20.

[0068] Check the network joining mode. If the joining speed is more than twice the normal speed, the suspicious score increases by 30.

[0069] Check behavioral pattern similarity. Similar node set = find similar behaviors (new nodes). If the number of nodes in the similar node set > k, the suspicious score increases by 40.

[0070] Check the geographic / network topology. If the number of identical subnets is greater than the threshold, the suspicion score increases by 10. If the suspicion score is greater than 70, isolate and observe (reduce trust score and restrict interaction).

[0071] As an improvement to the above technical solution, the steps of Eclipse attack defense are: for each K-Bucket,

[0072] Group the nodes in the K-Bucket by geographical location, and force a minimum number of regions ≥ 3;

[0073] Group the nodes in K-Bucket by certification authority, and force the number of nodes in the certification authority set to be ≥2;

[0074] Iterate through the addition time of nodes in the K-Bucket to obtain a list of addition times, and force the standard deviation of the addition time list to be greater than the threshold;

[0075] Regularly perform route table integrity verification via anchor points, rebuild the route table if pollution is detected, and perform multi-path query verification.

[0076] Each refresh retains high-trust nodes, explores new neighbors (to prevent stagnation), cross-verifies neighbor information, and the refresh interval is dynamically adjusted based on network status.

[0077] As an improvement to the above technical solution, the execution process of the continuous authentication protocol is as follows:

[0078] Layered authentication scheduling: For each node in the routing table, calculate the next authentication time. The next authentication time = the previous authentication time + the authentication period (authentication level). The authentication period is (L1) = 24 hours or (L2) = 48 hours or (L3) = 168 hours (but there is real-time monitoring).

[0079] Priority queue scheduling adds nodes to the authentication queue according to their priority, where priority = (trust score × importance weight) / time since last authentication.

[0080] Incremental authentication (reducing overhead): If the node's authentication level is L3, lightweight authentication is used: Quote signature verification, TCB update check, and behavior consistency verification; otherwise, complete re-authentication is performed.

[0081] Anomaly-triggered authentication, triggering conditions: trust score suddenly drops by more than 20%, response anomaly rate is more than 10%, neighboring nodes report suspicious behavior, network partition recovery is detected, and full authentication is immediately performed;

[0082] The authentication result is propagated. If authentication fails, a revocation notice is broadcast for that node, along with a detailed reason for the failure. All nodes then remove that node from their routing tables.

[0083] As an improvement to the above technical solution, the steps of Byzantine fault-tolerant retrieval are:

[0084] Redundant query, required number of responses = 2f + 1, query node set = find the node with more data key and take the first (required number of responses × 1.5);

[0085] Parallel query collection, response list = parallel query(query node set, data key);

[0086] Response verification and grouping: Initialize the list of verified responses. For each response in the response list: If the response passes both authentication and signature verification: Add the response to the list of verified responses. Data value grouping: Group the list of verified responses by data value.

[0087] Byzantine consensus, for each data value group: group weight = Σ(response.trust score), number of groups = number of responses in the group, winning group = the maximum weight (data value group); if the number of winning groups < 2f+1: consensus failure is returned;

[0088] Malicious node identification: The majority data value equals the winning group's data value. For each response in the verified response list: if the response's data value ≠ the majority data value: mark the node in this response as suspicious and reduce the node's trust score (deduct 15 penalty points).

[0089] The technical solution of this invention solves the security problem of traditional DHT networks in the following ways:

[0090] 1. The node identity system bound to TEE hardware significantly increases the cost of generating false identities, effectively resisting Sybil attacks. Theoretical analysis shows that when an attacker controls m real TEE instances and the total number of network nodes is n, the probability of influencing critical operations is P≤(m / n)^t (t is the minimum number of trusted nodes required).

[0091] 2. Through the trust-weighted routing table and the routing table diversity guarantee mechanism, the credibility and diversity of routing information are ensured. Analysis shows that when the size of the K-Bucket is k, the minimum diversity requirement is d, and the proportion of attacker nodes is β, the probability P of a successful Eclipse attack satisfies P ≤ β^(k / d).

[0092] 3. By storing sensitive data in the TEE and the multi-node storage verification mechanism, the integrity and authenticity of data are guaranteed. In the Byzantine fault-tolerant retrieval algorithm, if the number of Byzantine nodes f < n / 3, the probability P of retrieving the correct data satisfies P > 1 - ε (ε is related to the authentication failure rate).

[0093] 4. Through the continuous authentication and abnormal behavior detection mechanism, real-time monitoring of node status and dynamic trust assessment are achieved, ensuring the continuous security of the network.

[0094] 5. At the same time, through optimization strategies such as authentication caching, hierarchical query, and adaptive parameter adjustment, the present invention effectively balances security and performance, enabling the system to maintain the high efficiency characteristics of a distributed system while providing high security guarantees.

[0095] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0096] 1. Security improvement: Through the hardware-level security guarantee of the TEE, traditional security threats common in DHT networks such as Sybil attacks and Eclipse attacks can be effectively resisted. Experimental data show that compared with traditional Kademlia, the success rate of the present invention in the Sybil attack scenario is reduced by 99.9%, and the defense success rate against Eclipse attacks is increased to over 99.5%.

[0097] 2. Identity credibility: A node identity system based on the TEE is established to ensure that node identities cannot be forged, providing a complete trust chain from hardware to software.

[0098] 3. Data integrity guarantee: Through multi-signature, data sharding, and Byzantine fault-tolerant mechanisms, data tampering and storage pollution are effectively prevented, and the data integrity reaches 99.999%.

[0099] 4. Performance optimization: Optimization strategies such as authentication caching and hierarchical query are introduced. While ensuring security, the query latency only increases by 5% - 15%, far better than similar security enhancement solutions.

[0100] 5. Strong scalability: Compatible with existing DHT network protocols, it can be gradually deployed and upgraded, supporting the access of a large number of nodes.

[0101] High flexibility: Supports node identity authentication with different security levels and can dynamically adjust security policies according to application scenarios.

[0102] 6. Wide range of applications: It can be applied to multiple fields such as distributed storage, blockchain, and the Internet of Things, and is especially suitable for distributed systems that require high security. Attached Figure Description

[0103] 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 some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0104] Figure 1 This is a schematic diagram of a trusted DHT network protocol architecture based on TEE authentication.

[0105] Figure 2 A schematic diagram of the node identity system and authentication process;

[0106] Figure 3 This is a schematic diagram of the trusted routing table structure and maintenance process;

[0107] Figure 4 This is a schematic diagram of the Byzantine fault-tolerant retrieval algorithm.

[0108] Figure 5 This is a schematic diagram of the core module architecture of the system of the present invention. Detailed Implementation

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

[0110] Specifically, such as Figure 1-5 As shown, the trusted DHT network protocol architecture based on TEE authentication proposed in this invention deeply integrates Trusted Execution Environment (TEE) technology with Distributed Hash Table (DHT) protocol to build a distributed trusted network based on hardware root trust. This network can provide functions such as node authentication, secure routing, data storage and retrieval, while effectively resisting various security attacks and ensuring data integrity and privacy.

[0111] The computer program of this invention mainly includes the following core modules:

[0112] TEE Authentication Module: Responsible for initializing the TEE environment, generating node identity credentials, performing remote authentication, and verifying authentication reports from other nodes.

[0113] Trusted routing management module: Maintains a trust-weighted K-Bucket structure, manages the connection relationships between nodes, and dynamically adjusts routing policies based on trust scores.

[0114] Trust assessment module: Collects node behavior data, calculates and updates node trust scores, and implements a trust decay mechanism over time.

[0115] Security Protocol Execution Module: Implements core protocols such as node joining, searching, storage, and retrieval, and incorporates TEE authentication and trust assessment mechanisms at each stage.

[0116] Defense Mechanism Module: Implements defense algorithms against specific security threats such as Sybil attacks and Eclipse attacks.

[0117] Performance optimization module: manages authentication caching, optimizes tiered queries, and adjusts adaptive parameters to improve system performance.

[0118] Data security module: responsible for secure operations such as encrypted storage, integrity verification, and fragmented transmission of data.

[0119] The following details each step of the process, including node addition, data storage, and retrieval:

[0120] a) Node joining process:

[0121] Step 1: TEE Initialization Phase

[0122] a. Generate an asymmetric key pair (SK, PK) within the TEE environment, where the private key SK is only visible within the TEE.

[0123] b. Generate a remote authentication report Report=SGX_CreateReport(), which includes TEE instance information and public key PK.

[0124] c. Send the report to an authentication service such as IntelIAS to obtain a signature: Attestation = IAS_Verify(Report).

[0125] d. Compute node ID = H(PK||Attestation||Genesis_Hash), where Genesis_Hash is the network genesis parameter.

[0126] Step 2: Trust Building Phase

[0127] a. Send a JOIN_REQUEST message to the bootstrap node, which includes the node_id, network endpoint information, authentication report, timestamp, and message digest signed with SK.

[0128] b. The bootstrap node verifies the received information: verifies the validity of the IAS signature; checks if the MRENCLAVE value is in the pre-configured whitelist; verifies if the TCB version meets security requirements; checks if the timestamp is within the allowed time window to prevent replay attacks; and verifies if the message signature matches the public key PK.

[0129] c. If the verification is successful, the bootstrapping node returns the initial neighbor list (containing only authenticated nodes), network configuration parameters, and a list of trusted anchors.

[0130] Step 3: Routing Table Construction Phase

[0131] a. Execute the FIND_NODE(self.node_id) operation to find other nodes with a node ID close to its own.

[0132] b. Perform asynchronous authentication on each returned node to verify its identity.

[0133] c. Sort the nodes according to their trust scores and insert them into the corresponding K-Buckets.

[0134] d. Start a periodic refresh task to ensure the freshness and accuracy of the routing table.

[0135] Step 4: Announcement Phase

[0136] a. Broadcast its presence to neighboring nodes, including the node ID, endpoint information, and authentication digest.

[0137] b. Request to be added to the other party's routing table.

[0138] c. Establish heartbeat connections with nodes that have high trust scores and maintain active monitoring.

[0139] b) Data storage process:

[0140] Step 1: Selecting a replica node:

[0141] a. Execute the FIND_NODE(key, minimum trust value=70) operation to find the node responsible for storing the data, requiring the node's trust score to be no less than 70.

[0142] b. Select the top 10 highly trusted nodes from the returned nodes as storage targets.

[0143] c. If there are not enough trusted nodes, increase the number of replicas to compensate for potential storage risks.

[0144] Step 2: Data Encapsulation

[0145] a. Construct a data packet that includes a key, a value, a timestamp, a digest signed with the publisher's private key, and a storage proof (including publisher authentication information and the required trust level).

[0146] Step 3: Distribution and Verification:

[0147] a. Send a STORE_REQUEST message containing the data packet to each target node.

[0148] b. The target node verifies the received information: verify the authentication validity of the publisher; check if the key is within its own responsibility scope; verify the data integrity; store the sensitive data part within the TEE.

[0149] c. The target node returns a STORE_ACK message containing an operation success flag, a storage receipt (a hash digest of the key and value signed with the node's private key), and a storage proof (proving that the data is stored within the TEE).

[0150] Step 4: Confirmation and Monitoring

[0151] a. Count the number of nodes with successful responses, stored_count.

[0152] b. If stored_count < replication, select additional nodes for retry.

[0153] c. Record the storage mapping: key -> [stored nodes, storage credentials] for subsequent retrieval and verification.

[0154] c) Data retrieval process:

[0155] Step 1: Locate the storage node:

[0156] a. Execute the FIND_NODE(key, minimum trust value = 60) operation to find nodes that may store the data, requiring the trust score of the nodes to be not less than 60.

[0157] Step 2: Parallel query:

[0158] a. Send RETRIEVE_REQUEST messages to multiple storage nodes in parallel, requesting the data corresponding to the key.

[0159] b. The storage node responds with a RETRIEVE_RESPONSE message containing the value, timestamp, original publisher signature, TEE storage proof, and access log commitment.

[0160] c. The retrieval node verifies the received information: verify if the hash of the value matches the key; verify the original publisher's signature; verify the TEE storage proof; check if the timestamp is reasonable.

[0161] d. Collect valid responses and record the sending node, return value, proof, and trust score.

[0162] Step 3: Consensus and Choice

[0163] a. Group the responses according to the returned values.

[0164] b. Calculate the trust weight for each group = Σ(trust_score_i), and sum the trust scores of the nodes in a group.

[0165] c. Select the group with the highest trust weight as the final result.

[0166] d. If the weight is below the threshold, the VERIFY_STORAGE operation is triggered to further verify the authenticity of the data.

[0167] Step 4: Cache and routing table update:

[0168] a. For nodes that successfully respond, their trust score will be appropriately increased.

[0169] b. Nodes that fail or return inconsistent data will have their trust score appropriately reduced.

[0170] c. Return the final result, including the data value, confidence level, and proof chain.

[0171] The software flowchart of this invention mainly includes node addition process, data storage process, and data retrieval process, etc. The connection between these processes and the physical process is mainly reflected in the following aspects:

[0172] During the node joining process, steps such as TEE initialization and remote authentication rely on the TEE function of the physical hardware to ensure the physical unforgeability of the node's identity.

[0173] In the data storage and retrieval process, sensitive data is processed and stored in a physically isolated TEE environment, ensuring data security at the physical level.

[0174] The performance metrics and availability parameters in the trust scoring model directly reflect the physical operating status of nodes and the network environment.

[0175] Geographic dispersion checks and network topology analysis in security defense mechanisms are closely related to the actual physical topology and geographical distribution of the network.

[0176] By tightly integrating software processes with physical processes, this invention achieves end-to-end protection from software protocols to hardware security, ensuring the overall security and reliability of distributed networks.

[0177] Based on the embodiments of the present invention, any modifications, equivalent substitutions, improvements, etc., made by all other embodiments obtained by those skilled in the art without creative effort should be included within the protection scope of the present invention.

Claims

1. A trusted DHT network protocol architecture based on TEE authentication, characterized in that: The trusted DHT network protocol architecture comprises: a TEE authentication module responsible for initializing a TEE environment, generating an identity certificate of a node, performing remote attestation, and verifying an authentication report of the node; a trusted routing management module maintaining a trust-weighted K-Bucket structure, managing connection relationships between nodes, and dynamically adjusting a routing strategy according to a trust score; a trust evaluation module collecting node behavior data, calculating and updating a trust score of the node, and implementing a time decay mechanism of trust; a security protocol execution module implementing core protocols of node joining, searching, storing, and retrieving, and integrating TEE authentication and trust evaluation mechanisms at each link; a defense mechanism module implementing defense algorithms against specific security threats such as Sybil attacks and Eclipse attacks; a performance optimization module managing authentication cache, performing hierarchical query optimization, and adjusting adaptive parameters to improve system performance; Before joining the DHT network, the plurality of nodes are authenticated through the steps of the TEE authentication module: S1, in the initialization, the plurality of nodes generate an asymmetric key pair SK, PK in the TEE environment; and make the private key SK only visible in the TEE authentication module; generate a remote authentication report, the remote authentication report comprising TEE instance information and the public key PK; S2, the TEE authentication module sends the remote authentication report to IntelIAS for authentication service, and obtains an IAS signature; calculates a node ID = H(PK||Attestation||Genesis_Hash), wherein Genesis_Hash is a network genesis parameter; S3, in the trust establishment stage, a joining request information is sent to a guide node, the request information comprising a node ID, network endpoint information, a remote authentication report Report, a timestamp, and a message digest signed by SK; The guide node verifies the received information: verifies the validity of the IAS signature; checks whether the MRENCLAVE value is in the preconfigured whitelist; verifies whether the TCB version meets the security requirements; checks whether the timestamp is within the allowed time window to prevent replay attacks; and verifies whether the message signature matches the public key PK; If the verification is passed, the guide node returns an initial neighbor list, network configuration parameters, and a trust anchor list; S4, in the routing table construction stage, a node search operation is performed to find other nodes close to the node ID; asynchronous authentication is performed on each returned node to verify the authenticity of the identity; the returned nodes are sorted and inserted into the corresponding K-Bucket; and a regular refresh task is started to ensure the freshness and accuracy of the routing table; S5, announcement, broadcast the existence of oneself to the neighboring nodes, including the node ID, endpoint information, and authentication digest; request to join the routing table of the other party; and establish a heartbeat connection with nodes with a higher trust score to maintain an active state monitoring.

2. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of authenticating the plurality of nodes through the TEE authentication module further comprise a data storage stage, and the steps of the data storage stage are: S6, replica node selection, performing node lookup operation to find nodes responsible for storing the data, requiring the trust score of the nodes to be no less than 70; selecting the first replication high-trust nodes from the returned nodes as storage targets; if there are not enough trusted nodes, increasing the number of replicas to compensate for potential storage risks; S7, data packaging, building a data packet containing key, value, timestamp, digest signed with publisher private key, and storage proof; S8, distribution and verification, sending a STORE_REQUEST message to each target node containing the data packet; the target node verifies the received information: verifying the validity of the publisher's authentication; checking whether the key is within its own responsibility range; verifying the integrity of the data; Storing the sensitive data part in the TEE; The target node returns a STORE_ACK message containing a successful operation flag, a storage receipt, and a storage proof; S9, confirmation and monitoring, counting the number of successful response nodes stored_count; if stored_count < replication, selecting additional nodes for retry; recording the storage mapping: key -> [stored nodes, storage credentials] for subsequent retrieval and verification. 3.The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of the data retrieval process of the TEE authentication module authentication of multiple nodes further include: S10, locating the storage node, performing a node lookup operation to find nodes that may store the data, requiring the trust score of the nodes to be no less than 60; S11, parallel query, sending a RETRIEVE_REQUEST message to multiple storage nodes in parallel to request the data corresponding to the key; the storage node responds with a RETRIEVE_RESPONSE message containing the value, timestamp, original publisher signature, TEE storage proof, and access log commitment; the retrieval node verification process receives the information: verifying whether the hash of the value matches the key; verifying the original publisher's signature; verifying the TEE storage proof; checking whether the timestamp is reasonable; collecting valid responses, recording the sending node, returned value, proof, and trust score; S12, consensus and selection, grouping responses by returned values; b. Calculate the trust weight of each group: consensus_weight = Σ(trust_score_i); select the group with the highest trust weight as the final result; if the weight is lower than the threshold, trigger the VERIFY_STORAGE operation to further verify the authenticity of the data; S13, cache and routing table update, the trust score of the successful response nodes is appropriately increased; the trust score of the failed or inconsistent data returning nodes is appropriately decreased; Returning the final result containing the data value, confidence, and proof chain.

4. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The trust-weighted K-Bucket structure includes node ID, node network address, trust score, authentication timestamp, authentication level, and performance indicators; the distance range is [2^i, 2^(i+1)); the dynamic capacity strategy is adaptive_k; the adaptive capacity algorithm steps of the dynamic capacity are as follows: The algorithm receives a K-Bucket as an input parameter, first sets the basic capacity value to 20; Then, the algorithm calculates the average trust score of all nodes in the bucket and divides it by 100 to get the trust multiplier; Next, the actual capacity value is calculated, where the trust multiplier is used as an adjustment factor, proportional to the node trust degree; Finally, to ensure system stability, the algorithm limits the calculation result within a reasonable range and returns the smaller value between the actual capacity value and the upper limit of the maximum capacity.

5. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The trust establishment phase is based on a multi-dimensional trust scoring model, and the multi-dimensional score = a A + β R + γ U + δ P; Where: A is the authentication strength score = level_weight [L0:0, L1:20, L2:30, L3:40] x freshness_factor; R is the historical behavior reputation = success_rate x response_quality x (1-malicious_reports); U is the availability score = online_time / total_time x stability_factor; P is the performance score = 1 / avg_latency x bandwidth_score; The weight configuration is: a = 0.5, β = 0.25, γ = 0.15, δ = 0.1; The time decay function freshness_factor(t) = exp(-λ·t); λ is L1:0.001; or L2:0.0005; or L3:0.0002.

6. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of the node search algorithm are: Select a candidate node set of a recent local nodes, candidate shortlist = priority queue, where the priority queue is sorted by distance value, and the searched node set = ∅; Parallel iterative query is performed when |candidate node set|>0 and not converged: Select β recent candidate nodes that have not been queried, selected nodes = top_β; Send the request FIND_NODE_REQUEST{target node ID, minimum trust value} in parallel; For each response Response{nodes[], remote proof}: Verify the authentication chain of the response node, for each node in nodes[]: Verify if the attestation is fresh, verify the validity of the IAS signature, calculate the trust score, and if the trust score < minimum trust value, discard; Update the candidate node set and the candidate shortlist; mark the searched node set as searched; Convergence detection, if candidate shortlist.top_α does not change for k consecutive rounds, exit the loop; Final node set = candidate shortlist.top_α, for each node in the final node set, perform real-time authentication verification and update the local routing table; Return the final node set sorted by distance value.

7. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of the data storage algorithm are: Target node set = T-Kademlia_FIND_NODE(key, minimum trust value = 70), select the top replication high-trust nodes, and if there are not enough trusted nodes, increase the number of replicas to compensate; Data encapsulation, including data key, data value, storage timestamp, required trust level for publisher authentication, etc. For each target node in the target node set, send a data packet, then perform node verification, verify the validity of the publisher's authentication, check if the key is within its own responsibility range, verify data integrity, and store sensitive data in TEE; The node returns to prove that the data is in the TEE.

8. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of the witch attack defense are: Initial trust of new nodes = 20, and prohibit new nodes from quickly obtaining key positions; Identity cost mechanism, each node ID must be bound to a unique TEE instance, which requires hardware support and regular re-authentication; Identity entropy detection, check the node ID entropy distribution for each new node, if the entropy of the node_id node is < threshold, the suspicious score increases by 20; Check the network joining mode, if the joining rate > 2 times the normal rate, the suspicious score increases by 30; Check the behavior pattern similarity, similar node set = find similar behavior (new node), if the number of nodes in the similar node set > k, the suspicious score increases by 40; Check the geography / network topology, if the number of the same subnets > threshold, the suspicious score increases by 10, if the suspicious score > 70: isolate observation to reduce trust score, limit interaction.

9. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The steps of Eclipse attack defense are: for each K-Bucket, Group the nodes in the K-Bucket by geographic location, and force the minimum number of regions to be ≥ 3; Group the nodes in the K-Bucket by certification authority, and force the number of nodes in the certification authority set to be ≥ 2; Traverse the joining time of the nodes in the K-Bucket to obtain a joining time list, and force the standard deviation of the joining time list to be > threshold; Periodically perform route table integrity verification through anchor points, rebuild if route table pollution is found, and verify through multi-path query; Keep high-trust nodes during each refresh, explore new neighbors to prevent solidification, cross-verify neighbor information, and dynamically adjust the refresh interval according to network status.

10. The trusted DHT network protocol architecture based on TEE authentication according to claim 1, characterized in that: The process of continuous authentication protocol execution is: Hierarchical authentication scheduling, for each node in the routing table: calculate the next authentication time, next authentication time = last authentication time + authentication period (authentication level), authentication period is L1 = 24 hours or L2 = 48 hours or L3 = 168 hours; Priority queue scheduling, add nodes to the authentication queue according to priority, priority = (trust score × importance weight) / time since last authentication; Incremental authentication (reduce overhead), if the authentication level of a node is L3, use lightweight authentication: Quote signature verification, TCB update check, behavior consistency verification, otherwise perform complete re-authentication; Abnormal trigger authentication, trigger conditions: trust score suddenly drops by > 20%, response abnormal rate > 10%, neighbor nodes report suspicious behavior, detect network partition recovery, immediately perform complete authentication; Authentication result propagation, if authentication fails, broadcast the node revocation notice with detailed failure reason, and remove the node from the routing table by all nodes; The steps of Byzantine fault tolerance retrieval are: Redundant query, required response count = 2f + 1, query node set = more data key lookup nodes, and take the first, required response count x 1.5; Parallel query collection, response list = parallel query, including query node set, data key; Response verification and grouping, initialize verified response list, for each response in response list: if response passes both verification authentication and verification signature: add response to verified response list, data value grouping = group verified response list by data value; Byzantine consensus, for each data value grouping: grouping weight = Σ(response.trust score), grouping quantity = number of responses in grouping, winning group = max by weight; if winning group quantity < 2f + 1: return consensus failure; Malicious node identification, majority data value = winning group data value, for each response in verified response list: if response data value ≠ majority data value: mark node in this response as suspicious, reduce trust score of node in this response by 15 penalty value.

Images