physical-threat-modeling

What this skill does

# physical-threat-modeling

Threat library for systems that face physical-access adversaries. Use when designing or reviewing systems that travel, are stored unattended, are operated in shared spaces, or face threat actors with momentary physical access (border crossings, hotel rooms, conferences, theft of laptops).

STRIDE and OWASP Top 10 implicitly assume a network adversary against a fixed-asset server. Their threat enumeration is **silent** on physical attacks — the threat model literally doesn't have categories for "evil-maid swap" or "Thunderbolt DMA". This skill fills that gap.

## Triggers

- "evil maid"
- "DMA attack" / "Thunderbolt attack"
- "travel host" / "airport / border / hotel"
- "hostile peripheral" / "BadUSB"
- "physical access" / "physical adversary"
- "coercion" / "rubber-hose" / "duress"
- "cold boot" / "RAM extraction"
- "supply chain implant"
- "side channel" / "TEMPEST" / "EM emanation"

## When NOT to use this skill

- Pure datacenter/cloud workloads with no portable assets (use STRIDE)
- Pure web app threat modeling (use OWASP)
- Forensics IR after a known compromise (use `forensics-complete`)

---

## Section 1: Threat Library

The library lists ten canonical physical-access threats. For each: applicability conditions, attacker capabilities required, detection difficulty, and remediation patterns. The remediation patterns are references to other skills' solutions — this skill is the enumeration.

### Threat 1: Evil-maid swap of bootstrap / boot media

**Description**: Adversary with brief physical access modifies code that runs before the integrity chain is established (bootloader, init scripts on writable media, USB bootstrap files).

**Applicability**:
- Asset is portable AND left unattended (hotel room, hotel safe, baggage claim, customs)
- Bootstrap code lives on writable media (FAT32 partition, USB MBR, unsigned ESP)
- Boot chain has no signature verification before user data is touched

**Attacker capability**: ~5–30 minutes physical access, basic technical skill, ability to write to the device or swap it.

**Detection difficulty**: Hard — the swap is functionally transparent until the operator runs something that reveals tampering, which the modified bootstrap can prevent.

**Remediation**: `chain-of-trust-design` skill — Pattern A (signed bootstrap blob) + Pattern D (printed hash card), or Pattern B (signed live image so the host code itself isn't on the writable media). Maps to review finding **B3**.

### Threat 2: Thunderbolt / USB-C DMA attack

**Description**: Adversary plugs a hostile DMA-capable peripheral into a Thunderbolt or USB-C port (with PCIe tunneling) and reads RAM via direct memory access, bypassing OS protections.

**Applicability**:
- Host has Thunderbolt 3+, USB-C with PCIe-tunnel, or FireWire
- Asset is in S0 (running) or S3 (sleep) state with secrets in RAM
- IOMMU is disabled or not properly configured

**Attacker capability**: 30–60 seconds, commodity attack tool (PCILeech, Inception), direct port access.

**Detection difficulty**: Detection-only via post-hoc memory analysis. Real-time detection requires DMAR/IOMMU event logging.

**Remediation**: 
- Disable Thunderbolt DMA in BIOS (`Thunderbolt Security Level: User Authorization` or `DisplayPort Only`)
- Enable IOMMU (`intel_iommu=on iommu=pt` Linux kernel)
- Lock screen → S5 (shutdown), not S3 (suspend), in hostile environments
- Use only known peripherals; physically block ports if possible (port blockers)

Maps to review finding **H4**.

### Threat 3: Hostile USB peripheral (BadUSB, keystroke injection)

**Description**: Adversary hands or plants a USB device that presents itself as a HID (keyboard) and runs commands, OR presents itself as a network adapter and intercepts traffic, OR presents as a mass storage device and exploits autorun.

**Applicability**:
- Host accepts USB devices without user authorization per device
- USB authorization (`/sys/bus/usb/.../authorized`) not enforced
- Operator plugs in unverified devices (gifted, found, public charging)

**Attacker capability**: Pre-attack hardware preparation; one-shot usage; deniability.

**Detection difficulty**: Hard at runtime; possible via USB authorization logs, USBGuard rules.

**Remediation**:
- USB authorization daemon (`USBGuard`) with allowlist
- Disable USB classes you don't use (mass storage, HID-from-storage)
- Use USB data blockers ("USB condoms") when charging from untrusted sources
- BIOS-level USB boot disabled when not provisioning

### Threat 4: Travel-host root compromise

**Description**: The host the operator uses to access the secret system is itself compromised at the OS or firmware level. Anything that runs on it — including the secrets pipeline — is observed by the adversary.

**Applicability**:
- Host is shared, public, hotel-provided, or has been out of operator's continuous custody
- Operator brings the secret system to the host (USB plug-in)
- Host runs an unsigned, unattested OS

**Attacker capability**: Persistent root malware; potentially firmware persistence.

**Detection difficulty**: Hard — root malware can hide from standard tools.

**Remediation**: This is the **single highest-leverage** mitigation for portable secret systems.

- **Boot the host from a signed live image** (Pattern B in `chain-of-trust-design`). The host stops being a trust dependency.
- Measured boot with TPM attestation against a known-good PCR set
- Forbid Docker fallback in production (Docker shares the host kernel; against kernel-resident adversary it's not a boundary)

Maps to review finding **H4**.

### Threat 5: Coercion of operator (rubber-hose attack)

**Description**: Adversary compels the operator (legally, threateningly, or via deception) to authenticate against the secret system.

**Applicability**:
- Operator is identifiable as a target
- Operator can be intercepted in person (border crossing, raid, kidnapping)
- System has no "what you know" factor (biometric + hardware = both available under duress)

**Attacker capability**: Physical access to operator AND device.

**Detection difficulty**: After-the-fact; sometimes never.

**Remediation**: `auth-factor-design` skill —
- FIDO2 PIN as a "what you know" factor (review finding H2)
- Duress codes (PIN that triggers wipe/silent-alarm)
- Time-locks, witness requirements, geographic fences

Maps to review finding **H2**.

### Threat 6: Cold-boot RAM extraction

**Description**: Adversary cools and removes RAM modules (or freezes the host with liquid nitrogen) to preserve the contents long enough to read out secrets that were unlocked in memory.

**Applicability**:
- Host can be physically opened
- Secrets are in plaintext in RAM
- Operating system/host doesn't crypto-protect RAM at rest

**Attacker capability**: Physical access; cooling spray (commodity); 5–10 minutes uninterrupted.

**Detection difficulty**: Impossible at runtime; possible via post-hoc inventory check.

**Remediation**:
- Reduce window: lock to S5 (full shutdown), not S3 (suspend), in hostile environments
- Use hardware features when available: Intel TME (Total Memory Encryption), AMD SME, Apple Silicon's secure enclave for sensitive computations
- Don't store keys in long-lived process memory — derive on demand and zeroize
- Accept residual risk: cold-boot is hard to fully eliminate without specialized hardware

### Threat 7: Hardware implant in supply chain

**Description**: A device is intercepted in supply chain (during shipment, at customs, by a malicious supplier) and a hardware implant is added — modified firmware, added microcontroller on motherboard, modified USB cable.

**Applicability**:
- High-value target
- Hardware sourced from untrusted supplier or shipped without tamper-evident packaging
- No hardware verification post-receipt

**Attacker capability**: Resourced adversary — nation-state, well-funded criminal group.

**Detection difficulty**: Very hard. Requires hardware teardown + comparison to known-good.

**Remediation**:
- Procurem