ICN Threat Model

Version: 1.2 Date: 2026-02-01 Status: Updated for Trust Score Timing Analysis Authors: Security Review Team

Executive Summary

This document provides a formal threat model for the InterCooperative Network (ICN) using the STRIDE framework. It identifies adversary classes, maps attack surfaces by system layer, analyzes threats for each component, and documents mitigations.

Security Posture Summary:

• 1134 tests covering security-critical paths
• Three-layer security architecture (Transport, Message, Application)
• 8 critical vulnerabilities fixed during production hardening
• Known gaps documented with priority rankings

Table of Contents

1. Adversary Classes
2. System Architecture Overview
3. Attack Surface by Layer
4. STRIDE Analysis by Component
5. Mitigations Reference
6. Gap Analysis
7. Security Assumptions
8. References

1. Adversary Classes

1.1 Outsider (Network Attacker)

Capabilities:

• No ICN identity (no DID)
• Can observe network traffic
• Can inject network packets
• Can perform DoS attacks at network level
• Cannot decrypt QUIC/TLS traffic

Goals:

• Disrupt service availability
• Intercept communications (fails due to TLS)
• Impersonate legitimate peers (fails due to DID-TLS binding)

Example Attacks:

• Connection flooding
• TCP/UDP amplification
• DNS hijacking of discovery endpoints

1.2 Malicious Peer (Byzantine Node)

Capabilities:

• Valid ICN identity (DID with keypair)
• Can establish authenticated connections
• Can participate in gossip protocol
• Can submit transactions and proposals
• Subject to trust-based rate limiting

Goals:

• Manipulate trust graph for elevated access
• Spam gossip network
• Create ledger inconsistencies
• Influence governance outcomes
• Exhaust resources of legitimate nodes

Example Attacks:

• Sybil attacks (create multiple identities)
• Gossip flooding
• Vote manipulation
• Trust inflation via collusion

1.3 Compromised Node (Stolen Keys)

Capabilities:

• Full access to legitimate user's identity
• All capabilities of Malicious Peer
• Historical transaction and trust relationships
• Possibly access to multiple devices (multi-device scenario)

Goals:

• Drain victim's credit balance
• Vote on victim's behalf
• Damage victim's reputation
• Access victim's private communications

Example Attacks:

• Balance theft
• Governance takeover
• Trust relationship manipulation
• Identity destruction

1.4 Economic Attacker

Capabilities:

• One or more valid ICN identities
• Understanding of mutual credit mechanics
• Potentially multiple colluding accounts

Goals:

• Extract value from the credit system
• Create unbacked credit
• Default on credit obligations
• Game dynamic credit limits

Example Attacks:

• "Grab and run" (exhaust credit limit, leave network)
• Credit cycling (inflate limits via circular transactions)
• Social recovery abuse (fake recoveries to duplicate balances)
• Demurrage avoidance schemes

1.5 Governance Attacker

Capabilities:

• Valid ICN identity with voting rights
• Understanding of governance mechanics
• Potentially colluding voters

Goals:

• Pass malicious proposals
• Block legitimate proposals
• Manipulate cooperative policies
• Gain unauthorized access/roles

Example Attacks:

• Vote buying/coordination
• Proposal spam (resource exhaustion)
• Quorum manipulation (prevent voting)
• Emergency mechanism abuse

1.6 Contract Attacker

Capabilities:

• Ability to deploy CCL contracts
• Understanding of interpreter mechanics
• Knowledge of capability system

Goals:

• Execute unauthorized operations
• Exhaust compute resources (fuel bombing)
• Extract data via side channels
• Bypass capability restrictions

Example Attacks:

• Fuel exhaustion attacks
• Deeply nested expression stack overflow
• Capability escalation attempts
• Non-deterministic execution exploitation

2. System Architecture Overview

┌─────────────────────────────────────────────────────────────────────┐
│                        APPLICATION LAYER                             │
│  ┌─────────┐  ┌───────────┐  ┌──────────┐  ┌─────────┐  ┌─────────┐ │
│  │ Gateway │  │Governance │  │ Compute  │  │ Ledger  │  │   CCL   │ │
│  │  REST   │  │  Domains  │  │  Tasks   │  │ Mutual  │  │Contracts│ │
│  │   API   │  │ Proposals │  │ Priority │  │ Credit  │  │  Rules  │ │
│  └────┬────┘  └─────┬─────┘  └────┬─────┘  └────┬────┘  └────┬────┘ │
│       │             │             │             │             │      │
├───────┴─────────────┴─────────────┴─────────────┴─────────────┴──────┤
│                         MESSAGE LAYER                                │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │  SignedEnvelope (Ed25519) │ ReplayGuard │ EncryptedEnvelope  │   │
│  └──────────────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────────────┤
│                        TRANSPORT LAYER                               │
│  ┌──────────────────────────────────────────────────────────────┐   │
│  │   QUIC/TLS 1.3  │  DID-TLS Binding  │  Certificate Verify    │   │
│  └──────────────────────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────────────────────┤
│                          DATA LAYER                                  │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────────────┐  │
│  │  Trust      │  │   Gossip    │  │       Sled Store            │  │
│  │  Graph      │  │   Topics    │  │   (Encrypted Keystore)      │  │
│  └─────────────┘  └─────────────┘  └─────────────────────────────┘  │
└─────────────────────────────────────────────────────────────────────┘

