SECURITY.md

🛡️ SolVox Security Model

Threat Model

SolVox operates under the assumption that:

1. The renderer process is untrusted — it could be compromised via XSS
2. The main process is the trust boundary — all key operations happen here
3. The local filesystem is semi-trusted — OS-level encryption protects at-rest data
4. The network is adversarial — only Solana RPC calls leave the device

Security Controls

1. Process Isolation

Control	Setting	Purpose
contextIsolation	true	Renderer cannot access Node.js globals
nodeIntegration	false	No require() in renderer
sandbox	true	OS-level process sandbox (Chromium)
webSecurity	true	Same-origin policy enforced
allowRunningInsecureContent	false	No HTTP content in HTTPS context
navigateOnDragDrop	false	Prevents file drag-and-drop navigation

2. IPC Channel Allowlist

The preload script exposes ONLY these namespaced channels via contextBridge:

wallet:create, wallet:import, wallet:getPublicKey, wallet:getBalance,
wallet:sendSOL, wallet:sendUSDT, wallet:getHistory, wallet:isUnlocked,
wallet:lock, wallet:exists

auth:biometric, auth:unlock, auth:setPin, auth:biometricAvailable

security:getSettings, security:updateSettings, security:addWhitelist,
security:removeWhitelist, security:getWhitelist, security:getAnomalies

ai:initialize, ai:processVoice, ai:chat, ai:parseIntent, ai:speak,
ai:translate, ai:embed, ai:ocr, ai:getStatus

rag:search, rag:addDocument

No raw ipcRenderer is ever exposed. The renderer cannot invoke arbitrary IPC channels.

3. Key Storage

Mnemonic/Private Key
    │
    ▼
PIN-based AES-256-GCM (PBKDF2, 600K iterations, SHA-512)
    │
    ▼
Electron safeStorage (OS keychain: macOS Keychain / Windows DPAPI / Linux libsecret)
    │
    ▼
File on disk (0600 permissions, owner-only)

The mnemonic is double-encrypted: first with the user's PIN (AES-256-GCM with PBKDF2-derived key), then with OS-level safeStorage. An attacker who obtains the vault file still needs:

1. The user's OS login credentials (to decrypt safeStorage)
2. The user's PIN (to decrypt the inner AES layer)

4. In-Memory Key Handling

• The Keypair object lives exclusively in the main process's _sessionKeypair variable
• On lock: secretKey.fill(0) zeroes the key buffer (best-effort; V8 GC is non-deterministic)
• Auto-lock triggers after 5 minutes of inactivity
• Key material is NEVER sent over IPC — only the public key (base58 string) and signed transaction bytes

5. Transaction Guards

Guard	Protection
Input validation	Regex-validated addresses, bounds-checked amounts
Per-tx limits	Configurable maximum per transaction
Daily volume	Cumulative daily spend limit
Velocity	Max transactions per hour
Cooldown	Minimum time between transactions
Whitelist	Optional — only send to pre-approved addresses
Anomaly detection	AI-powered pattern analysis (high amounts, odd hours, rapid sequences)
Confirmation	Every transaction requires explicit user confirmation

6. Content Security Policy

default-src 'self';
script-src 'self';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
connect-src 'self' https://api.mainnet-beta.solana.com https://api.devnet.solana.com;
object-src 'none';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';

• No unsafe-eval — prevents eval() and new Function() attacks
• No external scripts — blocks CDN-based script injection
• Limited connect-src — only Solana RPC endpoints allowed
• No frames — prevents clickjacking

7. Navigation Protection

• All navigation to non-local URLs is blocked
• New window creation is denied (setWindowOpenHandler(() => ({ action: 'deny' })))
• DevTools are disabled in production builds

Data Flow

Voice Input ──→ QVAC (local) ──→ Intent ──→ Main Process validates ──→ Wallet signs ──→ Solana RPC
                                                    │
                                                    ▼
                                            TransactionGuard checks:
                                            ├── Address format valid?
                                            ├── Amount within limits?
                                            ├── Daily volume OK?
                                            ├── Velocity limit OK?
                                            ├── Address whitelisted?
                                            ├── Anomaly detected?
                                            └── User confirmed?

Only the signed transaction bytes leave the device — via Solana RPC. All AI processing, intent parsing, and validation happen locally.

Known Limitations

1. V8 garbage collection means secretKey.fill(0) doesn't guarantee the key is erased from all memory pages
2. Electron renderer could theoretically be compromised via a 0-day in Chromium — contextIsolation + sandbox mitigate this
3. Transaction privacy is limited by Solana's public blockchain — recipients and amounts are on-chain
4. PIN brute-force is mitigated by PBKDF2 (600K iterations) + lockout, but a sufficiently weak PIN (e.g., 123456) can still be guessed

Recommendations for Production

• Use a hardware security module (HSM) or secure enclave for key storage
• Implement Shamir's Secret Sharing for mnemonic backup
• Add a dead man's switch (auto-transfer if inactive for N days)
• Integrate with hardware wallets (Ledger/Trezor) for signing
• Add transaction simulation (Solana simulateTransaction) before signing