Skip to content

Instantly share code, notes, and snippets.

Last active June 19, 2024 19:57
Show Gist options
  • Save huntrar/e42aee630bee3295b2c671d098c81268 to your computer and use it in GitHub Desktop.
Save huntrar/e42aee630bee3295b2c671d098c81268 to your computer and use it in GitHub Desktop.
Arch Linux Full-Disk Encryption Installation Guide [Encrypted Boot, UEFI, NVMe, Evil Maid]

Arch Linux Full-Disk Encryption Installation Guide

This guide provides instructions for an Arch Linux installation featuring full-disk encryption via LVM on LUKS and an encrypted boot partition (GRUB) for UEFI systems.

Following the main installation are further instructions to harden against Evil Maid attacks via UEFI Secure Boot custom key enrollment and self-signed kernel and bootloader.


You will find most of this information pulled from the Arch Wiki and other resources linked thereof.

Note: The system was installed on an NVMe SSD, substitute /dev/nvme0nX with /dev/sdX or your device as needed.


Connect to the internet

Plug in your Ethernet and go, or for wireless consult the all-knowing Arch Wiki.

Update the system clock

timedatectl set-ntp true

Preparing the disk

Create EFI System and Linux LUKS partitions

Create a 1MiB BIOS boot partition at start just in case it is ever needed in the future
Number Start (sector) End (sector) Size Code Name
1 2048 4095 1024.0 KiB EF02 BIOS boot partition
2 4096 1130495 550.0 MiB EF00 EFI System
3 1130496 976773134 465.2 GiB 8309 Linux LUKS

gdisk /dev/nvme0n1


Create the LUKS1 encrypted container on the Linux LUKS partition (GRUB does not support LUKS2 as of May 2019)

cryptsetup luksFormat --type luks1 --use-random -S 1 -s 512 -h sha512 -i 5000 /dev/nvme0n1p3

Open the container (decrypt it and make available at /dev/mapper/cryptlvm)

cryptsetup open /dev/nvme0n1p3 cryptlvm

Preparing the logical volumes

Create physical volume on top of the opened LUKS container

pvcreate /dev/mapper/cryptlvm

Create the volume group and add physical volume to it

vgcreate vg /dev/mapper/cryptlvm

Create logical volumes on the volume group for swap, root, and home

lvcreate -L 8G vg -n swap
lvcreate -L 32G vg -n root
lvcreate -l 100%FREE vg -n home

The size of the swap and root partitions are a matter of personal preference.

Format filesystems on each logical volume

mkfs.ext4 /dev/vg/root
mkfs.ext4 /dev/vg/home
mkswap /dev/vg/swap

Mount filesystems

mount /dev/vg/root /mnt
mkdir /mnt/home
mount /dev/vg/home /mnt/home
swapon /dev/vg/swap

Preparing the EFI partition

Create FAT32 filesystem on the EFI system partition

mkfs.fat -F32 /dev/nvme0n1p2

Create mountpoint for EFI system partition at /efi for compatibility with grub-install and mount it

mkdir /mnt/efi
mount /dev/nvme0n1p2 /mnt/efi


Install necessary packages

pacstrap /mnt base linux linux-firmware mkinitcpio lvm2 vi dhcpcd wpa_supplicant

Configure the system

Generate an fstab file

genfstab -U /mnt >> /mnt/etc/fstab

(optional) Change relatime option to noatime


# /dev/mapper/vg-root
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 rw,noatime 0 1

# /dev/mapper/vg-home
UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx / ext4 rw,noatime 0 1

Reduces writes to disk when reading from a file, but may cause issues with programs that rely on file access time

Enter new system chroot

arch-chroot /mnt

At this point you should have the following partitions and logical volumes:


nvme0n1 259:0 0 465.8G 0 disk
├─nvme0n1p1 259:4 0 1M 0 part
├─nvme0n1p2 259:5 0 550M 0 part /efi
├─nvme0n1p3 259:6 0 465.2G 0 part
..└─cryptlvm 254:0 0 465.2G 0 crypt
....├─vg-swap 254:1 0 8G 0 lvm [SWAP]
....├─vg-root 254:2 0 32G 0 lvm /
....└─vg-home 254:3 0 425.2G 0 lvm /home