Security Boundaries

1. Network Boundary: QUIC/TLS separates untrusted network from authenticated peers
2. Trust Boundary: Trust graph determines access levels within authenticated peers
3. Cooperative Boundary: Per-coop isolation of ledgers and governance
4. Capability Boundary: CCL capabilities constrain contract operations

3. Attack Surface by Layer

3.1 Identity Layer

Files: icn-identity/, icn-net/src/tls.rs

3.2 Network Layer

Files: icn-net/src/actor.rs, icn-net/src/protocol.rs

3.3 Trust Layer

Files: icn-trust/src/lib.rs, icn-trust/src/compute.rs

3.4 Gossip Layer

Files: icn-gossip/src/gossip.rs, icn-gossip/src/bloom.rs

3.5 Ledger Layer

Files: icn-ledger/src/ledger.rs, icn-ledger/src/credit_policy.rs

3.6 Governance Layer

Files: icn-governance/src/, icn-gateway/src/api/governance.rs

3.7 Compute Layer

Files: icn-compute/src/actor.rs, icn-compute/src/executor.rs

3.8 Gateway Layer

Files: icn-gateway/src/auth.rs, icn-gateway/src/rate_limit.rs

4. STRIDE Analysis by Component

4.1 Identity System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.2 Network System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.3 Trust System

Spoofing

Tampering

Repudiation

Information Disclosure

TR-I2 Details: The inputs_hash field in TrustScoreResult (see icn/crates/icn-trust/src/attestation.rs, where created_at.to_le_bytes() is incorporated into signing payloads) includes raw created_at timestamps (Unix seconds) from trust attestations. When nodes exchange inputs_hash values in P2P queries or gossip, an attacker can:

1. Temporal inference: Observe hash changes to infer when new attestations arrive
2. Relationship correlation: Correlate hash values across nodes to detect shared trust relationships
3. Network mapping: Build a temporal map of trust network formation

Attack Scenario: Alice attests trust for Bob at t=1000. Eve queries Alice's trust score for Bob repeatedly. The inputs_hash changes at t=1000, revealing to Eve the exact moment Alice's attestation arrived. If Eve queries multiple nodes and sees the same hash change pattern, Eve can infer Bob received attestations from multiple parties simultaneously (coordination event).

Current Mitigation: None. Timestamp precision is preserved for cache invalidation and deduplication.

Recommended Mitigations (see GAP-M5):

• Option A: Truncate created_at to hourly/daily buckets (e.g., created_at - (created_at % 3600))
  • Pros: Simple, maintains relative ordering for deduplication
  • Cons: Reduces cache invalidation precision, may cause false deduplication within window
• Option B: Hash only non-temporal fields, track timestamps separately
  • Pros: Eliminates timing leak entirely
  • Cons: Breaks determinism guarantee (same attestations → different hashes if arrival times differ)
• Option C: Add random delay to hash propagation (traffic obfuscation)
  • Pros: Preserves determinism, mitigates correlation attacks
  • Cons: Adds latency, complex implementation

Existing Baseline Protection: Current trust-gated rate limits (10–200 msg/sec by trust class) apply to all messages, including trust score queries, providing baseline protection against polling attacks.

Cross-References:

• icn-privacy traffic obfuscation primitives (random delay, padding, cover traffic) — implemented but not yet wired into trust score query paths
• Planned trust score caching layer in the trust service (forward-looking; implementation location TBD)
• TrustScoreResult definition in icn/crates/icn-kernel-api/src/services.rs:116-144

Denial of Service

Elevation of Privilege

4.4 Gossip System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.5 Ledger System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.6 Governance System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.7 Compute System

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

4.8 Gateway API

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of Privilege

5. Mitigations Reference

5.1 Transport Layer Security

5.2 Message Layer Security

5.3 Trust-Based Rate Limiting

Implementation: icn-net/src/rate_limit.rs

5.4 Authentication & Authorization

5.5 Economic Controls

5.6 Contract Security

5.7 Byzantine Detection (Phase 18)

Violation Types:

Reputation Mechanics:

• Score Range: 0.0 (banned) to 1.0 (perfect)
• Penalty Formula: score -= severity * 0.05
• Decay Rate: +0.01/hour recovery
• Quarantine Threshold: < 0.5
• Rate Limit: Max 10 violations/hour before auto-ban

