OPSEC — Identidad y compartimentacion de personas (sock puppets)

OPSEC — Identidad y compartimentacion de personas (sock puppets)

Sub-nota atomica del manual maestro manual-paranoid-opsec. Cada capitulo es una nota propia para consulta directa por dominio operativo.

4. Identity & Persona Compartmentalization

Goal: Build and operate investigative personas that cannot be reliably linked to you, your organization, other personas, or prior operations—while remaining credible for the mission.

4.1 Definitions & Scope

  • Persona: A constructed identity (name, contact points, device profile, behavior) used for investigative tasks.
  • Compartment: A self-contained environment (device/VM, browser profile, password store, comms channels) dedicated to a single persona or case.
  • Cross‑contamination: Any shared artifact (IP address, browser fingerprint, wording quirks, reused avatars, payment trail) that can link compartments.

4.2 Policy Baselines

  • One Persona = One Compartment (device/VM, browser, password vault, comms, storage). No sharing.
  • Zero Reuse Rule: No reuse of usernames, avatars, bios, recovery emails/phones, payment instruments, or VPN egress IPs across personas.
  • Attribution Budget: Treat every artifact as a potential identifier. Keep the sum of identifiers per persona as low as possible.
  • Lifecycle Discipline: Plan for provision → operate → rotate → retire, with documented criteria for each step.

4.3 Persona Lifecycle (Plan → Provision → Operate → Rotate → Retire)

Plan

  • Define objectives, target platforms, required credibility (age of account, posting cadence, social graph).
  • Choose risk level (L0–L3) from §3 and map mandatory controls.
  • Run a pre‑provision conflict check to avoid collisions with real people/brands.

Provision

  • Create unique credentials and recovery channels (no overlap with other personas).
  • Stand up dedicated VM/OS (Qubes domain, separate VM, or dedicated device) and browser profile.
  • Establish contact points (email/number) and 2FA (hardware token per persona).

Operate

  • Follow a content and engagement script (topics, tone, posting windows, reaction policy).
  • Maintain network separation (distinct VPN exit/Tor circuit). Log sessions for post‑op review.
  • Keep a persona register (metadata and link graph) updated after each session.

Rotate (when exposure risk rises or objectives change)

  • Change exit IP ranges, posting windows, and low‑value attributes.
  • Re‑issue credentials and regenerate keys as required.

Retire

  • Tombstone gracefully (final benign message or silence, depending on OPSEC).
  • Archive evidence, export logs, revoke tokens, destroy keys/seeds, wipe or reimage the compartment.

4.4 Persona Design (Credibility without Linkability)

  • Biographic outline: plausible age, locale, language variant, time‑zone; avoid copying personal details or unique biographical events.
  • Backstory & cover: minimal and congruent (job/education kept generic). Keep statements easy to maintain under questioning.
  • Style & linguistics: align spelling, idioms, and punctuation with claimed locale. Randomize rhythm; avoid distinctive catchphrases. See §13.4 for stylometry OPSEC.
  • Visual identity: avatars/banners with lawful, licensed stock or purpose‑made media. Avoid reusing GAN portraits across personas (researchers can cluster style). Strip EXIF before upload.
  • Social graph: follow/connect gradually, mirroring normal user behavior. Seed with low‑risk follows before target engagement.

4.5 Provisioning: Accounts, Contact Points, and Payments

Email