Time zone

Set the time zone

Replace America/Los_Angeles with your respective timezone found in /usr/share/zoneinfo

ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

Run hwclock to generate /etc/adjtime

Assumes hardware clock is set to UTC

hwclock --systohc


Uncomment en_US.UTF-8 UTF-8 in /etc/locale.gen and generate locale


Create locale.conf and set the LANG variable



Network configuration

Create the hostname file



This is a unique name for identifying your machine on a network.

Add matching entries to hosts

/etc/hosts localhost
::1 localhost myhostname.localdomain myhostname


Add the keyboard, encrypt, and lvm2 hooks to /etc/mkinitcpio.conf

Note: ordering matters.

HOOKS=(base udev autodetect keyboard modconf block encrypt lvm2 filesystems fsck)

Recreate the initramfs image

mkinitcpio -p linux

Root password

Set the root password


Boot loader

Install GRUB

pacman -S grub

Configure GRUB to allow booting from /boot on a LUKS1 encrypted partition



Set kernel parameter to unlock the LVM physical volume at boot using encrypt hook

UUID is the partition containing the LUKS container


/dev/nvme0n1p3: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="crypto_LUKS" PARTLABEL="Linux LUKS" PARTUUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"


GRUB_CMDLINE_LINUX="... cryptdevice=UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx:cryptlvm root=/dev/vg/root ..."

Install GRUB to the mounted ESP for UEFI booting

pacman -S efibootmgr
grub-install --target=x86_64-efi --efi-directory=/efi

Enable microcode updates

grub-mkconfig will automatically detect microcode updates and configure appropriately
pacman -S intel-ucode

Use intel-ucode for Intel CPUs and amd-ucode for AMD CPUs.

Generate GRUB's configuration file

grub-mkconfig -o /boot/grub/grub.cfg

(recommended) Embed a keyfile in initramfs

This is done to avoid having to enter the encryption passphrase twice (once for GRUB, once for initramfs.)

Create a keyfile and add it as LUKS key

mkdir /root/secrets && chmod 700 /root/secrets
head -c 64 /dev/urandom > /root/secrets/crypto_keyfile.bin && chmod 600 /root/secrets/crypto_keyfile.bin
cryptsetup -v luksAddKey -i 1 /dev/nvme0n1p3 /root/secrets/crypto_keyfile.bin

Add the keyfile to the initramfs image



Recreate the initramfs image

mkinitcpio -p linux

Set kernel parameters to unlock the LUKS partition with the keyfile using encrypt hook


GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/secrets/crypto_keyfile.bin"

Regenerate GRUB's configuration file

grub-mkconfig -o /boot/grub/grub.cfg

Restrict /boot permissions

chmod 700 /boot

The installation is now complete. Exit the chroot and reboot.



Your system should now be fully installed, bootable, and fully encrypted.

If you embedded the keyfile in the initramfs image, it should only require your encryption passphrase once to unlock to the system.

For the standard Arch Linux post-installation steps, RTFM.

(recommended) Hardening against Evil Maid attacks

With an encrypted boot partition, nobody can see or modify your kernel image or initramfs, but you would be still vulnerable to Evil Maid attacks.

