Rivellum Threat Model

Version: 1.0
Last Updated: 2024
Status: Active

1. Executive Summary

This document describes the threat model for the Rivellum blockchain platform, including identified threats, attack vectors, mitigations, and security boundaries. It serves as a living document for security analysis and should be updated as the system evolves.

Key Security Goals:

Integrity: Ensure state transitions are valid and deterministic
Availability: Maintain consensus and network operation under adversarial conditions
Confidentiality: Protect sensitive user data (intents, keys) during processing
Non-repudiation: Ensure cryptographic accountability for all actions

2. System Overview

Rivellum is a blockchain platform with the following key components:

Core Components

Intent Layer: User-submitted intents with execution constraints
Consensus: Leader-based consensus with epoch-based key rotation
Execution: Move VM-based smart contract execution
Zero-Knowledge (ZK) System: Privacy-preserving proof generation
Proof-of-Useful-Work (PoUW): Economic incentives for proof generation
Networking: Gossip protocol for state dissemination

Trust Boundaries

Untrusted Network: Internet-facing RPC and p2p connections
Semi-Trusted Committee: Validator nodes (Byzantine fault tolerant)
Trusted Compute: Local node execution environment
Cryptographic Boundary: All inter-node communication secured with Ed25519

3. Threat Categories

3.1 Network-Level Threats

T-NET-001: Eclipse Attack

Description: Attacker isolates a node by controlling all its network connections
Impact: Victim receives false blockchain state, enabling double-spend or censorship
Likelihood: Medium (requires Sybil resources)
Mitigations:
- Diverse peer selection strategies
- Outbound connection diversity requirements
- Long-lived peer retention
- Network topology monitoring

T-NET-002: DDoS/Flood Attack

Description: Overwhelm nodes with excessive RPC requests or p2p messages
Impact: Service degradation, resource exhaustion, network partition
Likelihood: High (easily automated)
Mitigations:
- Rate limiting on RPC endpoints (implemented in validation.rs)
- Max payload sizes: RPC (10MB), intents (1MB), contracts (5MB)
- Connection limits per IP
- Proof-of-work for expensive operations (PoUW)
- Message prioritization for consensus-critical traffic

T-NET-003: Sybil Attack

Description: Attacker creates many fake identities to gain influence
Impact: Consensus manipulation, routing attacks, reputation gaming
Likelihood: High (low barrier to entry)
Mitigations:
- Stake-based admission control (future)
- IP diversity requirements
- Proof-of-useful-work gating for prover participation
- Reputation scoring for long-lived peers

T-NET-004: Man-in-the-Middle (MITM)

Description: Intercept and modify network traffic between nodes
Impact: State corruption, intent manipulation, key compromise
Likelihood: Low (TLS + Ed25519 signatures)
Mitigations:
- All messages cryptographically signed with Ed25519
- Gossip message authentication
- Peer identity verification
- Reject unsigned or invalid signatures

3.2 Consensus Threats

T-CONS-001: Byzantine Leader

Description: Malicious leader proposes invalid blocks or censors intents
Impact: State divergence, intent censorship, liveness failure
Likelihood: Medium (depends on leader selection)
Mitigations:
- Follower validation of all proposed blocks
- Leader rotation to limit damage window
- Slashing for provably invalid proposals (future)
- Intent expiration to prevent indefinite censorship

T-CONS-002: Finality Reversion

Description: Long-range attack to rewrite finalized history
Impact: Double-spend, contract state rollback
Likelihood: Low (requires >2/3 Byzantine nodes)
Mitigations:
- Cryptographic finality (committee signatures)
- Checkpointing for deep block history
- Social layer verification (community watchdogs)

T-CONS-003: Timejacking

Description: Manipulate node clocks to cause consensus desync
Impact: Block timestamp manipulation, intent expiry bypass
Likelihood: Low (NTP + validation)
Mitigations:
- Block timestamp bounds validation
- Reject blocks with excessive clock skew (±15 minutes)
- NTP synchronization requirements
- Intent deadline enforcement

3.3 Execution Threats

T-EXEC-001: Re-entrancy Attack

Description: Malicious contract recursively calls victim during execution
Impact: Unauthorized fund withdrawal, state corruption
Likelihood: Low (Move VM protections)
Mitigations:
- Move VM linear type system (resources consumed on move)
- No arbitrary external calls during execution
- Gas metering prevents infinite loops
- Stack depth limits (MAX_NESTING_DEPTH = 32)

T-EXEC-002: Integer Overflow/Underflow