5.8 SDIS Identity Verification

Verification Levels:

6. Gap Analysis

6.1 High Priority Gaps

GAP-H3 Resolution: Phase 18 (2025-12-04) implemented MisbehaviorDetector with 7 violation types, reputation scoring (0.0-1.0), automatic quarantine at score < 0.5, and auto-ban for critical violations. See Section 5.7 Byzantine Detection for details.

6.2 Medium Priority Gaps

GAP-M5 Details: The inputs_hash computation in the trust attestation reducer implementation (within the trust computation logic of the icn-trust crate) includes raw Unix timestamps from attestations. This creates a timing side-channel that allows adversaries to:

• Correlation Attack: Query inputs_hash from multiple nodes. Identical hashes indicate nodes processed the same attestations with the same timestamps, revealing shared trust relationships.
• Temporal Attack: Poll a target node's trust score repeatedly. Hash changes reveal the exact moment new attestations arrive, enabling network activity monitoring.
• Social Graph Mapping: Combine timing data across nodes to build a temporal map of trust network formation (who attested for whom, and when).

Severity Rationale: Medium risk because:

• Requires persistent polling (detectable via rate limiting)
• Limited scope (only reveals timing of trust graph changes, not content)
• Mitigated by cooperative's transparency philosophy (trust graph is intentionally public)

However, timing precision could enable targeted attacks:

• Coordinated social engineering (attacker knows when target receives recommendations)
• Vote manipulation (correlate attestations with governance proposals)
• Sybil detection evasion (coordinate attestations to appear organic)

Decision Criteria for Mitigation:

1. No action needed if: Cooperatives accept that attestation timing is observable (transparency trade-off)
2. Timestamp truncation if: Cooperatives need timing obfuscation without breaking cache invalidation
3. Traffic obfuscation if: Cooperatives require strong unlinkability (enterprise/sensitive contexts)

Implementation Path:

• Phase 1 (Low effort): Document trade-off in operator manual, add warning in API docs
• Phase 2 (Medium effort): Add configurable timestamp truncation (hourly/daily buckets)
• Phase 3 (High effort): Wire icn-privacy traffic obfuscation into trust score query paths (primitives exist, integration needed)

Related:

• Threat TR-I2 in Section 4.3 (Trust System - Information Disclosure)
• icn-privacy traffic obfuscation module (implemented in icn-privacy/src/traffic_obfuscation.rs)
• Trust score caching and invalidation strategy

6.3 Low Priority Gaps

6.4 By-Design Limitations

These are intentional design decisions, not gaps:

6.5 Pilot Deployment Specific Risks

The K3s homelab deployment introduces deployment-specific attack surfaces:

Kubernetes-Specific Attack Vectors:

Monitoring Coverage:

• 15 Alertmanager rules configured for ICN-specific conditions
• Grafana dashboards for gossip, ledger, trust, compute
• Health endpoints monitored via liveness/readiness probes

See incident-response.md for K3s-specific incident procedures.

7. Security Assumptions

7.1 What This System Provides

• Authenticated communication between known identities
• Integrity of messages and stored data
• Non-repudiation of signed actions
• Availability under normal and moderate attack conditions
• Economic safety rails against common abuse patterns
• Capability-constrained contract execution

7.2 What This System Does NOT Provide

• Anonymous communication - All actions tied to DIDs
• Byzantine fault tolerance - Now partially provided via MisbehaviorDetector (Phase 18)
• Perfect forward secrecy - Key compromise reveals past messages
• Traffic analysis resistance - Network patterns observable
• Sybil resistance - Now partially provided via SDIS steward verification
• Legal enforceability - Technical system only

7.3 Trust Assumptions

8. References

Internal Documentation

• ARCHITECTURE.md - System architecture
• production-hardening.md - Security fixes
• security-roadmap.md - Security implementation plan
• phase-10c-security-analysis.md - Contract security

External References

• STRIDE Threat Modeling
• OWASP Top 10
• QUIC RFC 9000
• TLS 1.3 RFC 8446
• Ed25519 RFC 8032

Changelog

• 2026-02-01: Trust score timing attack documentation (v1.2)
  • Added TR-I2 threat: inputs_hash timing side-channel
  • Added GAP-M5 gap: Trust score timestamp precision leak
  • Documented three mitigation options with trade-offs
  • Cross-referenced with icn-privacy traffic obfuscation
  • Related: Issue #999, PR #987
• 2026-01-04: Updated for pilot deployment (v1.1)
  • Added Byzantine Detection mitigations (Phase 18)
  • Added SDIS identity verification controls
  • Added K3s pilot deployment specific risks
  • Updated gap analysis (GAP-H3 closed, GAP-H1 partial)
  • Updated security assumptions for new capabilities
• 2025-11-29: Initial comprehensive STRIDE analysis (v1.0)