33.3.2 Web of Trust Systems

Web of Trust (WoT) systems pivot away from centralized authorities or isolated challenges to prove humanity. Instead, they model real-world social trust: your identity as a human is validated by other humans who already have established trust within the network. This creates a decentralized, graph-based reputation system where trust is transitive. For an AI, penetrating such a system isn’t about solving a puzzle; it’s about faking a social history and convincing real people to vouch for its manufactured persona.

From a red team perspective, these systems shift the attack surface from pure algorithm cracking to sophisticated social engineering and graph theory manipulation. You are no longer attacking a single point of failure but the very fabric of the trust relationships that hold the network together.

Core Architecture and Trust Propagation

Understanding the architecture is key to dismantling it. A WoT is fundamentally a directed graph where nodes are identities and edges are attestations of trust.

• Identity Nodes: Each node represents a unique entity, typically anchored to a cryptographic key pair (e.g., an Ethereum wallet address). The public key is the node’s identifier.
• Trust Edges (Attestations): A cryptographically signed statement from one node (the truster) vouching for another (the trustee). This edge can be binary (“I trust this person”) or weighted (“I trust this person with a confidence of 0.8”).
• Root of Trust: A set of initial, highly vetted “seed” nodes. The trustworthiness of any other node is ultimately calculated based on its distance and path quality to these roots. The compromise of a root node is a catastrophic event.
• Trust Algorithm: The engine that computes a “humanity” or “trust” score for any given node. This can range from simple shortest-path algorithms to more complex, Sybil-resistant methods like PageRank or EigenTrust.

Vulnerability Taxonomy and Red Team Plays

Your attack strategies must be tailored to the specific implementation of the WoT, but they generally fall into three categories.

1. Identity Proliferation (Sybil Attacks)

This is the classic attack against any decentralized reputation system. The goal is to create a disproportionate number of AI-controlled identities (Sybils) to gain influence, validate other malicious nodes, or execute a 51% attack on the system’s decision-making processes.

• Attack Vector: Sock Puppet Swarms. You generate thousands of key pairs and create a dense subgraph where they all vouch for each other. This “Sybil cluster” tries to appear legitimate through sheer volume of internal attestations. The goal is to get just one or two legitimate nodes to vouch for a member of your cluster, thereby bridging your manufactured trust into the real graph.
• Attack Vector: Trust Bribing and Airdrop Farming. You identify real users on the periphery of the trust graph and offer them a small financial incentive (e.g., cryptocurrency) to vouch for one of your Sybil nodes. This is highly effective in systems where the cost of attestation is low and the rewards for being “verified” are high.

2. Trust Graph Manipulation

Here, you don’t just add nodes; you actively exploit the graph’s structure and the algorithm used to calculate trust. This requires a deeper analysis of the system’s mechanics.

• Attack Vector: Eclipse Attacks. You aim to partition the graph. By controlling the network connections of a target node or group, you can isolate them from the main, honest graph and feed them a view where your malicious nodes appear highly trustworthy. This is more of a network-level attack but is devastatingly effective.
• Attack Vector: Centrality Poisoning. Identify nodes with high “betweenness centrality”—nodes that act as bridges between different communities. By compromising these few key nodes, you can disconnect large portions of the graph or inject your Sybil cluster with a high degree of apparent legitimacy, as they now have a short path to many other communities.

3. Root of Trust Compromise

This is the endgame. If you can compromise the initial seed nodes, the entire system’s integrity collapses. Trust becomes meaningless because its source is corrupted.

• Attack Vector: Targeted Social Engineering. The root nodes are often publicly known or discoverable. They become high-value targets for sophisticated phishing, pretexting, and other social engineering campaigns. The goal is to trick them into signing a trust attestation for a malicious node or, even better, to steal their private keys.
• Attack Vector: Legacy System Exploitation. The WoT may be built on other protocols. If a root user’s identity is linked to a less secure email or social media account for recovery, you attack that weaker link. Compromise the email, reset the WoT credentials, and take over the root node.

Red Teaming WoT Algorithms

Let’s examine a simplified trust propagation algorithm to see the weak points. This pseudocode calculates a node’s trust score based on the scores of those who vouch for it.

function calculate_trust_score(node, graph, depth=0):
    // Base case: Root nodes have a perfect score.
    if graph.is_root(node):
        return 1.0

    // Prevent infinite recursion in cyclic graphs.
    if depth > MAX_DEPTH:
        return 0.0

    total_weighted_score = 0.0
    total_weight = 0.0

    // Iterate over all nodes that vouch for the current node.
    for truster, attestation in graph.get_trusters(node):
        truster_score = calculate_trust_score(truster, graph, depth + 1)
        vouch_strength = attestation.weight // e.g., a value from 0.1 to 1.0
        
        // RED TEAM NOTE: The core logic. We need to manipulate this.
        // If vouch_strength isn't capped, we can use a compromised, high-score
        // node to give an absurdly high weight to our Sybil.
        weighted_score = truster_score * vouch_strength
        total_weighted_score += weighted_score
        total_weight += vouch_strength
    
    // RED TEAM NOTE: Division by total_weight can be a target.
    // If we can make total_weight zero or very small while the numerator
    // is non-zero, we could cause an error or score inflation.
    if total_weight == 0:
        return 0.0
    
    return total_weighted_score / total_weight

Your objective when analyzing this code is to find the mathematical edge cases. Can you create attestations with negative weights? Can you create cycles in the graph that the `MAX_DEPTH` check doesn’t handle properly? Can you find a high-scoring but careless node and convince it to sign an attestation with maximum weight for your target Sybil node, effectively “donating” its trust?

Defensive Posture and Mitigation Summary

Defending a WoT requires a multi-layered approach that combines algorithmic robustness, economic incentives, and human processes. Below is a summary of countermeasures mapped to the vulnerabilities we’ve discussed.