Passcodes, wallet anti-hack, secure transfer, fleet maintenance · 03_qals_architecture/SECURE_OPS.md
Secure Ops — passcodes, wallet hardening, secure transfer, fleet maintenance
Date: 2026-09-09 · Answers: "figure out passcode systems, what's needed for secure and maintained setups, how to not have wallets hacked, and secure transfer of data/messages/value."
1. Passcode & login systems (the decision tree)
Principle: passkeys > PIN+biometric vault > passwords. Never passwords as the root of trust.
| Context | System | Why | Status |
|---|---|---|---|
| Human → wallet app | (a) Vault password today (PBKDF2×200k + AES-GCM at rest, 5-try lockout) → (b) passkeys/WebAuthn next (device hardware key, phishing-proof, nothing to steal remotely) | passwords leak; passkeys can't | vault ✅ · passkeys = next build |
| Human → web apps | existing OAuth + qalclaim handle-binding (points bind to a Qal handle; claiming proves handle ownership via a loopd challenge) | apps keep their login; the VALUE layer needs its own proof | ✅ (qalclaim) |
| Agent/service → anything | per-agent HMAC keys (loopd X-Sig) → RFC 9421/DID keys (Qal ID phase) |
rotate-able, capped, revocable in ~2s | ✅ HMAC · DID next |
| Device/machine → fleet | SSH keys only (no password SSH), Tailscale node identity, service keys via seedkit derivation | machine identity ≠ human identity | SSH ✅ · seedkit derivation ✅ |
| Recovery | BIP-39 mnemonic — the ONLY root. One phrase → identity + agent secret + chain slot | nothing else to lose | ✅ (seedkit, 39/39) |
Rules that make this work: never store the mnemonic (show-once), never reuse vault passcodes between machines, rotate agent keys quarterly (scripted), every lockout/revocation drills into a test.
2. How wallets actually get hacked — and which one we've blocked
| Attack | How it usually goes | Our state |
|---|---|---|
| Malware reads key files | plaintext keys on disk | blocked at rest: vault encryption (AES-256-GCM), identities stripped to public fields when locked |
| Phishing steals a password | user types it somewhere fake | vault password only ever unlocks locally (never transmitted); passkeys phase removes the class entirely |
| Malicious tx signing (the #1 real-world wallet hack) | user/agent tricked into signing a bad tx | structurally bounded: agent caps + escrowed holds mean the worst signed tx costs the daily cap; every tx is receipted and anchored (forensics = minutes) |
| Supply-chain wallet swap | trojaned download | single-source builds from our repo, checksums published; .deb from our own Pages origin — verify-by-default instructions in README |
| Backup theft | seed phrase in a screenshot/cloud note | show-once UX + explicit warnings; recovery drills documented |
| Remote exploitation of the box | exposed services | all services bind localhost/Tailscale (never public), firewalled RPC, LAN-exposure finding F1 already logged for fix |
| Social engineering of ops | "just run this" | qalsh = whitelist-only, anchored, paid — even us running commands on machines is receipted |
The honest remaining risks: (1) a compromised unlocked session (mitigation: 5-min auto-lock, caps bound the damage), (2) endpoint compromise with keylogging (passkeys + hardware keys later), (3) us being the escrow trustee while on-chain escrow is pending. All tracked in the threat model.
3. Secure transfer of data, messages, and value (the stack, end to end)
DATA (files): chunk → AES-GCM per chunk (keys from conversation ratchet, AAD-bound)
→ relay stores CIPHERTEXT only (48h TTL) → receiver re-hashes every chunk
→ whole-file sha256 → auto-anchored. Tamper = reject-before-reassemble.
MESSAGES: X25519 ECDH → HKDF → per-message ratchet keys → AES-GCM + ed25519
signatures + hash chain; contacts QR-PINNED (substitution → exit 4, zero
leakage); conversation Merkle roots anchored; multi-relay + offline ferry.
VALUE: never travels as a bearer object — it's ledger entries moved by
HMAC-signed orders; purchases are escrowed HOLDS (115% cap) that settle
at actual; on-chain twin (qal_credit) enforces caps in bytecode; every
settle/redeem/trade writes an anchored receipt.
Transport: Tailscale (WireGuard) between machines; bytes never ride the chain — only hashes do.
4. Maintained-setup checklist (per Fleet machine)
Daily (automated): service health probes → Signal alert on fault · receipt/anchoring spot-check.
Weekly: cargo audit + system updates (staged, not auto-reboot) · backup integrity: nightly encrypted snapshots of loopd/data, identities vault, genesis blobs; monthly restore drill (a backup you haven't restored is a rumour).
Monthly: key rotation (agent HMACs) · revocation drill (kill one agent, time it) · disk/thermal check on minis · reconciliation: loopd ledger vs receipts vs on-chain anchors (scripted; delta > 0 → halt + Signal).
Quarterly: full adversary drill (attack-of-the-quarter from the testing roadmap) · Tailscale ACL review · dependency + upstream IOTA rebase.
5. bb-mini / gmktec deployment (ready-to-run — machine offline at packaging time)
deploy/bbmini/ contains the whole package: install.sh (copies the four zero-dep services, creates hardened systemd user units, generates machine-specific keys from a fresh mnemonic, enables firewall guidance) and BBMINI_SETUP.md (10-minute operator walkthrough). Roles assigned to bb-mini: relay #2 (multi-relay decentralisation), compute provider node, fleet monitor. When the box is online: ssh bella@bb-mini 'bash -s' < deploy/bbmini/install.sh.