Overview

This section documents the security architecture and best practices for NCN Network v2.

---

Security Model

NCN Network v2 employs a defense-in-depth security model with multiple layers of protection:

┌─────────────────────────────────────────────────────────────────────────────┐
│                         Security Layers                                      │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  Layer 1: Network Security                                             │  │
│  │  • TLS encryption for all connections                                  │  │
│  │  • Rate limiting and DDoS protection                                   │  │
│  │  • Firewall rules and network isolation                                │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  Layer 2: Authentication & Authorization                               │  │
│  │  • Wallet-based authentication                                         │  │
│  │  • Cryptographic signatures                                            │  │
│  │  • Role-based access control                                           │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  Layer 3: Execution Security                                           │  │
│  │  • Sandboxed model execution                                           │  │
│  │  • System call filtering (seccomp)                                     │  │
│  │  • Process isolation (namespaces)                                      │  │
│  │  • Filesystem isolation (Landlock)                                     │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  Layer 4: Economic Security                                            │  │
│  │  • Validator staking                                                   │  │
│  │  • Slashing for misbehavior                                            │  │
│  │  • Escrow-based payments                                               │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
│  ┌───────────────────────────────────────────────────────────────────────┐  │
│  │  Layer 5: Cryptographic Security                                       │  │
│  │  • Result signing (secp256k1)                                          │  │
│  │  • Message hashing (SHA-256)                                           │  │
│  │  • Signature verification                                              │  │
│  └───────────────────────────────────────────────────────────────────────┘  │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

---

Security Documentation

Sandbox Security

Compute node sandbox isolation:

• seccomp syscall filtering

• Linux namespace isolation

• Landlock filesystem rules

• Resource limits

Cryptographic Signing

Signature schemes and verification:

• secp256k1 ECDSA signatures

• Message hashing

• Key management

• Verification process

Payment Security

Smart contract security:

• Escrow mechanism

• Signature verification

• Reentrancy protection

• Expiry handling

Network Security

Network-level protections:

• TLS configuration

• Rate limiting

• DDoS protection

• Firewall rules

Best Practices

Security recommendations:

• Key management

• Deployment hardening

• Monitoring

• Incident response

---

Threat Model

Assets to Protect

Asset	Criticality	Protection
User Funds	Critical	Escrow, signatures, validators
Private Keys	Critical	Never stored on-chain, HSM recommended
Model Data	High	Sandboxing, access control
User Data	High	Encryption, minimal retention
Service Availability	Medium	Redundancy, rate limiting

Threat Actors

Actor	Motivation	Mitigations
Malicious Model	Execute arbitrary code	Sandbox isolation
Rogue Compute Node	Steal funds, data	Signatures, escrow
Rogue Validator	Approve invalid results	M-of-N consensus
External Attacker	DoS, exploitation	Rate limiting, TLS
Man-in-the-Middle	Intercept data	TLS, signatures

Attack Vectors

                    Attack Surface
                    
┌─────────────────────────────────────────────────────────┐
│                                                         │
│  ┌─────────────┐    Network Attacks                     │
│  │   Network   │    • DDoS                              │
│  │   Layer     │    • Man-in-the-middle                 │
│  └──────┬──────┘    • DNS hijacking                     │
│         │                                               │
│         ▼                                               │
│  ┌─────────────┐    Application Attacks                 │
│  │ Application │    • API abuse                         │
│  │   Layer     │    • Input manipulation                │
│  └──────┬──────┘    • Authentication bypass             │
│         │                                               │
│         ▼                                               │
│  ┌─────────────┐    Execution Attacks                   │
│  │  Execution  │    • Sandbox escape                    │
│  │   Layer     │    • Resource exhaustion               │
│  └──────┬──────┘    • Malicious code execution          │
│         │                                               │
│         ▼                                               │
│  ┌─────────────┐    Economic Attacks                    │
│  │  Economic   │    • Double spending                   │
│  │   Layer     │    • Front-running                     │
│  └─────────────┘    • Validator collusion               │
│                                                         │
└─────────────────────────────────────────────────────────┘

---

Security Features

Implemented ✅

Feature	Description	Component
Sandboxed Execution	seccomp, namespaces, Landlock	Compute Node
Signature Verification	secp256k1 ECDSA	All components
M-of-N Consensus	Distributed validation	Registry
Escrow Payments	Funds held until completion	Smart Contract
Request Expiry	Automatic refunds	Smart Contract
Reentrancy Guard	Prevent reentrancy attacks	Smart Contract
Resource Limits	CPU, memory, time bounds	Compute Node

Recommended for Production 🚧

Feature	Description	Status
TLS Everywhere	Encrypt all connections	Configuration
API Authentication	API keys for clients	Planned
Rate Limiting	Prevent abuse	Partial
Security Audit	External audit	Recommended
Bug Bounty	Incentivize disclosure	Recommended

---

Key Management

Best Practices

┌─────────────────────────────────────────────────────────┐
│                  Key Management                          │
│                                                         │
│  Development          Staging            Production     │
│  ┌─────────────┐     ┌─────────────┐     ┌─────────────┐│
│  │ Environment │     │ Environment │     │    HSM /    ││
│  │  Variables  │     │  Variables  │     │   Vault     ││
│  │             │     │ + Secrets   │     │             ││
│  │  (Ephemeral)│     │  Manager    │     │  (Hardware) ││
│  └─────────────┘     └─────────────┘     └─────────────┘│
│                                                         │
│  Security Level:                                        │
│  Low ────────────────────────────────────────▶ High    │
│                                                         │
└─────────────────────────────────────────────────────────┘

Key Types

Key Type	Owner	Storage Recommendation
Gateway Wallet	Gateway Operator	Hardware wallet / HSM
Compute Wallet	Compute Operator	Secure enclave
Validator Key	Validator	HSM
Client Wallet	User	User-controlled

---

Incident Response

Response Levels

Level	Trigger	Response
P0 - Critical	Fund loss, exploit	Immediate pause, investigation
P1 - High	Service outage	1-hour response
P2 - Medium	Performance degradation	4-hour response
P3 - Low	Minor issues	24-hour response

Response Process

Detection → Triage → Containment → Investigation → Remediation → Post-mortem

---

Compliance

Data Handling

Data Type	Retention	Protection
Request data	30 days	Encrypted at rest
Payment records	Indefinite (on-chain)	Blockchain security
Logs	90 days	Access controlled
User data	Minimal	GDPR compliant

Audit Trail

All operations are logged:

• Request submissions

• Payment transactions

• Validation events

• Access attempts

---

Security Checklist

Pre-Deployment

• Generate unique keys for each component

• Configure TLS certificates

• Set up firewall rules

• Enable rate limiting

• Configure logging

• Test backup/recovery

Production

• Regular key rotation

• Monitor for anomalies

• Keep dependencies updated

• Conduct security reviews

• Maintain incident playbook

• Test disaster recovery

---

Reporting Security Issues

Responsible Disclosure

Please report security vulnerabilities to:

• Email: [email protected]

• PGP Key: [Available on request]

What to Include

1. Description of vulnerability

2. Steps to reproduce

3. Potential impact

4. Suggested fix (if any)

Response Timeline

• Acknowledgment: 24 hours

• Initial assessment: 72 hours

• Fix timeline: Depends on severity

---

Next Steps

• Sandbox Security - Isolation details

• Cryptographic Signing - Signature verification

• Best Practices - Security recommendations