# Security Model This document describes the security architecture of NCN Network v2, including threat modeling, security mechanisms, and trust assumptions. *** ## Security Overview NCN Network employs a **defense-in-depth** strategy with multiple security layers: ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Security Architecture │ │ │ │ ┌───────────────────────────────────────────────────────────────────────┐ │ │ │ Layer 5: Economic Security │ │ │ │ • Validator staking and slashing │ │ │ │ • Escrow-based payments │ │ │ │ • Economic incentives for honest behavior │ │ │ └───────────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────────┐ │ │ │ Layer 4: Cryptographic Security │ │ │ │ • secp256k1 ECDSA signatures │ │ │ │ • SHA-256 hashing │ │ │ │ • Signature verification on-chain │ │ │ └───────────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────────┐ │ │ │ Layer 3: Consensus Security │ │ │ │ • M-of-N validator signatures │ │ │ │ • Distributed validation │ │ │ │ • Byzantine fault tolerance │ │ │ └───────────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────────┐ │ │ │ Layer 2: Execution Security │ │ │ │ • Sandboxed model execution │ │ │ │ • System call filtering (seccomp) │ │ │ │ • Process isolation (namespaces) │ │ │ │ • Filesystem isolation (Landlock) │ │ │ │ • Resource limits │ │ │ └───────────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────────┐ │ │ │ Layer 1: Network Security │ │ │ │ • TLS encryption │ │ │ │ • Rate limiting │ │ │ │ • Authentication │ │ │ └───────────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` *** ## Threat Model ### Assets | Asset | Criticality | Primary Threats | | ------------------------- | ----------- | ------------------- | | **User Funds** | Critical | Theft, double-spend | | **Private Keys** | Critical | Exposure, theft | | **Computation Integrity** | High | Manipulation, fraud | | **Model Data** | High | Theft, tampering | | **Service Availability** | Medium | DoS attacks | ### Threat Actors | Actor | Capability | Motivation | | ----------------------- | ----------------- | -------------------------- | | **Malicious Model** | Code execution | Data theft, resource abuse | | **Rogue Compute Node** | Access to data | Payment fraud | | **Rogue Validator** | Signing authority | Approve invalid results | | **External Attacker** | Network access | Service disruption, theft | | **Colluding Operators** | Multiple roles | Payment manipulation | ### Attack Surface ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Attack Surface │ │ │ │ External Internal Blockchain │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ API Abuse │ │ Sandbox │ │ Contract │ │ │ │ DDoS │ │ Escape │ │ Exploits │ │ │ │ MITM │ │ Resource │ │ Front-run │ │ │ │ Auth Bypass │ │ Exhaustion │ │ Reentrancy │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` *** ## Trust Assumptions ### What We Trust | Assumption | Justification | | ---------------------------- | ------------------------------------------------- | | **Blockchain consensus** | Ethereum security model | | **Cryptographic primitives** | Standard algorithms (secp256k1, SHA-256) | | **Linux kernel** | Seccomp, namespaces, Landlock are kernel features | | **Majority of validators** | M-of-N consensus (Byzantine fault tolerant) | ### What We Don't Trust | Entity | Mitigation | | ------------------------ | ---------------------- | | **Any single validator** | M-of-N consensus | | **Model code** | Sandbox isolation | | **Compute nodes** | Signature verification | | **Network** | TLS encryption | | **Client input** | Input validation | *** ## Sandbox Security ### Isolation Mechanisms ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Sandbox Isolation │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ seccomp Filter │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ │ │ Allowed: read, write, mmap, brk, exit, futex, ... │ │ │ │ │ │ Blocked: socket, connect, fork, execve (except Python), ... │ │ │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ Namespace Isolation │ │ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ │ │ PID NS │ │ Network NS │ │ Mount NS │ │ IPC NS │ │ │ │ │ │ (isolated) │ │ (no access) │ │ (private) │ │ (isolated) │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ Landlock Filesystem Rules │ │ │ │ ┌─────────────────────────────────────────────────────────────┐ │ │ │ │ │ /tmp → Read/Write │ │ │ │ │ │ /models → Read only │ │ │ │ │ │ /python/lib → Read only │ │ │ │ │ │ Everything else → Denied │ │ │ │ │ └─────────────────────────────────────────────────────────────┘ │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌───────────────────────────────────────────────────────────────────┐ │ │ │ Resource Limits (rlimit) │ │ │ │ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ │ │ │ │ CPU: X seconds│ │ Memory: Y MB │ │ Files: Z │ │ │ │ │ └───────────────┘ └───────────────┘ └───────────────┘ │ │ │ └───────────────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### Attack Prevention | Attack | Protection | Mechanism | | -------------- | ----------------- | ---------------------- | | Network access | Network namespace | No network interfaces | | File theft | Landlock | Restricted file access | | Fork bomb | RLIMIT\_NPROC | Process limit | | Memory bomb | RLIMIT\_AS | Memory limit | | CPU exhaustion | RLIMIT\_CPU | CPU time limit | | Syscall escape | seccomp | Syscall whitelist | *** ## Cryptographic Security ### Signature Scheme **Algorithm**: secp256k1 ECDSA (Ethereum-compatible) ``` Message → SHA-256 Hash → ECDSA Sign → Signature │ ▼ 0x{r}{s}{v} (65 bytes) ``` ### Signed Data | Data | Signer | Purpose | | ------------------------ | ------------ | ---------------------- | | Preprocessing validation | Validators | Authorize payment | | Compute result | Compute node | Attest to computation | | Completion validation | Validators | Authorize distribution | | Subnet creation | Gateway | Authorize subnet | ### Verification Flow ```rust // On-chain verification function verifySignatures( bytes32 messageHash, bytes[] signatures, address[] validators ) { for (uint i = 0; i < signatures.length; i++) { address recovered = ECDSA.recover(messageHash, signatures[i]); require(isValidator(recovered), "Invalid validator"); } } ``` *** ## Economic Security ### Validator Staking ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Economic Incentives │ │ │ │ Honest Behavior Malicious Behavior │ │ ┌─────────────────────┐ ┌─────────────────────┐ │ │ │ + Validation rewards│ │ - Stake slashing │ │ │ │ + Reputation gain │ │ - Reputation loss │ │ │ │ + More selections │ │ - Fewer selections │ │ │ └─────────────────────┘ └─────────────────────┘ │ │ │ │ Cost of Attack: │ │ • Control M validators × minimum stake │ │ • Risk of detection and slashing │ │ • Reputation loss affects future earnings │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` ### Slashing Conditions | Offense | Penalty | Detection | | ---------------------- | ---------- | --------------------- | | Invalid signature | 50% stake | On-chain verification | | Approve invalid result | 30% stake | Challenge period | | Collusion | 100% stake | Governance action | | Prolonged downtime | 10% stake | Heartbeat monitoring | ### Escrow Protection ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Payment Escrow │ │ │ │ Client Contract Recipients │ │ │ │ │ │ │ │ 1. Deposit │ │ │ │ │───────────────────────▶│ │ │ │ │ │ (Funds locked) │ │ │ │ │ │ │ │ │ │ 2a. Completion │ │ │ │ │ (valid signatures) │ │ │ │ │───────────────────────────▶│ │ │ │ │ │ │ │ │ │ 2b. Expiry │ │ │ │◀───────────────────────│ (auto-refund) │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` *** ## Network Security ### TLS Configuration (Recommended) ```yaml # Gateway TLS tls: cert_file: /etc/ncn/certs/gateway.crt key_file: /etc/ncn/certs/gateway.key client_ca: /etc/ncn/certs/ca.crt min_version: TLS1.3 ``` ### Rate Limiting | Endpoint | Limit | Window | | -------------- | -------------- | -------- | | HTTP Inference | 100 | 1 minute | | gRPC Submit | 1000 | 1 minute | | WebSocket | 10 connections | Per IP | ### Network Isolation ``` ┌─────────────────────────────────────────────────────────────────────────────┐ │ Network Zones │ │ │ │ Public Zone DMZ Private Zone │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Clients │────▶│ Gateway │───────▶│ Compute │ │ │ │ Internet │ │ (HTTP/ │ │ Nodes │ │ │ │ │ │ gRPC) │ │ │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ │ │ │ │ │ ▼ │ │ │ ┌─────────────┐ │ │ │ │ Registry │◀──────────────┘ │ │ │ (P2P) │ │ │ └─────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘ ``` *** ## Security Recommendations ### Production Checklist * [ ] **TLS everywhere**: All connections encrypted * [ ] **Key management**: Use HSM or secure key storage * [ ] **Rate limiting**: Enable on all public endpoints * [ ] **Firewall**: Restrict unnecessary ports * [ ] **Monitoring**: Set up security alerting * [ ] **Updates**: Keep dependencies current * [ ] **Audit**: External security audit before mainnet ### Key Management | Environment | Recommendation | | ----------- | --------------------- | | Development | Environment variables | | Staging | Secrets manager | | Production | HSM / Hardware wallet | ### Incident Response 1. **Detection**: Monitor for anomalies 2. **Containment**: Pause affected services 3. **Investigation**: Collect logs and evidence 4. **Remediation**: Fix vulnerability 5. **Recovery**: Restore services 6. **Post-mortem**: Document and improve *** ## Related Documentation * [Sandbox Security](https://github.com/NeuroChainAi/docs-guides/blob/main/security/sandbox-security.md) - Sandbox details * [Cryptographic Signing](https://github.com/NeuroChainAi/docs-guides/blob/main/security/cryptographic-signing.md) - Signature verification * [Payment Security](https://github.com/NeuroChainAi/docs-guides/blob/main/security/payment-security.md) - Payment protection * [Best Practices](https://github.com/NeuroChainAi/docs-guides/blob/main/security/best-practices.md) - Security recommendations --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.neurochain.ai/nc/neurochainai-guides/architecture/security-model.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.