Phone / Voice

  • Use lawful VoIP/burner services with clear ToS (e.g., JMP.chat https://jmp.chat/). Avoid numbers tied to your identity; understand KYC requirements by jurisdiction.
  • For high‑risk ops, avoid voice/SMS verification; prefer app‑based or hardware 2FA when platforms allow.

Domains & Web Presence (optional)

  • If persona needs a site, register with WHOIS privacy enabled; separate registrar account and payment method; no analytics. Host static-only pages; disable logs where legal.

Payments

  • Use organization‑approved methods (virtual cards, prepaid where lawful). Keep receipts in encrypted vault; never reuse payment instruments across personas.

4.6 Compartment Engineering (Devices, VMs, Browsers)

  • Device/VM: one VM per persona (e.g., Qubes persona‑x AppVM) or a dedicated laptop. Snapshots before/after operations.
  • Browser: dedicated profile per persona. Prefer Tor Browser (no extensions) or Brave hardened profile. Disable password sync/cloud features.
  • Password store: separate KeePassXC vault per persona with its own strong passphrase; store in the persona’s compartment only.
  • Key material: per‑persona PGP keys (GnuPG). Keep master/backup offline; use subkeys operationally.
  • Storage: encrypt at rest (VeraCrypt/LUKS). Distinct containers for evidence vs. persona working data.

4.7 Network Separation & Traffic Hygiene

  • Exit isolation: each persona uses a distinct VPN egress IP or Tor circuit. Do not alternate multiple personas over the same exit during overlapping windows.
  • Leak control: enforce DNS/IPv6/WebRTC hardening. Validate at ipleak.net after every environment change.
  • Session windows: schedule distinct activity windows per persona (time‑zone believable for the cover story). Vary posting times within natural ranges.
  • Geo‑consistency: ensure IP geolocation matches claimed region; align with language and content cadence.

4.8 Operational Conduct (Content, Engagement, and Safety)

  • Content script: predefine acceptable topics, tone, and red lines. Avoid statements that demand deep domain knowledge you cannot sustain.
  • Engagement playbook: expected responses to DMs, friend requests, and provocations. Use templated, low‑commitment replies where possible.
  • Attachments: scrub metadata (MAT2/ExifTool) and validate file types before opening inbound media. Never open untrusted files in the same compartment used for persona comms—use a disposable analysis VM.
  • Cross‑platform discipline: do not copy/paste verbatim text across platforms. Vary formatting and timing to reduce correlation risk.

4.9 Deconfliction & Linkage Testing

  • Before first use, run an OSINT collision scan: search proposed names/handles, image reverse‑search for avatars, and check for brand conflicts.
  • Periodically audit the persona with outside‑in tests: browser fingerprint checks (AmIUnique), leaked credential searches (HaveIBeenPwned https://haveibeenpwned.com/), and social graph diffusion (manual review).
  • Plant low‑risk canary interactions (e.g., distinct redirects) to detect unintended cross‑links between compartments.

4.10 Rotation & Retirement

  • Rotation triggers: platform KYC prompts, unusual login alerts, direct targeting, change in mission scope, or accumulated attribution budget.
  • Rotation actions: change exit infrastructure, regenerate keys, adjust posting windows/tone, refresh avatar/biographic minor details (keep core identity consistent to avoid suspicion).
  • Retirement: export evidence, revoke API tokens, delete or freeze accounts per policy, destroy keys/seeds, wipe/reimage the compartment. Update the persona register to RETIRED with rationale and date.

4.11 Records & Templates

Maintain a Persona Register (stored inside an encrypted case vault):

  • Persona ID, Handle(s), Creation Date, Purpose/Case, Risk Level (L0–L3), Email, Phone/IM, 2FA method, Device/VM ID, VPN/Tor profile, Notes on style/locale, Known contacts, Rotation history, Retirement date & reason.

Checklists (quick use):

  • Pre‑Provision: name/handle collision check; decide risk level; prepare VM; create email/2FA; set password vault; note recovery codes.
  • Go‑Live: fingerprint test; IP geo check; seed social graph; first low‑risk posts; log session.
  • Ongoing: vary cadence; keep logs; run periodic linkage tests; update register.
  • Sunset: archive, revoke, wipe, document.

🔥 Extreme Practices (Optional)

  • Use one-time personas – identities should exist only for a single task, then be retired.
  • Operate personas exclusively on burner hardware purchased anonymously and destroyed after use.
  • Apply stylometric masking: alter writing style, vocabulary, errors, and tone depending on the persona.
  • Maintain multi-layered identities: one as a primary cover, one as a decoy, and one as a “sacrificial” persona ready for intentional exposure.
  • Never repeat the same activity patterns (time of day, session length, UI language) across multiple personas.

Themes