Portable Node

What It Is

A portable node is a bootable USB device (flash drive, NVMe enclosure) that turns any computer into a FortrOS node. Plug it in, boot from USB, authenticate with a YubiKey or CAC + PIN, and access your org environment. The host provides CPU, RAM, and peripherals. The stick provides the OS, encrypted storage, and org connectivity. The host's internal disks are never touched.

Carry a USB stick and a physical token instead of a laptop.

Why It Matters

You don't always have your device. Conferences, travel, incident response, a borrowed machine, an internet cafe in a foreign country. Today your options are: VPN into a cloud desktop (requires trusting the host OS) or carry your laptop everywhere.

A portable node says: plug in, authenticate, work, unplug. The stick is your node. The YubiKey/CAC is your identity. The org provides your environment. The host provides the hardware.

How It Works

What's on the Stick

The USB device contains the same partition layout as any FortrOS node, just on removable media:

ESP: Bootable, contains the preboot UKI (org-specific, signed)
/persist: LUKS-encrypted partition for node identity, boot state, cached org state, and cached generation images
Scratch/swap: LUKS-encrypted partition for client VM overlay, scratch data, and encrypted swap

On a USB flash drive, /persist and scratch are small (limited by flash write speed and capacity). On a USB NVMe enclosure, the stick is a full node with fast storage -- the difference between a flash drive and a laptop SSD is just the form factor.

The stick is generic to the org until first use. Any org member can take any stick, authenticate with their own YubiKey/CAC + PIN, and the stick becomes their node. The stick doesn't know who you are until you authenticate.

The Boot Sequence

Plug in USB device + YubiKey/CAC. Enter UEFI boot menu (usually F12), select USB.
FortrOS boots from the stick. Preboot UKI loads from the stick's ESP. Same boot chain as any permanent node.
/persist on the stick. The preboot authenticates to the org (YubiKey/CAC
- PIN replaces TPM-based auth), unlocks the stick's LUKS /persist, selects a generation, and kexec's into the main OS. The host's internal disks are never mounted, probed, or written to.
Connect to org overlay. The maintainer connects via the transport profile appropriate for the network (direct, tcp-wrapped, tor-obfuscated).
Client VM starts. Two paths depending on the host's hardware:
- Local execution: Host has enough CPU/RAM. Client VM runs locally, disk overlay on the stick's scratch partition. Best performance.
- Streaming: Host is underpowered. The org runs the client VM on a capable host and streams the display via App Streaming. The stick acts as a thin client.
Work. The user sees their desktop, their files, their apps. State syncs to org shard storage continuously (same mechanism as any client VM).
Done. Cleanly shut down the client VM. The stick syncs final state to the org. Unplug. The host reboots into its normal OS.

Storage Tiers by USB Device

Device	/persist	Scratch/Swap	Local VM Execution	Use Case
USB flash drive	Small (identity + boot state only)	Minimal (swap only)	Streaming preferred (slow I/O)	Emergency access, thin client
USB SSD	Moderate (cached images + state)	Moderate	Viable for light workloads	Travel, conferences
USB NVMe enclosure	Full (same as laptop SSD)	Full	Full desktop VM locally	Primary portable node

The architecture scales from a $10 flash drive (thin client / emergency) to a $100 NVMe enclosure (full portable workstation). The same OS, same security model, different performance.

Everything Is an Unreadable Brick

The stick takes full advantage of FortrOS's encryption architecture:

/persist is LUKS-encrypted. Without YubiKey/CAC + PIN + org auth, it's indistinguishable from random data.
Scratch/swap is LUKS-encrypted with a per-boot random key (destroyed on shutdown) or a derived key (for persistent scratch on NVMe sticks).
The ESP contains the signed preboot UKI -- the only readable part. It reveals that this is a FortrOS stick but nothing about the user, the org, or the data.
A found/stolen stick is a brick. No credentials, no data, no identity. The finder sees random encrypted data and a bootable partition that asks for a YubiKey they don't have.

Pulling the Stick from a Running System

Pulling the USB from a running system -- whether accidental or under duress -- has the same result: the stick is dead until reprovisioned.

What happens immediately:

