Disk encryption on NetBSD – achieving secrecy

The NetBSD project published an architecture guide detailing practical disk encryption techniques designed to protect confidential data on lost or stolen computers. As detailed in netbsd.org's report, the design establishes cryptographic secrecy without requiring specialized hardware or complex custom bootloaders by isolating sensitive partitions behind the native cryptographic device driver. The technique avoids fragile boot procedures while securing all user data, configuration records, and system memory state.

This report breaks down the partitioning workflow, threat modeling, cipher selection, and post-installation storage layout for system administrators securing NetBSD desktop and server installations. It evaluates which system directories require cryptographic isolation, how hardware-accelerated algorithms compare to software ciphers like Adiantum, and how engineers can configure standard disklabel partitions to enforce confidentiality against physical theft.

01Threat models and base system separation

Disk encryption on NetBSD targets a threat model where physical hardware is lost or stolen and its contents must remain secret. Protecting hardware against physical tampering requires specialized verification mechanisms that render devices unusable, but data secrecy focuses strictly on preventing unauthorized data extraction. NetBSD systems simplify this boundary by cleanly isolating immutable open source base system components from user-modified files.

Standard operating system binaries such as the standard shell binary in /bin/sh originate directly from NetBSD FTP distribution servers and contain no confidential data. Because the platform separates core base packages from third-party software, directories on the root filesystem remain unchanged outside administrative system upgrades. Administrators can even mark these public system directories read-only without interrupting standard execution flows.

System security boundaries benefit from running daemons and client software under unprivileged user accounts rather than root permissions. Because non-root programs lack permissions to create or alter executables located in the primary /bin directory, unmodified binaries carry zero device-specific secrets. Consequently, defensive storage architectures can safely leave public binary distributions unencrypted without expanding exposure to data loss.

02Bootloader constraints and cipher performance

Booting an operating system requires unencrypted bootstrap code so the machine can read files before user authentication. True full disk encryption without specialized hardware remains difficult because the kernel must execute software to accept a password and compute the corresponding cryptographic key. NetBSD systems must also store partition metadata on disk to derive secure 256-bit encryption keys from 24-character passphrases.

Unix systems rely on shared runtime libraries located in /usr/lib to provide shared system functionality to running applications. If an administrative error or corrupted partition makes dynamic libraries inaccessible during boot, recovery becomes significantly harder. Administrators should rely on the statically linked rescue utilities in /rescue, which operate independently without dynamic libraries during emergency restoration procedures.

Standardized government cryptographic algorithms frequently incur steep execution penalties when executed entirely within software routines. Modern processors mitigate this latency by embedding hardware acceleration instructions for ciphers like AES directly onto the silicon. Systems powered by hardware lacking native acceleration instructions can instead deploy alternative ciphers such as Adiantum to preserve storage throughput.

03Sensitive directories and middle ground partitioning

Normal system operations continually update a distinct set of directories that store sensitive user and system information. The /home path contains private personal files, while the /root hierarchy holds configuration data for administrative accounts. Meanwhile, /var maintains system logs, mail notifications, and system databases, while /usr/pkg and /usr/local host installed third-party programs.

Encrypting only the /home partition leaves critical operational data exposed across default system paths. Crash dumps written to disk capture full snapshots of system memory containing active credentials, though administrators can redirect this directory using sysctl. Furthermore, local mail files regarding interrupted editing sessions can expose confidential filenames, while unencrypted server logs leak traffic patterns.

While the cgdroot configuration uses an unencrypted ramdisk to mount an encrypted root, it alters standard startup scripts and complicates system rescues. NetBSD offers a practical middle ground through standard installer configurations that split /usr and /var into isolated partitions. System files in /etc retain hashed passwords, while sensitive Wi-Fi and VPN secrets can point via symlinks to encrypted storage.

04Minimal root partition and installer sizing

The standard NetBSD installer provisions a compact unencrypted root filesystem while dedicating the remaining storage to encrypted partitions. Excluding variable growth directories like /home, /var, and /usr allows a complete NetBSD installation with development tools to occupy very little space. A dedicated root allocation of 4 GB provides ample headroom for base system operations.

During the installation walkthrough on a sparc64 virtual machine, the installer scans existing drive configurations before administrators select the option to delete existing disks. Administrators then access the manual partition sizing interface to split the drive between unencrypted base files and protected application storage. The same partitioning sequence applies directly to mainstream hardware architectures like amd64.

The partition layout defines a 4096 MB root partition alongside an 11263 MB secondary partition initially reserved for /var. In the partition editor, the administrator changes the secondary partition filesystem type to cgd, representing NetBSD's cryptographic device driver, and sets its mount point to a dash. Selecting the full installation option then populates the base system into the unencrypted root.

05Cryptographic device driver setup and verification

Systems utilizing traditional disklabel partitioning expose the primary disk as wd0 and designate the encrypted slice as /dev/wd0d. Administrators create a cryptographic parameter profile by executing cgdconfig with the argon2id key derivation function, generating an adiantum cipher configuration with a 256-bit key stored at /etc/cgd/wd0d. Running cgdconfig then attaches the cgd0 virtual device and prompts for password entry.

The kernel transparently encrypts and decrypts all traffic passing through the configured cgd0 device. To verify passwords upon boot, administrators write an internal disklabel directly to the encrypted container using the interactive disklabel utility. The editor assigns an internal label identifier, sets the partition offset to zero, and allocates all remaining capacity with the dollar sign notation.

Testing environments running NetBSD-current can format the sub-partition using the 4.4LFS log file system with the newfs_lfs utility. Production systems more commonly adopt 4.2BSD or format the device as FFSv2ea using the newfs utility. Updating /etc/cgd/wd0d with the disklabel verification method and registering the partition in /etc/cgd/cgd.conf automatically attaches the encrypted volume across system reboots.