One possible solution is to use UEFI Secure Boot. Get rid of preloaded Secure Boot keys (you really don't want to trust Microsoft and OEM), enroll your own Secure Boot keys and sign the GRUB boot loader with your keys. Evil Maid would be unable to boot modified boot loader (not signed by your keys) and the attack is prevented.

Creating keys

The following steps should be performed as the root user, with accompanying files stored in the /root directory.

Install efitools
pacman -S efitools
Create a GUID for owner identification
uuidgen --random > GUID.txt
Platform key

CN is a Common Name, which can be written as anything.

openssl req -newkey rsa:4096 -nodes -keyout PK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" PK.crt PK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt PK PK.esl PK.auth
Sign an empty file to allow removing Platform Key when in "User Mode"
sign-efi-sig-list -g "$(< GUID.txt)" -c PK.crt -k PK.key PK /dev/null rm_PK.auth
Key Exchange Key
openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
Signature Database key
openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=my Signature Database key/" -out db.crt
openssl x509 -outform DER -in db.crt -out db.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" db.crt db.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k KEK.key -c KEK.crt db db.esl db.auth

Signing bootloader and kernel

When Secure Boot is active (i.e. in "User Mode") you will only be able to launch signed binaries, so you need to sign your kernel and boot loader.

Install sbsigntools

pacman -S sbsigntools
sbsign --key db.key --cert db.crt --output /boot/vmlinuz-linux /boot/vmlinuz-linux
sbsign --key db.key --cert db.crt --output /efi/EFI/arch/grubx64.efi /efi/EFI/arch/grubx64.efi
Automatically sign bootloader and kernel on install and updates

It is necessary to sign GRUB with your UEFI Secure Boot keys every time the system is updated via pacman. This can be accomplished with a pacman hook.

Create the hooks directory

mkdir -p /etc/pacman.d/hooks

Create hooks for both the linux and grub packages


Operation = Install
Operation = Upgrade
Type = Package
Target = linux

Description = Signing Kernel for SecureBoot
When = PostTransaction
Exec = /usr/bin/find /boot/ -maxdepth 1 -name 'vmlinuz-*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key /root/db.key --cert /root/db.crt --output {} {}; fi' \ ;
Depends = sbsigntools
Depends = findutils
Depends = grep


Operation = Install
Operation = Upgrade
Type = Package
Target = grub

Description = Signing GRUB for SecureBoot
When = PostTransaction
Exec = /usr/bin/find /efi/ -name 'grubx64*' -exec /usr/bin/sh -c 'if ! /usr/bin/sbverify --list {} 2>/dev/null | /usr/bin/grep -q "signature certificates"; then /usr/bin/sbsign --key /root/db.key --cert /root/db.crt --output {} {}; fi' \ ;
Depends = sbsigntools
Depends = findutils
Depends = grep

Enroll keys in firmware

Copy all *.cer, *.esl, *.auth to the EFI system partition
cp /root/*.cer /root/*.esl /root/*.auth /efi/
Boot into UEFI firmware setup utility (frequently but incorrectly referred to as "BIOS")
systemctl reboot --firmware

Firmwares have various different interfaces, see Replacing Keys Using Your Firmware's Setup Utility if the following instructions are unclear or unsuccessful.

Set OS Type to Windows UEFI mode

Find the Secure Boot options and set OS Type to Windows UEFI mode (yes, even if we're not on Windows.) This may be necessary for Secure Boot to function.

Clear preloaded Secure Boot keys

Using Key Management, clear all preloaded Secure Boot keys (Microsoft and OEM).

By clearing all Secure Boot keys, you will enter into Setup Mode (so you can enroll your own Secure Boot keys).

Set or append the new keys

The keys must be set in the following order:

db => KEK => PK

This is due to some systems exiting setup mode as soon as a PK is entered.

Do not load the factory defaults, instead navigate the available filesystems in search of the files previously copied to the EFI System partition.

Choose any of the formats. The firmware should prompt you to enter the type (Note: type names may differ slightly.)

*.cer is a Public Key Certificate
*.esl is a UEFI Secure Variable
*.auth is an Authenticated Variable

Certain firmware (such as my own) require you use the *.auth files. Try various ones until they work.

Set UEFI supervisor (administrator) password

You must also set your UEFI firmware supervisor (administrator) password in the Security settings, so nobody can simply boot into UEFI setup utility and turn off Secure Boot.

You should never use the same UEFI firmware supervisor password as your encryption password, because on some old laptops, the supervisor password could be recovered as plaintext from the EEPROM chip.

Exit and save changes

Once you've loaded all three keys and set your supervisor password, hit F10 to exit and save your changes.

If everything was done properly, your boot loader should appear on reboot.

Check if Secure Boot was enabled

od -An -t u1 /sys/firmware/efi/efivars/SecureBoot-XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

The characters denoted by XXXX differ from machine to machine. To help with this, you can use tab completion or list the EFI variables.

If Secure Boot is enabled, this command returns 1 as the final integer in a list of five, for example:

6 0 0 0 1

If Secure Boot was enabled and your UEFI supervisor password set, you may now consider yourself protected against Evil Maid attacks.

Copy link

mohemiv commented Jul 7, 2022

Great manual! I always recommend it when someone asks me about Full-Disk Encryption.

However, there is a small issue in this configuration. It accrues when a large number of iterations is set for the user's password.

For example, if you set the number of iterations to 40,000,000, it may take 1 minute for GRUB to decrypt the master key. But after the master key has been decrypted, Linux will spend 1 minute again when using crypto_keyfile.bin, when it's not needed. And if you swap the keys for the user's password and crypto_keyfile.bin, it won't change anything.

Somehow, it's needed to specify to the Linux kernel which key slot to use, but I don't see any options for it.

Copy link

r3m8 commented Sep 3, 2022

Thanks for this tutorial ! But it doesn't work with Secure Boot from June 2022 due to grub update (commit 6fe755c5c07bb386fda58306bfd19e4a1c974c53, since grub version 2.06.r261.g2f4430cc0). Here's how to fix "error: prohibited by secure boot policy" even you have successfully enrolled custom keys (without downgrading grub package for keep security updates) :

  1. Set GRUB_MODULES variable to load necessary modules (select only the needed modules for your archlinux installation for best security and lower bootloader size, but you can leave as default). You can find other supported modules in /usr/lib/grub/x86_64-efi/

GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo cpuid play tpm cryptodisk gcry_arcfour gcry_blowfish gcry_camellia gcry_cast5 gcry_crc gcry_des gcry_dsa gcry_idea gcry_md4 gcry_md5 gcry_rfc2268 gcry_rijndael gcry_rmd160 gcry_rsa gcry_seed gcry_serpent gcry_sha1 gcry_sha256 gcry_sha512 gcry_tiger gcry_twofish gcry_whirlpool luks lvm mdraid09 mdraid1x raid5rec raid6rec"

  1. (Re-)Generate bootloader and add modules list plus disable shim lock (or you get error shim lock protocol no found) :

grub-install --target=x86_64-efi --efi-directory=/efi --modules="${GRUB_MODULES}" --disable-shim-lock

  1. Don't forget to sign new bootloader (and configure pacman hook)

sbsign --key db.key --cert db.crt --output /efi/EFI/arch/grubx64.efi /efi/EFI/arch/grubx64.efi

This is no really a bug (report here) but a security "required" functionality. Archlinux guide confirm that "since grub version 2.06.r261.g2f4430cc0", corresponding to commit mentioned upper (published 08-Jun-2022 15:22 on official arch repo).

Committer say "We must not allow other verifiers to pass things like the GRUB modules". So you need to set yourself all modules needed (best security effort btw). Anyway, you can use shim if you want (but probably less security because you must trust Microsoft keys and more complex configuration).

This work on linux-hardened kernel, grub2 version 2.06.r322.gd9b4638c5-3, with SecureBoot enabled).

@huntrar which method do you prefer/recommand to update this page ? (downgrading grub, disable shim lock, use shim, load necessary modules..)

Copy link

100ze commented Oct 23, 2022

Amazing guide! But I believe GRUB supports LUKS 2 now.

No, it doesn't.

Copy link

Chris98 commented Nov 26, 2022

@r3m8 this no longer seems to be working unfortunately. I'm getting the error that "verification requested but nobody cares" even when including every single module.

This was the only thing which worked for me:

Not a great fix and unsure of what long-term compatibility it might affect but at least it's something. I'm wondering now whether it's something as trivial as with the signing keys and the authority behind them as to why Grub isn't picking up that SecureBoot is enabled properly.

Copy link

mohemiv commented Nov 26, 2022

@huntrar Please consider updating the guide.

Copy link

0rteip commented Dec 2, 2022

I followd the guide and everythings works fine, except for the keyfile: After grub It says that Is impossible to dead the keyfile, and ask for the passphrase, can someone helps me?

Copy link

Great guide, thanks ! BUT, DONT DO THIS : cp /root/*.cer /root/*.esl /root/*.auth /efi/

From ArchLinux wiki :

Warning: Do not copy the noPK.auth file to the EFI system partition (ESP) of your PC! If you do this, and someone e.g. steals your PC, this person can delete the personal Platform Key in the UEFI Secure Boot firmware again, turn on "Setup Mode" on your PC again and replace your Secure Boot Keys (PK, KEK, db, dbx) with his or her own Platform Key, thereby defeating the whole purpose of UEFI Secure Boot. Only you should be able to replace the Platform Key, so only you should have access to the noPK.auth file.

noPK.auth == rm_PK.auth

If you copied it to your /efi partition already, don't simply rm it, use shred -u /efi/rm_PK.auth.

Also, signing the kernel following this guide is pretty much useless because its signature is not checked by grub. Plus, the initrd is not signed.
Take a look at if you want to do so.

Copy link

Chris98 commented Dec 3, 2022

One good workaround for this would be to generate a CA certificate somewhere on your PC and use it to sign all your SecureBoot certificates prior to the signing. The attacker would then need to know your CA as well in order to correctly generate a new key and sign the bootloader correctly. Which, if encrypted on your hard drive for instance, they wouldn't be able to find.

But yes, I understand what you're saying. Surely however you can just move the files off the hard drive back to the encrypted disk, rather than deleting them?

Copy link

This guide makes you generate rm_PK.auth on your encrypted partition, so you still have a copy of it somewhere, that's why I suggest to completely remove it from the /efi partition. I personally backed it up on an external hard drive, encrypted using my own gpg key.

Copy link

r3m8 commented Dec 3, 2022

I don't see any problems about generate authorities and certificates on your encrypted partition ; only if the attacker has the encryption password, in theory, he can access to the CA files. In the case where you delete all files on your encrypted disk with rm, attacker have a very small chance to get CA files with disk forensics if no much data isn't overwritten at multiples times (use shred instead).

If you have copy CA files on the EFI partition, i'm agree with @ShellCode33 , you must delete files securely with shred -uz -n 7.

The best solution for me is to save all your authorities and other certificates on another external storage using encryption like GPG and AES (the mixture of symmetrical and asymmetrical is a good thing) even through the more secure way (not stable actually) is For safety, save all this data with 2 or more samples and put them in a secure and hidden vault. After that, you can use shred on your encrypted partition to definitively delete CA files on your computer.

Copy link

Chris98 commented Dec 3, 2022

That scenario above was mainly for simplicity as an example. I think if you're using a CA, you're probably more likely to be a corporate business or have many Linux installations rather than just one. That's really where a CA could become most powerful, I think - assuming the keys are stored securely etc.

I also agree that the best solution would really be to keep any CA keys in a completely different place. Even better would be to isolate all your CA keys on a separate machine to begin with specifically for crypto, and never move them off there, but again this is more for corporates I think. Just doing all this for a single personal computer depends upon how much you want it secured I suppose.

Copy link

schm1d commented Dec 29, 2022

I have a fully automated script on my repo, very close to your steps.

Copy link

Iwwww commented Mar 1, 2023

I've written a step-by-step guide essentially on how to enable hibernation with this setup:

Copy link

beune commented Mar 14, 2023

I followed this guide. However, whenever I want to reboot systemd fails to unmount /home, and after the reboot I am dropped into an emergency shell. The temporary fix for me, is to boot to a live arch ISO, mount the encrypted partitions, install grub, run grub-mkconfig -o and regenerate initramfs (mkinitcpio -p linux). After that, I can boot into the system just fine. However, I don't want to be doing this everytime I want to restart my machine. Is there a fix for this?

Copy link

Take note that you may encounter issues after a certain GRUB version. See here for info about why:

Copy link

sla-te commented Jun 8, 2023

Thanks for the thorough guide @huntrar


I've written a step-by-step guide essentially on how to enable hibernation with this setup:

If i put, what you put in modules, I get "module not found" for all of these. why do we have to put it to modules in addition to hooks? you have amdgpu in there too ig, that one depends on which gpu you are using.

Copy link

I follod this guide until the GRUB install,
grub-install --target=x86_64-efi --efi-directory=/efi
which left me with the
'Installing for x86_64-efi platform.
grub-install: error: unknown filesystem.'
Until now I found no working fix, do you have any ideas?
THank you in advance!

Copy link

tjex commented Jun 29, 2023

'Installing for x86_64-efi platform.
grub-install: error: unknown filesystem.'

I was also getting this during two installation attempts. The only time I didn't get this error was when I used fdisk to partition, instead of parted. I haven't tried gdisk but could be a similar case.

I've all but given up on encrypted install for now. I've tried multiple times and each time grub says I'm giving it an incorrect password. Which is not true, as others have also recently found.

Really seems like grub and LUKS are not playing nicely :(

Copy link

philbur2 commented Jun 30, 2023

'Installing for x86_64-efi platform.
grub-install: error: unknown filesystem.'

I was also getting this during two installation attempts. The only time I didn't get this error was when I used fdisk to partition, instead of parted. I haven't tried gdisk but could be a similar case.

I've all but given up on encrypted install for now. I've tried multiple times and each time grub says I'm giving it an incorrect password. Which is not true, as others have also recently found.

Really seems like grub and LUKS are not playing nicely :(

I finally got it to work, using this, gentoo wizards saved me:

tune2fs -O metadata_csum_seed /dev/device

did the trick.

Copy link

tjex commented Jun 30, 2023

I also tried that, but to no avail. But have seen it worked for a few.
Finally got it working. The other missing part to the puzzle was to include the --type luks1 flag when running luksFormat on the partition. Grub is not compatible in all cases with luks2 (the default value in luksFormat), as has also been reported around the place.

Copy link

gavsiu commented Aug 28, 2023

Finally figured out how to enable Secure Boot after GRUB made it difficult with the update.

I ended up ditching GRUB and just boot straight from UEFI using a signed Unified Kernel Image. Skip creating and embedding the keyfile also. I used sbctl to make my life easier with creating and signing keys.

Copy link

ShellCode33 commented Aug 28, 2023

@gavsiu that's the way to go. GRUB is overrated IMO, it's not necessary at all. I invite people to take a look at arch-secure-boot. Booting directly into a UKI also allows you to use LUKS2, which is not supported by GRUB yet.

Copy link

gavsiu commented Aug 28, 2023

Passphrase decryption seems way faster than before when I was booting with GRUB.

Copy link

True, that's because the UKI uses hardware acceleration

Copy link

bsl commented Apr 28, 2024

Grub 2.12 supports LUKS2. But if we do cryptsetup luksFormat device, this defaults to LUKS2 with --pbkdf argon2id, but Grub doesn't support that PBKDF. But you can still use LUKS2 with Grub by doing something like cryptsetup luksFormat --pbkdf pbkdf2 device.

The docs for Grub are here, and it's helpful to look at the compiled defaults of cryptsetup via cryptsetup --help and looking for "Default" near the bottom of the output.

Copy link

Could you explain how secure boot protects against an evil maid with physical access? If you can modify your trusted keys, so can an attacker.

Copy link

ShellCode33 commented May 24, 2024

It's only a matter of slowing down the attacker, by setting a password to the BIOS, you considerably slow them down because they would have to open the computer and remove the battery on the motherboard to reset the password, it's very inconvenient and can be time consuming (especially on laptops where the battery is usually on the back of the MB and you have to unscrew almost everything). Whereas if secure boot was not enabled, it would only be a matter of accessing the drive (which is usually way easier to do, especially on laptops) to alter the EFI partition. So you're right it doesn't protect you 100%. One interesting feature that some manufacturers provide (e.g. Dell) is the ability to detect if the device has been physically tempered with, it doesn't prevent the attack but at least you can be informed that it occurred (as long as you have the proper runtime checks, I guess it can be accessed through UEFI variables exposed by the OS)

Copy link

I agree, however if your BIOS password also blocks booting at all, then secure boot doesn't offer more protection against that kind of attack. But if the password blocks only the UEFI settings, then I guess secure boot does help a bit.

Copy link

Chris98 commented May 24, 2024 via email

Copy link

lucas-mior commented Jun 18, 2024

@ShellCode33 an addendum: If the attacker removes the firmware battery and doing so disables your password, 2 things may happen:
A) You will get no password prompt, so you will know that your computer is compromised.
B) He will set a password different from yours so you will not be able to boot. Then you will know your computer is compromised (just like case A).

So you should be safe either way. Not against all kinds of hardware manipulation (e.g keylogger) or against a hidden camera.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment