# eZFS2FA+ — FreeBSD-First Hardened ZFS with FIDO2 Two-Factor Authentication **Sources:** [eZFS2FA+ GitHub Repository](https://github.com/BillieBadin/eZFS2FA) · [Vivian Voss on LinkedIn](https://www.linkedin.com/posts/vvoss_this-is-what-freebsd-first-looks-like-when-share-7459874878171693056-wqRH) **HTML Infographic:** [ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.html](ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.html) **RDF Knowledge Graph:** [ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.ttl](ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.ttl) **Authors:** [Billie Badin](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/billiesabouraud/) (SIGORYX Engineering) · Commentary: [Vivian Voss](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/vvoss/) **License:** MIT · **Version:** 1.0.0 · **Published:** May 2026 --- ## Overview [eZFS2FA+](https://linkeddata.uriburner.com/describe/?url=https%3A//github.com/BillieBadin/eZFS2FA) is a hardened FreeBSD-first interactive workflow for wrapping encrypted [OpenZFS](https://linkeddata.uriburner.com/describe/?url=https%3A//openzfs.org/) dataset keys with [FIDO2](https://linkeddata.uriburner.com/describe/?url=https%3A//fidoalliance.org/fido2/)-backed two-factor authentication, with full Linux compatibility built in. The core idea is simple: protected services do not start at boot. Their secrets live inside encrypted OpenZFS datasets that remain locked until the operator explicitly unlocks them with a FIDO2-compatible hardware token (such as those made by [Yubico](https://linkeddata.uriburner.com/describe/?url=https%3A//www.yubico.com/)), a passphrase, or both. On [FreeBSD](https://linkeddata.uriburner.com/describe/?url=https%3A//www.freebsd.org/), the transient raw key material is held in `mdmfs -M` (malloc-backed `md(4)` storage) — never touching swappable memory or hard storage. On [Linux](https://linkeddata.uriburner.com/describe/?url=https%3A//www.kernel.org/), the equivalent is `ramfs`. The raw key is wiped immediately after the dataset is unlocked. Created by [Billie Badin](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/billiesabouraud/) of SIGORYX Engineering, developed on [Pi-BSD](https://linkeddata.uriburner.com/describe/?url=https%3A//www.freebsd.org/platforms/arm/) running on an untethered battery-powered ARM stack. MIT licensed. --- ## Vivian Voss's Commentary > "This is what FreeBSD-first looks like when someone actually means it." > — [Vivian Voss](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/vvoss/), System Architect & Philosopher [Vivian Voss](https://www.linkedin.com/in/vvoss/) identifies three things she particularly admires about eZFS2FA+: **1. The threat model is stated honestly.** eZFS2FA+ protects against a powered-off machine being lost, stolen, or imaged — not against a live compromise at unlock time. The right line to draw, drawn out loud. One sees that less often than one would hope. **2. The zero lock-in principle is structural, not promotional.** Back up the ZFS raw key offline and the framework becomes optional. The user keeps their own dataset. **3. The development platform is Pi-BSD on an untethered battery-powered stack.** The kind of small, deliberate, hand-built work that one used to see more of — a Wabi-Sabi (侘寂) approach to infrastructure. --- ## Threat Model eZFS2FA+'s threat model is stated explicitly — a quality that Vivian Voss specifically praises as rare and valuable: | Threat | Protected? | |--------|------------| | Powered-off machine lost or stolen | ✅ Yes | | Powered-off machine forensically imaged | ✅ Yes | | Offline brute-force without the FIDO2 token | ✅ Yes | | Live, fully compromised root/kernel at unlock time | ⚠️ No — explicitly disclaimed | --- ## Architecture ### FreeBSD — Primary Platform The transient ZFS key is held in `mdmfs -M` (malloc-backed `md(4)`) — a FreeBSD native primitive that creates a kernel-memory-backed filesystem. It cannot be swapped to disk and leaves no trace on stable storage. The key is wiped immediately after the dataset unlocks. ### Linux — Compatible Platform The equivalent mechanism is `ramfs` — a Linux in-kernel filesystem that cannot be swapped. eZFS2FA+'s design respects BSD primitives where they exist rather than pretending the two systems are interchangeable. ### FIDO2 Key Wrapping The ZFS encryption key is wrapped (encrypted) using a FIDO2 hardware token (e.g., [YubiKey](https://linkeddata.uriburner.com/describe/?url=https%3A//www.yubico.com/)), a passphrase, or both. The wrapped key is stored in a single JSON state file. The raw key is never stored directly. ### Zero Lock-in The raw ZFS key can be backed up independently and used with standard `zfs send` to any target. Once the key is secured offline, eZFS2FA+ becomes optional — the user retains full ownership of their dataset. --- ## Features - **Multiple enrolled FIDO2 keys** — any enrolled token can unlock the dataset - **Single JSON state file** — stores all wrapped key copies; safe to back up - **Service-start prerequisite checks** — dependent services held until dataset unlocks - **Delayed forced locking** — configurable timer to re-lock the dataset automatically - **Optional lock-time ZFS snapshots** — consistent restore point at each lock event - **Removable/mirrored media support** — coming soon - **Proxmox Server Solutions integration** — in progress - **Zero lock-in** — raw key exportable via standard `zfs send` - **MIT licensed** — open source, auditable, contributions welcome ### Dependencies | Platform | Required | |----------|----------| | FreeBSD | python3, py-cryptography, libfido2 | | Linux | python3-cryptography, fido2-tools | --- ## How-To: Secure a ZFS Dataset with eZFS2FA+ ### Step 1 — Install Dependencies ```bash # FreeBSD (pkg) pkg install python3 py311-cryptography libfido2 # Linux (apt) apt install python3-cryptography fido2-tools # Clone the repo git clone https://github.com/BillieBadin/eZFS2FA.git ``` ### Step 2 — Run the Installer ```bash # FreeBSD doas sh ./install.sh # Linux sudo sh ./install.sh ``` ### Step 3 — Enrol Your FIDO2 Token Follow the interactive workflow to enrol your FIDO2-compatible hardware token. You may also enrol a passphrase, or use both (recommended for maximum protection). The wrapped key is stored in the JSON state file. ### Step 4 — Configure and Lock Your Dataset Configure the encrypted ZFS dataset to remain locked at boot. Set up service-start checks so that dependent services only start after the dataset is unlocked. Optionally configure delayed forced locking and lock-time snapshots. ### Step 5 — Unlock at Operator Request To unlock the dataset, present your FIDO2 token (and passphrase if configured). The transient ZFS key is materialised in `malloc-backed md(4)` (FreeBSD) or `ramfs` (Linux), the dataset is unlocked, and the key is immediately wiped. Dependent services may then start. --- ## FAQ **What does eZFS2FA+ protect against?** It protects against a powered-off machine being lost, stolen, or imaged. The ZFS dataset cannot be decrypted without physical possession of the enrolled FIDO2 hardware token and (if configured) the passphrase. **What does eZFS2FA+ NOT protect against?** It does not protect against a live, fully compromised root or kernel at the time of unlock. If an attacker has root access while you are unlocking the dataset, the key can be extracted from memory. **Why is FreeBSD the first-class platform?** eZFS2FA+ uses FreeBSD's `mdmfs -M` (malloc-backed `md(4)`) for transient key storage, a native primitive with superior memory isolation guarantees. Linux support uses `ramfs` as a compatible alternative, but FreeBSD's primitives are used where they exist rather than pretending the two systems are interchangeable. **How is the ZFS encryption key kept secure during unlock?** The raw ZFS key is materialised only in malloc-backed `md(4)` memory (FreeBSD) or `ramfs` (Linux) — never in normal filesystems or swappable memory. It is wiped immediately after use and never touches hard storage at any point. **Can I use eZFS2FA+ with multiple hardware tokens?** Yes. eZFS2FA+ supports multiple enrolled FIDO2 keys. Any one of the enrolled tokens can be used to unlock the dataset, enabling backup-key workflows. **What is the zero lock-in principle?** The raw ZFS encryption key can be backed up independently of eZFS2FA+. If you back it up securely offline, you can decrypt your dataset with standard ZFS tools without eZFS2FA+ at any time. The framework is optional, not mandatory. **What is the JSON state file?** A single JSON file that stores the wrapped (encrypted) copies of the ZFS key for each enrolled token. This file can be backed up for disaster recovery. The raw key is never stored — only the wrapped form. **What is Pi-BSD and why was it used?** Pi-BSD is a FreeBSD system for Raspberry Pi and compatible single-board computers. Billie Badin developed eZFS2FA+ on a Pi-BSD installation running on an untethered battery-powered stack — a deliberate, minimal, hand-built environment. **Can I use a passphrase instead of a hardware token?** Yes. eZFS2FA+ supports passphrase-only wrapping, FIDO2-token-only wrapping, or both combined (recommended). Using both maximises security by requiring physical token presence and knowledge of the passphrase. **Is eZFS2FA+ suitable for removable or mirrored media?** Support for encrypted ZFS removable media (including mirrored configurations) is listed as coming soon. Proxmox Server Solutions integration is also in progress. --- ## Glossary | Term | Definition | |------|------------| | [FIDO2](https://linkeddata.uriburner.com/describe/?url=https%3A//fidoalliance.org/fido2/) | Open authentication standard enabling hardware-token-based authentication. In eZFS2FA+, a FIDO2 token wraps the ZFS encryption key. | | [mdmfs -M](https://linkeddata.uriburner.com/describe/?url=https%3A//man.freebsd.org/cgi/man.cgi%3Fquery%3Dmdmfs) | FreeBSD command creating a malloc-backed memory filesystem. Non-swappable, non-persistent — ideal for transient cryptographic key storage. | | [OpenZFS](https://linkeddata.uriburner.com/describe/?url=https%3A//openzfs.org/) | Open-source ZFS filesystem with native encryption. eZFS2FA+ secures OpenZFS-encrypted datasets by wrapping their keys with FIDO2 tokens. | | ramfs | Linux in-memory filesystem that cannot be swapped. Used by eZFS2FA+ on Linux for transient key storage, analogous to `mdmfs -M` on FreeBSD. | | Wrapped Key | A ZFS key encrypted by a FIDO2 token or passphrase. Stored safely in the JSON state file; raw key only recoverable by presenting the original credential. | | Transient Key Material | The raw ZFS key in usable form, held only in volatile RAM during the unlock window and wiped immediately after use. | | Zero Lock-in | Design principle ensuring users can always recover their data without eZFS2FA+, by maintaining an offline backup of the raw ZFS key. | | Threat Model | Formal statement of what a security system protects against. eZFS2FA+: offline attack protection, not live root compromise protection. | | MFA | Multi-Factor Authentication — two or more independent credentials (something you have + something you know). | | [Pi-BSD](https://linkeddata.uriburner.com/describe/?url=https%3A//www.freebsd.org/platforms/arm/) | FreeBSD for Raspberry Pi and ARM SBCs. Used as eZFS2FA+'s development platform — a deliberate, minimal, untethered stack. | | [Wabi-Sabi 侘寂](https://linkeddata.uriburner.com/describe/?url=https%3A//en.wikipedia.org/wiki/Wabi-sabi) | Japanese aesthetic philosophy of beauty through reduction and impermanence. Applied by Vivian Voss to characterise the hand-built, minimal nature of eZFS2FA+'s development approach. | --- ## Semantic Entities (URIBurner) - [eZFS2FA+ Software](https://linkeddata.uriburner.com/describe/?url=https%3A//github.com/BillieBadin/eZFS2FA) - [Billie Badin](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/billiesabouraud/) - [Vivian Voss](https://linkeddata.uriburner.com/describe/?url=https%3A//www.linkedin.com/in/vvoss/) - [FIDO2](https://linkeddata.uriburner.com/describe/?url=https%3A//fidoalliance.org/fido2/) - [OpenZFS](https://linkeddata.uriburner.com/describe/?url=https%3A//openzfs.org/) - [FreeBSD](https://linkeddata.uriburner.com/describe/?url=https%3A//www.freebsd.org/) - [Linux](https://linkeddata.uriburner.com/describe/?url=https%3A//www.kernel.org/) - [Yubico](https://linkeddata.uriburner.com/describe/?url=https%3A//www.yubico.com/) - [Pi-BSD / FreeBSD ARM](https://linkeddata.uriburner.com/describe/?url=https%3A//www.freebsd.org/platforms/arm/) - [mdmfs(8) FreeBSD manpage](https://linkeddata.uriburner.com/describe/?url=https%3A//man.freebsd.org/cgi/man.cgi%3Fquery%3Dmdmfs) --- ## Sources - [eZFS2FA+ GitHub Repository — Billie Badin / SIGORYX Engineering](https://github.com/BillieBadin/eZFS2FA) - [LinkedIn Post — Vivian Voss: "This is what FreeBSD-first looks like..."](https://www.linkedin.com/posts/vvoss_this-is-what-freebsd-first-looks-like-when-share-7459874878171693056-wqRH) - [LinkedIn — Billie Badin Profile](https://www.linkedin.com/in/billiesabouraud/) - [LinkedIn — Vivian Voss Profile](https://www.linkedin.com/in/vvoss/) - [RDF-Turtle Knowledge Graph](ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.ttl) - [HTML Infographic](ezfs2fa-freebsd-hardened-zfs-2fa-claude-sonnet-1.html) --- *Generated by [Claude (claude-sonnet-4-6)](https://linkeddata.uriburner.com/describe/?url=https%3A//claude.ai) via [Cowork desktop](https://linkeddata.uriburner.com/describe/?url=https%3A//claude.ai/cowork) · Entity links via [URIBurner](https://linkeddata.uriburner.com/fct) powered by [Virtuoso](https://virtuoso.openlinksw.com) · kg-generator, rdf-infographic-skill*