Necropolis-C2/docs/security-model.md

Security Model — Sole Ownership & Permissioned Access

Core Principle

You are the sole owner of your data. No relay operator or ISP observer can read your C2 traffic, identify your implants, or access exfiltrated data.

Centralised C2 frameworks let a server operator (or hosting provider, or law enforcement) seize the server and read everything. necropolis's decentralised model puts cryptographic ownership and access control at every layer instead.

End-to-End Ownership

1. Operator Key = Ownership

The operator's Ed25519 private key is the root of trust. It is never shared with relays or bootstrap peers, never stored on any network, and is the sole credential that can authorise implants and decrypt data.

Operator Private Key (NEVER leaves operator's machine)
    ├── Derives Operator PeerID (public identity)
    ├── Signs implant binaries (proves ownership)
    ├── Signs all commands (authenticity)
    └── Signs beacon registration (proves implant authenticity)

2. What a Relay/Bootstrap Peer Sees

A libp2p relay forwards encrypted traffic. It sees:

• Source PeerID -> Destination PeerID (who is talking to whom)
• Encrypted bytes (cannot read contents)
• PubSub topic names (e.g., /c/<peerid>/cx) — topic IDs are hashes of the operator's public key

Relays cannot decrypt message contents, authenticate as the operator, send commands to implants, distinguish C2 traffic from any other libp2p traffic, or identify the data as C2 traffic.

Layered Encryption

Layer	Protocol	Protects
Transport	libp2p Noise XX / TLS 1.3	Eavesdropping, MITM on wire
PubSub	Envelope signing (Ed25519)	Impersonation, replay
NaCl Box	Bidirectional encryption	Implant and operator each generate box keypairs. Implant pubkey sent in beacon register. Operator encrypts commands with implant pubkey, implant encrypts responses with operator pubkey. Both directions ride on Noise + box.
Message	Per-message signing	Integrity, authenticity
Auth Token	32-byte operator-specific token	Prevents unauthorized command injection on implant side. Operator accepts beacons from any authenticated peer.
Command	Signed envelopes	Only operator can send commands

• Message authentication — Every Envelope carries a 32-byte operator-specific auth token. Auth token prevents unauthorized command injection on the implant side. Operator accepts beacons from any authenticated peer.

Threat Model & Guarantees

Operator is compromised

• Impact: Total loss — attacker controls everything
• Mitigation: Multi-operator support; each operator has their own key
• Hardware key support (future): Store operator key on YubiKey / TPM

libp2p relay is malicious

• Impact: Can see PeerIDs communicating, drop relay traffic
• Mitigation: Relays only see encrypted bytes; hole-punching avoids relays after connection
• Cannot: Read messages, impersonate operator, modify traffic

DHT / Sybil attack

• Impact: Attacker could intercept peer discovery
• Mitigation: Implants store direct backup peer list; operator PeerID is signed
• Cannot: Forge operator identity, decrypt messages

Social / Traffic analysis

• Impact: Observer sees that "PeerID X talks to PeerID Y"
• Mitigation:
  • Cover traffic (random noise published to topics) masks beacon timing signatures

Data Sovereignty Checklist

Concern	How necropolis Addresses It
Who owns the data?	Only the operator — data encrypted before touching the network
Who can read commands?	Only implants with the operator's public key embedded
Who can send commands?	Only the operator with the private key
Who knows implant locations?	Only the operator (discovery via signed DHT records)
Can a relay block me?	Yes, but any libp2p relay works — use multiple
Can traffic be identified as C2?	No — indistinguishable from regular p2p traffic

Operational Security Recommendations

1. Generate operator key on an air-gapped machine and transfer only the public key
2. Use unique implant keypairs — never reuse across engagements
3. Rotate operator key periodically
4. Enable cover traffic to mask beacon timing signatures
5. Self-host a libp2p relay for resilience against public relay rate limits
6. Prefer hole-punching over relayed connections for sensitive sessions