Install OpenBSD with Full-Disk Encryption

Synopsis #

OpenBSD implements bootable disk encryption with the CRYPTO discipline of softraid(4) . The encrypted volume appears as another sd device. The installer places the OpenBSD filesystems on that virtual disk while the unencrypted physical disk contains the partitioning and softraid metadata needed to start the boot process.

This procedure destroys the selected disk. It uses an amd64 or another architecture on which CRYPTO volumes are bootable. Confirm boot support in softraid(4) and read the platform’s INSTALL.<arch> file before starting.

Disk names in this guide are examples only. The target disk, installation media, and new softraid volume can receive different device numbers on every system.

Before Starting #

Prepare verified OpenBSD installation media and a tested backup. Record the existing disk layout and keep the recovery media available after installation.

This example assumes:

  • sd0 is the disk that will be erased and encrypted;
  • sd1 is the installation media;
  • sd2 will become the new CRYPTO volume;
  • sd3 is an optional, separate keydisk used only in the alternative procedure;
  • the system boots with UEFI.

At the installer menu, select (S)hell. Display the disks with sysctl(8) , dmesg(8) , disklabel(8) , and fdisk(8) .

# sysctl hw.disknames
  # List disk names and disklabel UIDs
# dmesg | grep '^sd'
  # Match each disk to its size and attachment
# disklabel sd0
  # Inspect the proposed target before changing it
# fdisk sd0
  # Inspect its outer partition table

Stop if the target cannot be identified unambiguously.

Prepare the Physical Disk #

Create any missing device nodes in the install environment. Include the expected virtual disk and any removable media in the MAKEDEV(8) command.

# cd /dev
  # Work in the device directory
# sh MAKEDEV sd0 sd1 sd2 sd3
  # Create nodes for the target, media, expected virtual disk, and optional keydisk

For a UEFI installation, initialize the target with a GPT layout that reserves boot space. For legacy MBR boot, use the platform-appropriate fdisk procedure instead.

# fdisk -gy -b 532480 sd0

Create one disklabel partition of type RAID on the target. The interactive editor displays the actual offset and size; accept only values that keep the partition inside the OpenBSD area.

# disklabel -E sd0
Label editor (enter '?' for help at any prompt)
sd0> a a
offset: [default]
size: [default] *
FS type: [4.2BSD] RAID
sd0*> w
sd0> q

Inspect the result before continuing:

# disklabel sd0

The a partition must have filesystem type RAID. This is the final checkpoint before encrypted-volume creation.

Create the CRYPTO Volume #

Use bioctl(8) to create a CRYPTO volume on the RAID partition:

# bioctl -c C -l sd0a softraid0

Enter a strong passphrase when prompted. Loss of this passphrase makes the encrypted data unrecoverable.

The command reports the new virtual disk name. This example assumes sd2; use the name printed on the actual system. Verify both the physical and virtual devices:

# bioctl sd2
  # Confirm the discipline and online state
# disklabel sd2
  # Confirm that the new virtual disk is the expected size

New encrypted volumes contain random-looking data. Clear only the first megabyte of the new virtual disk so the installer does not mistake that data for old partition metadata:

# dd if=/dev/zero of=/dev/rsd2c bs=1m count=1

This command must name the raw c partition of the new CRYPTO device, not the physical disk.

Install to the Virtual Disk #

Exit the shell and start the installer:

# exit

Select (I)nstall. When the installer asks which disk will contain the root filesystem, select the CRYPTO device reported by bioctl, sd2 in this example. Do not select sd0.

Complete partition allocation and installation normally. The installer creates filesystems and installs the boot loader on the correct layers. The installation chapter describes the remaining prompts.

Remove the installation media at the end of the installation and reboot. The boot loader should request the softraid passphrase before loading the kernel.

Verify the Installation #

Device numbers are assigned again during boot. After removing the installation media, the CRYPTO volume may no longer be sd2. Re-identify every disk before naming the assembled volume:

$ sysctl hw.disknames
  # List the post-boot disk names and disklabel UIDs
$ dmesg | grep '^sd'
  # Match the physical and softraid disks to their sizes and attachments
$ mount
  # Identify the sd device that contains the mounted root filesystem

Use that post-boot device name in the privileged checks. If mount reports root on sd1a, for example:

# bioctl sd1
  # Confirm the CRYPTO discipline and online state
$ sysctl hw.sensors.softraid0
  # Display any softraid sensor status

Record the physical disk, CRYPTO volume, disklabel UIDs, and recovery procedure outside the encrypted system.

Keydisk Alternative #

A keydisk can replace the boot passphrase. This changes the recovery model: the encrypted disk cannot start without the keydisk, and a lost or damaged keydisk can make the system unrecoverable.

The keydisk must be a separate device with a small partition of type RAID. Re-run the disk-identification checks before preparing it and confirm that it is neither the target nor the installation media. In this example, sd3a is the keydisk partition and sd0a is the encryption target.

Current OpenBSD uses the RAID partition directly as the keydisk. Create the CRYPTO volume with bioctl(8) :

# bioctl -c C -k /dev/sd3a -l /dev/sd0a softraid0

Keep an offline backup of the key material and test it before relying on the system. Follow the exact keydisk preparation, backup, and restore procedure in the OpenBSD FAQ disk-encryption section .

Recovery Planning #

Full-disk encryption protects data at rest. It does not replace backups, protect a running and unlocked system, or provide redundancy.

Maintain:

  • verified installation or recovery media;
  • the passphrase or keydisk recovery material in a protected location;
  • an off-host backup whose restore procedure has been tested;
  • the system’s disk and filesystem layout;
  • authorized console access for boot and recovery.

A CRYPTO volume must be unlocked before its filesystems can be inspected or repaired. Never run filesystem or boot-repair commands against a physical softraid chunk when the intended target is the assembled virtual disk.

See Storage and File Systems for disk naming, softraid concepts, backups, and filesystem recovery.

Report a bug