Device Obfuscation

What It Is

Device obfuscation makes a FortrOS node indistinguishable from a normal device to physical inspection, visual observation, and casual use. The transport profile (Tor and Anonymity Networks) handles what the network sees. This page handles what the person holding the device sees, and what someone searching a room finds.

Why It Matters

Three scenarios where device obfuscation is critical:

Asset laptops: An operative in a repressive regime carries a laptop that authorities may demand to inspect. The laptop must look and behave like a normal Linux or Windows machine. FortrOS is the invisible hypervisor underneath, routing connectivity through the org's secure overlay. The user interacts with a normal desktop VM. An inspector finds a normal laptop.

Dead-drop relays: A small device (Raspberry Pi, mini PC, or something disguised as a consumer device -- a "smart plug," a router, a USB charger) is placed on a target network. It connects to the local network and acts as a FortrOS relay node, bridging the org's overlay into the target environment. It looks like innocuous network hardware. No screen, no keyboard, no obvious indicators.

Insider defense: Within controlled infrastructure, a compromised insider (mole) with physical access might look for FortrOS-specific indicators on devices to identify which machines are part of the org's secure overlay vs normal infrastructure. If all machines look identical regardless of role, the insider can't distinguish targets from decoys.

Laptop Obfuscation

What the User Sees

The user experience must be indistinguishable from a normal laptop:

Boot sequence:

Power on -> UEFI -> OEM logo (normal firmware splash)
FortrOS preboot runs (display shows OEM logo or nothing -- no FortrOS branding, no unusual text output)
Preboot authenticates, unlocks /persist, kexec into main OS (still invisible to the display)
s6-rc starts services, maintainer connects overlay, reconciler starts the client VM
VM's virtual display connects to the physical screen via GPU passthrough
User sees: The desktop VM's boot splash and login screen, as if the laptop just powered on normally

The gap between power-on and "VM desktop appears" must fit within normal boot time expectations. If FortrOS's invisible boot takes 5-8 seconds and a normal Ubuntu boot takes 10-15 seconds, the timing is indistinguishable.

Sleep: FortrOS pauses the VM, suspends the host to RAM. On resume, the host wakes, the VM resumes. The user sees: lid close -> lid open -> desktop lock screen. Identical to any normal laptop.

Hibernate: FortrOS snapshots the VM state, writes the host hibernate image (locked with YubiKey + PIN). On resume, the preboot runs invisibly, restores the host, the reconciler restores the VM from snapshot. The user sees: normal shutdown -> normal boot -> desktop picks up where it left off.

Peripheral passthrough: Keyboard, mouse, trackpad, display, audio, webcam, USB ports, Bluetooth -- all passed through to the client VM. The VM owns the peripherals. The user never interacts with FortrOS directly during normal operation.

What an Inspector Sees

Physical device: A normal laptop. No stickers, no unusual hardware. Standard OEM branding.

Powered on: A normal desktop environment (Ubuntu, Fedora, Windows). Normal applications, normal files, normal browsing history. The client VM IS the cover -- it's a real, usable desktop environment.

Disk: /persist is LUKS-encrypted. Without the org's key material (TPM

org auth), it's indistinguishable from random data. The ESP contains a preboot UKI -- for maximum deniability, the ESP also contains a standard Linux bootloader as a decoy (GRUB entries that look normal).

UEFI boot entries: The FortrOS boot entry can be named to match the desktop OS ("Ubuntu", "Fedora") or hidden behind the decoy bootloader. UEFI admin password prevents the inspector from viewing boot entry details without credentials.

Network traffic: Controlled by the transport profile. With tor-obfuscated, all traffic looks like normal HTTPS or video calls. See Tor and Anonymity Networks#Leak Prevention and Fingerprinting for the full list of side channels that must align with the cover story.

Duress Features

For scenarios where an operative is compelled to unlock the device:

Duress PIN/passphrase: Entering a duress code instead of the real credentials unlocks a sanitized version of the desktop VM (or a separate decoy VM) with innocuous content. The real VM's state is preserved in encrypted storage, inaccessible without the actual credentials. The org is notified that a duress unlock occurred.

Remote wipe: The org can trigger a wipe via the "send what you have" generation protocol (04 Disk Encryption). The gen-auth refuses all generations, /persist is reformatted, all local state is destroyed. The preboot identity (TPM) survives for future re-provisioning, but nothing incriminating remains on the device.

Dead man's switch: If the device doesn't check in with the org within a configurable window, it self-wipes on next boot. The preboot contacts the org; if the org signals "wipe" (or doesn't respond within the window), the preboot reformats /persist.

Dead-Drop Relays

Form Factors

A dead-drop relay is a FortrOS node designed to be physically placed on a target network and left unattended:

Mini PC (Intel NUC, similar): Small, quiet, can be hidden behind furniture or in a server room. Looks like generic IT hardware.
Single-board computer (Raspberry Pi, similar): Tiny, low power, can be powered by USB. Disguised as a smart home device.
Modified consumer device: A device that already belongs on the network (a "smart plug" with a hidden SBC inside, a "NAS" that's actually a FortrOS node). Physical inspection reveals normal consumer electronics.

Behavior

The relay boots, connects to the local network (Ethernet or WiFi), and joins the org's overlay via the configured transport profile. It acts as a bridge: the org can route traffic into the target network through the relay. From the target network's perspective, the relay is just another device making normal network traffic.

No persistent indicators: The relay stores nothing incriminating on local storage. /persist is LUKS-encrypted (random data if locked). Org state is in memory only -- power loss destroys all state. If the relay is discovered and its storage is imaged, the image reveals nothing without the org's key material.

Network stealth: The relay uses the org's transport profile for all overlay traffic. Local network traffic (DHCP, ARP, normal broadcast) matches what any consumer device would produce. No unusual ports, no VPN signatures, no DNS queries for unusual domains.

Remote management: The org manages the relay entirely through the overlay. No SSH on the local network. No management ports exposed locally. If the relay needs reconfiguration, it comes through the encrypted overlay.

Insider Defense

Within controlled infrastructure (corporate network, government facility), an insider with physical or network access might try to identify which machines are part of the FortrOS overlay:

Uniform appearance: All machines in the facility run FortrOS (or appear to). There is no visible difference between a node that's actively part of the secure overlay and a decoy that's just running a normal desktop.

Network uniformity: If the org's transport profile is tcp-wrapped or obfuscated, the overlay traffic from real nodes looks identical to normal traffic from non-FortrOS machines. The insider can't distinguish by traffic analysis.

No management surface: FortrOS nodes expose no management ports on the local network. No SSH, no web console, no SNMP. All management is through the overlay. An insider running nmap on the local network sees the same open ports on FortrOS nodes as on normal desktops.

Decoy nodes: FortrOS can run decoy nodes that participate in gossip and appear to be real members but carry no sensitive state. An insider who identifies a node as "part of something" and investigates it finds nothing of value.

The Principle

Device obfuscation is about alignment: every observable property of the device (physical appearance, boot behavior, disk contents, network traffic, management surface) must be consistent with its cover identity. A laptop that looks normal but makes unusual network traffic is compromised. A relay that looks like a consumer device but responds to nmap differently is compromised. A server room machine that has different boot timing than its neighbors is compromised.

The org's obfuscation policy defines what "normal" looks like for each deployment context, and FortrOS aligns every observable to that definition.