Description: Arithmetic operations exceed type bounds
Impact: Incorrect token balances, contract logic bypass
Likelihood: Low (Move VM checks)
Mitigations:
- Move VM automatic overflow checking
- Safe math operations
- Numeric range validation in validation.rs

T-EXEC-003: Gas Exhaustion (DoS)

Description: Deploy contracts with excessive computational cost
Impact: Block execution timeout, network congestion
Likelihood: Medium (requires economic cost)
Mitigations:
- Gas metering for all operations
- Per-block gas limit
- Transaction fee market
- Contract size limits (5MB bytecode)

T-EXEC-004: Determinism Violation

Description: Non-deterministic execution causes state divergence
Impact: Consensus failure, fork
Likelihood: Low (VM determinism guarantees)
Mitigations:
- Move VM deterministic execution model
- No filesystem/network access in contracts
- Controlled randomness via VRF (future)
- Fuzzing for determinism bugs

3.4 Cryptographic Threats

T-CRYPTO-001: Key Compromise

Description: Private keys stolen via malware, social engineering, or cryptanalysis
Impact: Unauthorized transactions, consensus disruption
Likelihood: Medium (user error)
Mitigations:
- Ed25519 (128-bit security level)
- Epoch-based key rotation for committee keys
- Hardware wallet support (future)
- Multi-signature accounts (future)

T-CRYPTO-002: Weak Randomness

Description: Predictable RNG enables key prediction or proof forgery
Impact: Key compromise, proof invalidity
Likelihood: Low (system RNG)
Mitigations:
- ChaCha20Rng from rand crate
- System entropy sources
- No custom RNG implementations

T-CRYPTO-003: Signature Malleability

Description: Modify signature to create valid alternate signature
Impact: Transaction replay, double-spend
Likelihood: Low (Ed25519 not malleable)
Mitigations:
- Ed25519 canonical signatures
- Signature format validation (128 hex chars)
- Nonce/timestamp to prevent replay

3.5 Zero-Knowledge (ZK) Threats

T-ZK-001: Proof Forgery

Description: Generate valid-looking proof without honest computation
Impact: Invalid state transitions accepted, consensus failure
Likelihood: Low (cryptographic hardness)
Mitigations:
- Halo2 proof system (no trusted setup)
- Proof verification before acceptance
- Fuzz testing for verifier edge cases
- Multiple proof systems (future defense-in-depth)

T-ZK-002: Prover Griefing

Description: Malicious prover submits invalid proofs to waste verifier resources
Impact: Verification DoS, resource exhaustion
Likelihood: Medium (economic barrier via PoUW)
Mitigations:
- PoUW bid system (economic cost to submit)
- Proof format validation before expensive verification
- Prover reputation tracking
- Slashing for invalid proofs (future)

T-ZK-003: Witness Data Leakage

Description: Private inputs leaked via proof, side channels, or logs
Impact: User privacy violation, competitive advantage loss
Likelihood: Low (ZK guarantees)
Mitigations:
- Zero-knowledge proof properties (no witness leakage)
- Log sanitization (sanitize_for_log())
- Constant-time operations where applicable

3.6 PoUW Economic Threats

T-POUW-001: Bid Manipulation

Description: Coordinate bid prices to extract excessive rewards or censor jobs
Impact: Economic inefficiency, job starvation
Likelihood: Medium (requires coordination)
Mitigations:
- Configurable bid strategies (lowest-bid, reputation-weighted)
- Job timeout mechanisms
- Public bid visibility
- Multi-prover redundancy (future)

T-POUW-002: Job Starvation

Description: All provers offline or refusing jobs
Impact: Network liveness failure, intent backlog
Likelihood: Low (economic incentives)
Mitigations:
- Fallback to mock proofs in testing (configurable)
- Job expiry to prevent indefinite queuing
- Prover diversity incentives

3.7 Input Validation Threats

T-INPUT-001: Buffer Overflow

Description: Excessive input size causes memory corruption
Impact: Node crash, code execution
Likelihood: Low (Rust memory safety)
Mitigations:
- Rust memory safety guarantees
- Explicit size validation (validate_size())
- Max payload limits enforced at RPC layer

T-INPUT-002: Log Injection

Description: Craft input with newlines/control chars to manipulate logs
Impact: Log poisoning, false alerts, audit trail corruption
Likelihood: Medium (common attack)
Mitigations:
- sanitize_for_log() removes \n, \r, \t, control chars
- Structured logging (JSON) for machine parsing