FortrOS's architecture makes clean RAM wiping possible because the root filesystem is the initramfs (tmpfs, in RAM), not the USB. The USB provides /persist and scratch as secondary mounts. Pulling the USB loses those mounts but the kernel, s6, and all service binaries stay running in RAM. There is no kernel panic -- the OS lost a data disk, not its root.

A RAM-resident wipe service (mlockall'd, all code pinned in RAM) detects the USB disconnect and executes everything in parallel where possible:

Immediately, concurrently:

Self-revoke: The overlay is still up (WireGuard is in RAM). Send a revocation request to the org: "revoke this portable node's credentials." The org marks the stick as revoked in the CRDT -- before the stick is even in enemy hands, it's already invalid.
Kill all VMs and containers (release their memory pages)
Kill all non-essential services (reconciler, key service)
Begin scrubbing sensitive memory regions (encryption keys, CRDT state, session data, VM memory)

After concurrent operations complete:

Kill remaining services (maintainer last -- it was needed for the revocation message)
Zero remaining allocatable RAM pages
Trigger hardware reset (host reboots into its own OS)

The goal: minimize the window between USB disconnect and "nothing useful in RAM." Self-revocation and memory scrubbing don't depend on each other -- they race in parallel. The adversary's window is the time between physical USB removal and the hardware reset, during which RAM is being actively zeroed.

The wipe runs to completion -- no race against a panic. The kernel is fully functional in RAM for the entire sequence. On hosts with AMD SME or Intel TME (hardware RAM encryption with a per-boot key), the hardware reset also destroys the RAM encryption key, making any residual data in physical RAM unrecoverable even to a cold-boot attack.

After wipe and reset, the host reboots into its normal OS with no trace of FortrOS in RAM or on its storage. The org detects the node's disappearance from gossip and flags it.

The stick after pulling:

LUKS /persist is intact but the stick is cryptographically invalidated. A portable node requires live org authentication on every boot (no TPM, no local secret that survives reboot). Pulling the stick breaks the org auth session. Re-inserting and booting requires the org to re-authenticate the stick -- and the org knows this node was abruptly disconnected.
Org policy determines what happens on re-authentication:
- Revalidate: Org allows the stick to resume (homelab, accidental pull)
- Require reprovisioning: Org refuses the stick's cached generations, forces reformat of /persist (high-security default). The user reprovisions a fresh stick from any authed node.
- Remote wipe + alert: Org flags the event as duress, wipes the stick via the generation protocol, alerts administrators.

Accidental pull = same as duress pull. The user can't distinguish between "I tripped over the cable" and "someone yanked it." The org handles the distinction: if the user contacts the org and confirms it was accidental, the org revalidates. If the user doesn't check in, the org treats it as compromise.

State Actor with Stick + YubiKey + Compelled PIN

The worst case: a state actor physically has the stick and YubiKey, and compels the user to reveal the PIN. They boot the stick. Then:

The preboot authenticates to the org. The org controls the response.
If the node was flagged (duress signal, abrupt disappearance, user failed to check in): the org refuses authentication. The stick is a brick. Game over.
If the org delivers a duress response (org policy): the stick boots into a sanitized/decoy VM with innocuous content. The real client VM state stays in org shard storage, inaccessible.
If the org was not alerted (adversary was quick and subtle): the adversary gets a live session. This is the residual risk -- the org must be notified before the adversary boots the stick.

The mitigation chain: user triggers duress signal (separate duress PIN, dead man's switch if they don't check in within a time window, or the abrupt disconnection itself) -> org flags the node -> next boot attempt is refused or delivers decoy.

Org policy determines the posture:

Policy	On pull	On re-auth attempt	Residual risk
homelab	Alert only	Revalidate automatically	Low threat model
business	Alert + require reprovisioning	Refuse until admin approves	Delay between pull and re-auth
government	Alert + wipe	Refuse or deliver decoy VM	Time window before org is notified
intelligence	Dead man's switch + wipe	Always refuse after pull	Adversary must boot before org reacts

Security Model

Tails + Persistence

A portable node provides the benefits of Tails (no trace on host, encrypted everything, hostile-network-capable) combined with authenticated persistent access to an org environment:

	Portable Node	Tails
Trace on host	None (host disks never touched)	None (amnesic)
Network camouflage	Transport profiles (direct through tor-obfuscated)	Tor (all traffic)
Encrypted storage	LUKS on stick (unreadable brick without auth)	Optional encrypted persistent volume
User environment	Full client VM with roaming state from org	Tor Browser + basic tools
Identity	Authenticated (YubiKey/CAC + PIN)	Anonymous
State persistence	In org shard storage (survives stick loss)	None (by design)
Offline work	Yes (cached state on stick, syncs on reconnect)	Limited

Tails optimizes for anonymity (no identity, no state). A portable node optimizes for authenticated resilience (strong identity, persistent state, no trace on untrusted hardware). If an org member needs anonymous browsing, a disposable VM within the client environment can route through Tor -- combining both models.

Threat Assessment

Threat	Protected?	Why
Malware on the host OS	Yes	FortrOS replaces the host OS entirely
Network surveillance	Yes	Transport profile handles hostile networks
Forensic analysis of host after session	Yes	Nothing written to host disk
Forensic analysis of stolen stick	Yes	LUKS = unreadable brick without auth
Stolen stick (without token)	Safe	Org auth + YubiKey required to boot
Stolen token (without stick and PIN)	Safe	Token alone can't boot FortrOS
Stolen stick + token (without PIN)	Safe	PIN lockout after failed attempts
Stick + token + compelled PIN	Policy	Org controls auth: refuse, wipe, or decoy VM
Cold boot on host RAM after pull	Yes	Full RAM wipe before reset (kernel stays running in RAM after USB pull) + hardware RAM encryption if available
Compromised host firmware (ME/UEFI)	No	Firmware runs below FortrOS
Hardware keylogger	No	Physical device between keyboard and USB
Cold boot attack on host RAM	Partial	RAM contains data until power-off/decay

What's Not Trusted

The host hardware. The CPU, RAM, and peripherals are unknown. Compromised firmware could observe FortrOS's operations. A portable node is "better than using the host's OS directly" -- it eliminates software-level attacks but cannot eliminate firmware-level attacks on unknown hardware.

For maximum security: use the portable node only on hardware you've physically inspected (conference-provided laptop that you checked for hardware keyloggers) and combine with the tor-obfuscated transport profile.

Limitations

UEFI Secure Boot lockdown: Some machines have Secure Boot locked to Windows-only keys with a BIOS password. The stick can't boot. Workaround: enterprise-managed fleets can pre-enroll the org's key in their hardware.

No GPU passthrough: Host IOMMU groups are unknown. Desktop rendering is CPU-only for local execution, or streamed. Sufficient for productivity work.

Performance depends on the host AND the stick: A flash drive on a decade-old PC is a thin client. An NVMe enclosure on a modern workstation is a full desktop. The portable node adapts, but the user should carry appropriate media for their expected use case.

YubiKey-Pull Kill Switch on Permanent Nodes

The USB-pull wipe sequence isn't limited to portable nodes. Permanent FortrOS nodes can enable the same behavior for YubiKey/CAC removal as an org policy option:

Admin inserts YubiKey at boot to authorize the session
While the YubiKey is inserted, the node operates normally
Pulling the YubiKey triggers the same parallel wipe sequence: self-revoke via overlay, kill VMs/services, scrub RAM, reset
Useful for: secure terminals where the operator's physical presence IS the authorization. Walk away and pull your key = session killed.

This is org-policy-driven (session_kill_on_token_remove: true). Homelabs don't need it. Government secure terminals do. The mechanism is identical to the portable node's USB-pull response -- the trigger is just "YubiKey removed" instead of "boot device removed."

How FortrOS Uses It

Travel: Carry a stick for conferences, hotel business centers, borrowed machines
Incident response: Trusted OS on potentially compromised hardware
BYOD without installation: Org access from personal devices, nothing left behind
Asset operations: Work from any location, leave no trace
Disaster recovery: Any computer + stick + YubiKey = back in the org
Flexible form factor: Flash drive for emergencies, NVMe for daily use