T-INPUT-003: Unicode/UTF-8 Exploits

Description: Invalid UTF-8 causes parsing errors or security bypass
Impact: Denial of service, validation bypass
Likelihood: Low (validation)
Mitigations:
- validate_string() enforces UTF-8 validity
- String length limits (64KB max)
- Reject strings with invalid UTF-8

4. Security Controls

4.1 Implemented Defenses

Control ID	Description	Component	Status
C-001	Ed25519 signature verification	`rivellum-crypto`	✅ Implemented
C-002	Epoch-based key rotation	`rivellum-crypto`	✅ Implemented
C-003	RPC payload size limits (10MB)	`rivellum-types::validation`	✅ Implemented
C-004	Intent size limits (1MB)	`rivellum-types::validation`	✅ Implemented
C-005	Contract bytecode size limits (5MB)	`rivellum-types::validation`	✅ Implemented
C-006	Log injection sanitization	`rivellum-types::validation`	✅ Implemented
C-007	Address format validation	`rivellum-types::validation`	✅ Implemented
C-008	Signature format validation	`rivellum-types::validation`	✅ Implemented
C-009	Gas metering	`rivellum-move`	✅ Implemented
C-010	Stack depth limits (32)	`rivellum-types::validation`	✅ Implemented
C-011	State key limits (1000/tx)	`rivellum-types::validation`	✅ Implemented
C-012	Mutex poison handling	`rivellum-pouw`	✅ Implemented
C-013	Fuzzing infrastructure	`rivellum-fuzz`	✅ Implemented
C-014	Static analysis (clippy)	CI	✅ Implemented
C-015	Dependency auditing	CI	✅ Implemented

4.2 Planned Defenses

Control ID	Description	Priority	Target Phase
C-100	Slashing for Byzantine behavior	High	Phase 15
C-101	Hardware wallet integration	Medium	Phase 16
C-102	Multi-signature accounts	Medium	Phase 16
C-103	VRF for leader selection	High	Phase 15
C-104	Rate limiting per IP	High	Phase 15
C-105	Prover reputation system	Medium	Phase 16
C-106	Checkpointing for finality	High	Phase 15

5. Attack Surface Analysis

5.1 External Attack Surface

Interface	Exposure	Authentication	Risk Level
JSON-RPC API	Public (TCP 8545)	None	High
P2P Gossip	Public (TCP 9000)	Ed25519	Medium
WebSocket	Public (TCP 8546)	None	High
Metrics/Health	Private (localhost:9090)	None	Low

Recommendations:

Deploy reverse proxy (nginx) for RPC with TLS
Use firewall rules to restrict P2P to known peers
Never expose metrics port to public internet

5.2 Internal Attack Surface

Component	Trust Level	Risk Level
Move VM	Sandboxed	Low
RocksDB	Trusted	Low
PoUW Queue	Shared State	Medium
ZK Prover	Untrusted Input	Medium

6. Incident Response

6.1 Critical Vulnerabilities

If a critical vulnerability is discovered:

DO NOT publicly disclose until patch is available
Report to security@rivellum.dev (see SECURITY.md)
Patch will be developed privately
Coordinated disclosure after 90 days or patch deployment
Post-mortem published after resolution

6.2 Emergency Procedures

Consensus Halt:

Committee coordination via secure channel
Emergency patch deployment
State rollback to last known good checkpoint

Key Compromise:

Rotate epoch keys immediately
Invalidate compromised signatures
Notify affected users

7. Audit History

Date	Auditor	Scope	Findings	Status
TBD	Internal	Full codebase	TBD	Pending
TBD	External	Crypto + Consensus	TBD	Planned

8. Assumptions & Limitations

8.1 Trust Assumptions

Committee Honesty: < 1/3 of committee nodes are Byzantine
Cryptographic Hardness: Ed25519, Halo2 remain secure
Network Synchrony: Messages delivered within bounded time
Time Synchronization: Nodes maintain NTP sync within 15 min

8.2 Known Limitations

No quantum resistance (Ed25519 vulnerable to Shor's algorithm)
Single leader bottleneck for liveness
Limited scalability (~1000 TPS without sharding)
No formal verification of Move contracts

8.3 Out of Scope

Physical security of validator hardware
Social engineering attacks on operators
Supply chain attacks on dependencies
DNS hijacking or BGP attacks

9. References

10. Change Log

Version	Date	Changes	Author
1.0	2024	Initial threat model	Security Team

Document Classification: Internal Use
Next Review Date: Quarterly or after major architecture changes