dm-crypt (Português)/Encrypting an entire system (Português)

From ArchWiki
Jump to navigation Jump to search

Tango-preferences-desktop-locale.pngEsse artigo ou seção precisa de tradução.Tango-preferences-desktop-locale.png

Notas: esta página está em tradução (Discuta na Talk:Dm-crypt (Português)/Encrypting an entire system (Português)#)

Os exemplos a seguir são cenários comuns de um sistema criptografado com dm-crypt. Eles explicam todas as adaptações que serão realizadas do processo de instalação. Todas as ferramentas necessárias estão disponíveis na imagem de instalação.

Contents

Visão geral

dm-crypt se destaca, tanto em funcionalidades quanto em velocidade, quando o assunto é proteger o sistema de arquivos principal. Diferente da encriptação seletiva de sistemas de arquivos secundários, a criptografia de todo um sistema pode proteger informações como quais programas estão instalados, os nomes de usuários de todas as contas, e vetores comuns de vazamento de dados tais como mlocate e /var/log. E, é bem mais difícil fazer alterações em um sistema criptografado, exceto o gerenciador de boot e (geralmente) o kernel que nao são criptografados.

Todos os cenários ilustrados a seguir compartilham as vantagens supracitadas, prós e contras que os diferenciam estão resumidos abaixo:

Cenários Vantagens Desvantagens
#LUKS em uma partição

Mostra uma configuração básica e direta para uma partição principal criptografada com LUKS.

  • Simples particionamento e configuração
  • Inflexível; o espaço em disco precisa ser alocado antes de criptografar
#LVM dentro do LUKS

Consegue flexibilidade no particionamento ao usar LVM dentro de uma partição criptografada com LUKS.

  • Simples particionamento se sabe como usar LVM
  • Somente uma chave para desbloquear todos os volumes (exemplo, configuração simples de resume-from-disk)
  • design de volumes não é visível quando bloqueado
  • Método mais fácil para suspensão para o disco
  • LVM adiciona mais uma camada adicional de mapeamento e hook
  • Menos útil, se um volume deve receber uma chave separada
#LUKS dentro do LVM

usa dm-crypt somente depois de configurar o LVM.

  • LVM pode ser usado para volumes criptografados em múltiplos discos
  • Fácil de usar com grupos de volumes criptografados ou não
  • Complexo; para mudar volumes precisa modificar também os mapeadores de encriptação
  • Volumes precisam de chaves individuais
  • design de volumes não é visível quando bloquead
#LUKS dentro do RAID de software

usa dm-crypt somente depois de configurar RAID.

  • Análogo ao LUKS dentro do LVM
  • Análogo ao LUKS dentro do LVM
#Plain dm-crypt

usa o modo plain dm-crypt, exemplo sem um cabeçalho LUKS e suas opções para múltiplas chaves.
Este cenário também permite que dispositivos USB possam ser usados no /boot e como depósito de chaves, que pode ser aplicado para outros cenários.

  • Necessário grande atenção a todos os parâmetros
  • Encriptação de chave única e sem opção de mudança
#Partição de boot criptografada (GRUB)

Mostra como criptografar a partição de boot usando o gerenciador de boot GRUB.
Este cenário também usa uma partição de sistema EFI, que pode ser aplicado para outros cenários.

  • Mesmas vantagens do cenário de instalação en que é baseado (LVM dentro do LUKS neste particular exemplo)
  • Menos dados são deixados sem criptografia, exemplo o gerenciador de boot e a partição de sistema EFI, se presente
  • Mesmas desvantagens do cenário de instalação en que é baseado (LVM dentro do LUKS neste particular exemplo)
  • Configuração mais complicada
  • Não é suportado por outros gerenciadores de boot
#Subvolumes do btrfs com swap

Mostra como criptografar um sistema Btrfs, incluindo o diretório /boot, também é possível adicionar uma partição para swap, em um hardware com suporte a UEFI.

Enquanto todos os cenários acima oferecem maior proteção contra ameaças externas do que somente criptografar sistemas de arquivos não raiz, eles também possuem uma desvantagem comum: qualquer usuário que possui a chave pode abrir todo o disco, e assim, acessar os dados de outro usuário. Se isto é uma preocupação, é possível fazer uma combinação de dispositivo de blocos e sistema de arquivos criptografados empilhados e adquirir as vantagens de ambos. Veja Encriptação de disco para lhe ajudar no planejamento.

Veja Dm-crypt/Preparando a unidade de armazenamento#Particionamento para uma visão geral das estratégias de particionamento usadas nos cenários.

Outra coisa a considerar é se deve usar uma partição swap criptografada e de qual forma. Veja Dm-crypt/Swap criptografada para alternativas.

Se você antecipa a proteção de dados do sistema não somente contra roubo físico, como também contra adulteração lógica, veja Dm-crypt/Especificidades#Protegendo a partição de boot não criptografada para possibilidades futuras após seguir um dos cenários.

Para SSDs, você pode considerar habilitar suporte ao TRIM, mas esteja ciente que, isto tem potenciais problemas de segurança. Veja Dm-crypt/Especificidades#Discard/Suporte ao TRIM para unidades de estado sólido (SSD) para mais informações.

Atenção:
  • Em qualquer cenário, nunca diretamente repare um volume criptografado com ferramentas de reparação de sistema de arquivos como fsck, ou isto destruirá qualquer chance de recuperar a chave usada para abrir seus arquivos. Tais ferramentas devem ser usadas no dispositivo desbloqueado (aberto).
  • para o formato LUKS2:
GRUB não suporta LUKS2.[1] Use LUKS1 em partições que o GRUB precisa ter acesso.
o formato LUKS2 tem grande uso de RAM por escolha de design, o padrão é 1GB por mapeador criptografado. Máquinas com pouca RAM e/ou múltiplas partições LUKS2 abertas em paralelo podem falhar na inicialização. Veja a opção --pbkdf-memory para controlar o uso de memória.[2]

LUKS em uma partição

Este exemplo demonstra um sistema criptografado com dm-crypt + LUKS em uma partição:

+--------------------+-------------------------------+-----------------------+
| Partição de boot   | Sistema criptogrado com LUKS2 | Espaço livre opcional |
|                    | partição                      | para outras partições |
|                    |                               | ou swap               |
| /boot              | /                             |                       |
|                    |                               |                       |
|                    | /dev/mapper/cryptroot         |                       |
|                    |-------------------------------|                       |
| /dev/sda1          | /dev/sda2                     |                       |
+--------------------+-------------------------------+-----------------------+

Os primeiros passos podem ser executados imediatamente após iniciar a imagem de instalação do Arch Linux.

Preparando o disco

Antes de criar qualquer partição, você deveria saber a importância e também métodos de como apagar o disco com segurança, descritos em dm-crypt/Preparando a unidade de armazenamento.

Crie as partições necessárias, ao menos uma para / (exemplo /dev/sda2) e /boot (/dev/sda1). Veja Particionamento.

Preparando partições que não são de boot

Os comandos a seguir criam e montam a partição raiz criptografada. Eles correspondem ao detalhado procedimento descrito em dm-crypt/Criptografando um sistema de arquivos não raiz#Particionamento (que, apesar do título, pode ser aplicado a partições raiz, contanto que mkinitcpio e o gerenciador de boot sejam corretamente configurados). Se você deseja usar opções de encriptação que não são padrão (exemplo, cifras criptográficas, tamanho da chave), veja as opções de encriptação antes de executar o primeiro comando:

# cryptsetup -y -v luksFormat /dev/sda2
# cryptsetup open /dev/sda2 cryptroot
# mkfs.ext4 /dev/mapper/cryptroot
# mount /dev/mapper/cryptroot /mnt

Verifique se o mapeamento funcionou como esperado:

# umount /mnt
# cryptsetup close cryptroot
# cryptsetup open /dev/sda2 cryptroot
# mount /dev/mapper/cryptroot /mnt

Se você criou partições separadas (exemplo, /home), estes passos têm que ser adaptados e repetidos para todos eles, exceto para /boot. Veja dm-crypt/Criptografando um sistema de arquivos não raiz#Desbloqueio e montagem automatizados para como manusear partições adicionais na inicialização.

Note que cada dispositivo de bloco precisa de sua própria senha. Isto pode ser inconveniente, por ser necessário inserir senhas separadas durante a inicialização. Uma alternativa é usar uma keyfile guardada na partição do sistema para desbloquear a partição separada por meio do crypttab. Veja dm-crypt/Encriptação de dispositivo#Usando LUKS para formatar partições com uma keyfile para instruções.

Preparando a partição de boot

O que você vai precisar fazer é uma partição para /boot não criptografada, que é necessária pelo sistema. Para uma partição ordinária em sistemas BIOS, por exemplo, execute:

# mkfs.ext4 /dev/sda1

Ou para uma Partição de sistema EFI em sistemas UEFI:

# mkfs.fat -F32 /dev/sda1

Depois crie o diretório e monte a partição:

# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Mountando os dispositivos

no Guia de instalação#Montar os sistemas de arquivos você vai precisar montar os dispositivos criptografados, não as partições. Claro /boot, que não é criptografado, ainda precisará ser montado diretamente.

Configurando o mkinitcpio

Adicione os hooks keyboard, keymap e encrypt em mkinitcpio.conf. Se deseja padrão de teclado US, você pode omitir o hook keymap.

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

Se está usando o hook sd-encrypt com o initramfs baseado no systemd, o seguinte precisa ser definido ao invês:

HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt filesystems fsck)

Dependendo de quais hooks estão sendo usados, a ordem pode ser relevante. Veja dm-crypt/Configuração do sistema#mkinitcpio para detalhes e outros hooks que você pode precisar.

Configurando o gerenciador de boot

Para desbloquear a partição raiz criptografada na inicialização, os seguintes parâmetros do kernel devem ser adicionados ao gerenciador de boot:

cryptdevice=UUID=UUID-da-partição-raiz:cryptroot root=/dev/mapper/cryptroot

Se está usando o hook sd-encrypt, o seguinte precisa ser definido ao invês:

rd.luks.name=UUID-da-partição-raiz=cryptroot root=/dev/mapper/cryptroot

Veja dm-crypt/Configurações do sistema#Gerenciador de boot para detalhes.

o UUID-da-partição-raiz é para ser substituído pelo UUID da partição raiz, nesse caso /dev/sda2. Veja Nomeação persistente de dispositivo de bloco para detalhes.

LVM dentro do LUKS

O método mais direto é configurar o LVM em cima da partição criptografada ao invés do contrário. Tecnicamente o LVM está dentro de um grande dispositivo de bloco criptografado. Em razão disso, o LVM não é transparente até que o dispositivo de bloco seja aberto e o volume estruturado abaixo seja escaneado e montado durante a inicialização.

O design do disco neste exemplo é::

+-----------------------------------------------------------------------+ +------------------+
| volume lógico 1       | volume lógico 2       | volume Lógico 3       | | Partição de boot |
|                       |                       |                       | |                  |
| [SWAP]                | /                     | /home                 | | /boot            |
|                       |                       |                       | |                  |
| /dev/MeuGrupoVol/swap | /dev/MeuGrupoVol/raiz | /dev/MeuGrupoVol/home | | (pode ser        |
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | em outro         |
|                                                                       | | dispositivo)     |
|                         Partição criptografada com LUKS2              | |                  |
|                           /dev/sda1                                   | | /dev/sdb1        |
+-----------------------------------------------------------------------+ +------------------+
Nota: Ao usar o hook encrypt, você não poderá utilizar volumes lógicos espalhados em múltiplos discos; use o sd-encrypt ou veja dm-crypt/Especificidades#Modificando o hook encrypt para múltiplas partições.
Dica: Duas variações dessa configuração:

Preparando o disco

Antes de criar qualquer partição, você deveria saber a importância e também métodos de como apagar o disco com segurança, descritos em dm-crypt/Preparando a unidade de armazenamento.

Dica: Se usa o gerenciador de boot GRUB para inicialização com BIOS de um disco GPT, crie uma Partição de inicialização de BIOS.

Crie uma partição que será montada em /boot com o tamanho de 200 MiB ou mais.

Dica: sistemas UEFI systems podem usar a Partição de sistema EFI para a /boot.

Crie uma partição que depois irá conter o container criptografado.

Crie o container criptografado com LUKS na partição do sistema. Enter com a senha escolhida duas vezes.

# cryptsetup luksFormat /dev/sda1

Para mais informações sobre as opções disponíveis do cryptsetup veja as opções de encriptação LUKS antes de executar o comando acima.

abra o container:

# cryptsetup open /dev/sda1 cryptlvm

o container estará disponível em /dev/mapper/cryptlvm.

Preparando os volumes lógicos

Crie um volume físico em cima do container LUKS aberto:

# pvcreate /dev/mapper/cryptlvm

Crie um grupo de volumes nomeado MeuGrupoVol (ou o que você desejar), e adicione ao, anteriormente criado, volume físico:

# vgcreate MeuGrupoVol /dev/mapper/cryptlvm

Crie todos os seus volumes lógicos no grupo de volumes:

# lvcreate -L 8G MeuGrupoVol -n swap
# lvcreate -L 32G MeuGrupoVol -n raiz
# lvcreate -l 100%FREE MeuGrupoVol -n home

Formate cada volume lógico para os sistemas de arquivos desejados:

# mkfs.ext4 /dev/MeuGrupoVol/raiz
# mkfs.ext4 /dev/MeuGrupoVol/home
# mkswap /dev/MeuGrupoVol/swap

Monte eles:

# mount /dev/MeuGrupoVol/raiz /mnt
# mkdir /mnt/home
# mount /dev/MeuGrupoVol/home /mnt/home
# swapon /dev/MeuGrupoVol/swap

Preparando a partição de inicialização

O gerenciador de boot carrega o kernel, initramfs, e seus arquivos de configuração do diretório /boot. Qualquer sistema de arquivos em um disco que pode ser lido pelo gerenciador de boot é elegível para uso.

Coloque um sistema de arquivos na partição escolhida como /boot:

# mkfs.ext4 /dev/sdb1
Dica: Se optar por manter o /boot em uma Partição de sistema EFI a formatação recomendada é
# mkfs.fat -F32 /dev/sdb1

Crie o diretório /mnt/boot:

# mkdir /mnt/boot

Monte a partição para /mnt/boot:

# mount /dev/sdb1 /mnt/boot

Configurando o mkinitcpio

Adicione os hooks keyboard, encrypt e lvm2 em mkinitcpio.conf:

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

Se está usando o hook sd-encrypt com o initramfs baseado no systemd, o seguinte precisa ser definido ao invês:

HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)

Veja dm-crypt/Configuração do sistema#mkinitcpio para detalhes e outros hooks que você pode precisar.

Configurando o gerenciador de boot

Para desbloquear a partição raiz criptografada na inicialização, os seguintes parâmetros do kernel devem ser adicionados ao gerenciador de boot:

cryptdevice=UUID=UUID-do-dispositivo:cryptlvm root=/dev/MeuGrupoVol/raiz

Se está usando o hook sd-encrypt, o seguinte precisa ser definido ao invês:

rd.luks.name=UUID-do-dispositivo=cryptlvm root=/dev/MeuGrupoVol/raiz

o UUID-do-dispositivo precisa ser substituído pelo UUID da partição raiz, nesse caso /dev/sda1. Veja Nomeação persistente de dispositivo de bloco para mais detalhes.

Veja dm-crypt/Configuração do sistema#Gerenciador de boot para mais informação sobre.

LUKS dentro do LVM

Você deve configurar os volumes do LVM primeiro antes de usá-los como base para as partições criptografadas. Desta maneira, é possível fazer uma mistura de volumes/partições que são criptografadas ou não.

Dica: Diferente do #LVM dentro do LUKS, este método permite usar volumes lógicos espalhados em múltiplos discos.

O texto a seguir exemplifica uma configuração do LUKS dentro do LVM que também faz uso de uma keyfile para o volume lógico /home e volumes temporários criptografados para /tmp e /swap. O último é desejável caso se preocupe com segurança, devido a evitar que dados temporários sensíveis sobrevivam durante a inicialização do sistema. Se tem experiência com LVM, você vai ser capaz de ignorar/trocar alguns dos passos relacionados com ele e outras coisas específicas de acordo com sua vontade.

Se quer usar volumes lógicos espalhados por múltiplos discos que já foram configurados, ou expandir o /home (ou qualquer outro volume), um dos jeitos de como fazer isto é descrito em dm-crypt/Especificidades#Expandindo LVM em vários discos. Vale notar que o container criptografado com LUKS precisa ser redimensionado também.

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: A introdução desse cenário precisa de alguns ajustes, já que agora existem comparações em #Visão geral. Uma estrutura sugerida é a introdução presente em #LUKS em uma partição. (Discuss in Talk:Dm-crypt (Português)/Encrypting an entire system (Português)#)

Preparando o disco

Esquema de particionamento:

+------------------+------------------------------------------------------------------------------------------------+
| Partição de boot | Volume criptografado com o   | Volume criptografado com LUKS2 | Volume criptografado com LUKS2 |
|                  | modo plain do dm-crypt       |                                |                                |
|                  |                              |                                |                                |
| /boot            | [SWAP]                       | /                              | /home                          |
|                  |                              |                                |                                |
|                  | /dev/mapper/swap             | /dev/mapper/raiz               | /dev/mapper/home               |
|                  |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|                  | Volume lógico 1              | Volume lógico 2                | Volume lógico 3                |
|                  | /dev/MeuGrupoVol/cryptswap   | /dev/MeuGrupoVol/cryptraiz     | /dev/MeuGrupoVol/crypthome     |
|                  |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|   /dev/sda1      |                                   /dev/sda2                                                    |
+------------------+------------------------------------------------------------------------------------------------+

sobrescreva /dev/sda2 de acordo com dm-crypt/Preparando a unidade de armazenamento#dm-crypt limpa o disco vazio ou partição.

Preparando os volumes lógicos

# pvcreate /dev/sda2
# vgcreate MeuGrupoVol /dev/sda2
# lvcreate -L 32G -n raiz MeuGrupoVol
# lvcreate -L 500M -n cryptswap MeuGrupoVol
# lvcreate -L 500M -n crypttmp MeuGrupoVol
# lvcreate -l 100%FREE -n crypthome MeuGrupoVol
# cryptsetup luksFormat /dev/MeuGrupoVol/cryptraiz
# cryptsetup open /dev/MeuGrupoVol/cryptraiz raiz
# mkfs.ext4 /dev/mapper/raiz
# mount /dev/mapper/raiz /mnt

Mais informações sobre opções de encriptação podem ser encontradas em dm-crypt/Encriptação de dispositivo#opções de encriptação para o modo LUKS. Note que /home será criptografada em #Criptografando o volume lógico /home.

Dica: Se você precisar acessar a raiz criptografada pelo archiso, a ação open vai possibilitar a execução de comandos para mostrar volumes do LVM.

Preparando a partição de boot

# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress
# mkfs.ext4 /dev/sda1
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Configurando o mkinitcpio

Adicione os hooks keyboard, lvm2 e encrypt em mkinitcpio.conf:

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

Se está usando o hook sd-encrypt com o initramfs baseado no systemd, o seguinte precisa ser definido ao invês:

HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)

Veja dm-crypt/Configuração do sistema#mkinitcpio para detalhes e outros hooks que você pode precisar.

Configurando o gerenciador de boot

Para abrir a partição raiz criptografada na inicialização, os seguintes parâmetros do kernel precisam ser adicionados ao gerenciador de boot:

cryptdevice=UUID=UUID-do-dispositivo:raiz root=/dev/mapper/raiz

Se está usando o hook sd-encrypt, o seguinte precisa ser definido ao invés:

rd.luks.name=UUID-do-dispositivo=raiz root=/dev/mapper/raiz

O UUID-do-dispositivo precisa ser substituído pelo UUID do /dev/MeuGrupoVol/cryptraiz. Veja Nomeação persistente de dispositivo de bloco para detalhes.

Veja dm-crypt/Configuração do sistema#Gerenciador de boot para mais informação sobre.

Configurando o fstab e crypttab

Ambas as entradas do crypttab e fstab são necessárias para abrir o dispositivo e montar os sistemas de arquivos, respectivamente. As seguintes linhas irão criptografar os sistemas de arquivos temporários a cada inicialização:

/etc/crypttab
swap	/dev/MeuGrupoVol/cryptswap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256
tmp	    /dev/MeuGrupoVol/crypttmp	/dev/urandom	tmp,cipher=aes-xts-plain64,size=256
/etc/fstab
/dev/mapper/raiz        /       ext4            defaults        0       1
/dev/sda1               /boot   ext4            defaults        0       2
/dev/mapper/tmp         /tmp    tmpfs           defaults        0       0
/dev/mapper/swap        none    swap            sw              0       0

Criptografando o volume lógico /home

Devido a este cenário usar LVM como mapeador primário e dm-crypt como secundário, cada volume lógico precisa ser criptografado separadamente. Apesar disso, diferente dos sistemas de arquivos temporários que foram configurados acima para serem voláteis, o volume lógico para /home vai ser persistente. O seguinte assume que você reiniciou o seu sistema criptografado, se você não fez isto, precisará adaptar os caminhos. Para não digitar uma segunda senha na inicialização, uma keyfile é criada:

# mkdir -m 700 /etc/luks-keys
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress

O volume lógico é criptografado com:

# cryptsetup luksFormat -v /dev/MeuGrupoVol/crypthome /etc/luks-keys/home
# cryptsetup -d /etc/luks-keys/home open /dev/MeuGrupoVol/crypthome home
# mkfs.ext4 /dev/mapper/home
# mount /dev/mapper/home /home

A montagem dos volumes criptografados é feita tanto no crypttab como no fstab:

/etc/crypttab
home	/dev/MeuGrupoVol/crypthome   /etc/luks-keys/home
/etc/fstab
/dev/mapper/home        /home   ext4        defaults        0       2

LUKS on software RAID

This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including /boot) for all drives, with the SSDs in a RAID0 array, and keyfiles used to unlock all encryption after GRUB is given a correct passphrase at boot.

This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at / (no separate /boot partition), and the decrypted HDD being mounted at /data.

Please note that regular backups are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different RAID level if fault tolerance is important to you.

The encryption is not deniable in this setup.

For the sake of the instructions below, the following block devices are used:

/dev/sda = first SSD
/dev/sdb = second SSD
/dev/sdc = HDD
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+
| BIOS boot partition | EFI system partition      | LUKS1 encrypted volume    | | BIOS boot partition | EFI system partition      | LUKS1 encrypted volume    | | LUKS2 encrypted volume    |
|                     |                           |                           | |                     |                           |                           | |                           |
|                     | /efi                      | /                         | |                     | /efi                      | /                         | | /data                     |
|                     |                           |                           | |                     |                           |                           | |                           |
|                     |                           | /dev/mapper/cryptroot     | |                     |                           | /dev/mapper/cryptroot     | |                           |
|                     +---------------------------+---------------------------+ |                     +---------------------------+---------------------------+ |                           |
|                     | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | |                     | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | |                           |
|                     |                           |                           | |                     |                           |                           | |                           |
|                     | /dev/md/ESP               | /dev/md/root              | |                     | /dev/md/ESP               | /dev/md/root              | | /dev/mapper/cryptdata     |
|                     +---------------------------+---------------------------+ |                     +---------------------------+---------------------------+ +---------------------------+
| /dev/sda1           | /dev/sda2                 | /dev/sda3                 | | /dev/sdb1           | /dev/sdb2                 | /dev/sdb3                 | | /dev/sdc1                 |
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+

Be sure to substitute them with the appropriate device designations for your setup, as they may be different.

Preparing the disks

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation.

For BIOS systems with GPT, create a BIOS boot partition with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.

For UEFI systems create an EFI system partition with an appropriate size, it will later be mounted at /efi.

In the remaining space on the drive create a partition (/dev/sda3 in this example) for "Linux RAID". Choose partition type ID fd for MBR or partition type GUID A19D880F-05FC-4D3B-A006-743F0F84911E for GPT.

Once partitions have been created on /dev/sda, the following commands can be used to clone them to /dev/sdb.

# sfdisk -d /dev/sda > sda.dump
# sfdisk /dev/sdb < sda.dump

The HDD is prepared with a single Linux partition covering the whole drive at /dev/sdc1.

Building the RAID array

Create the RAID array for the SSDs.

Note:
  • All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.
  • The RAID superblock must be placed at the end of the EFI system partition using --metadata=1.0, otherwise the firmware will not be able to access the partition.
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2

This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.

# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3

Preparing the block devices

As explained in dm-crypt/Drive preparation, the devices are wiped with random data utilizing /dev/zero and a crypt device with a random key. Alternatively, you could use dd with /dev/random or /dev/urandom, though it will be much slower.

# cryptsetup open --type plain /dev/md/root container --key-file /dev/random
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress
# cryptsetup close container

And repeat above for the HDD (/dev/sdc1 in this example).

Set up encryption for /dev/md/root:

Warning: GRUB does not support LUKS2. Use LUKS1 (--type luks1) on partitions that GRUB needs to access.
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root
# cryptsetup open /dev/md/root cryptroot
# mkfs.ext4 /dev/mapper/cryptroot
# mount /dev/mapper/cryptroot /mnt

And repeat for the HDD:

# cryptsetup -y -v luksFormat /dev/sdc1
# cryptsetup open /dev/sdc1 cryptdata
# mkfs.ext4 /dev/mapper/cryptdata
# mkdir /mnt/data
# mount /dev/mapper/cryptdata /mnt/data

For UEFI systems, set up the EFI system partition:

# mkfs.fat -F32 /dev/md/ESP
# mount /dev/md/ESP /mnt/efi

Configuring GRUB

Configure GRUB for the LUKS1 encrypted system by editing /etc/default/grub with the following:

GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:cryptroot"
GRUB_ENABLE_CRYPTODISK=y

See dm-crypt/System configuration#Boot loader and GRUB#Encrypted /boot for details.

Complete the GRUB install to both SSDs (in reality, installing only to /dev/sda will work).

# grub-install --target=i386-pc /dev/sda
# grub-install --target=i386-pc /dev/sdb
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB
# grub-mkconfig -o /boot/grub/grub.cfg

Creating the keyfiles

The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a keyfile for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See dm-crypt/Device encryption#With a keyfile embedded in the initramfs for details.

  • Create the keyfile and add the key to /dev/md/root.
  • Create another keyfile for the HDD (/dev/sdc1) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit /etc/crypttab to decrypt the HDD at boot. See Dm-crypt/System configuration#Unlocking with a keyfile.

Configuring the system

Edit fstab to mount the cryptroot and cryptdata block devices and the ESP:

/dev/mapper/cryptroot  /           ext4    rw,noatime  0   1
/dev/mapper/cryptdata  /data       ext4    defaults            0   2
/dev/md/ESP            /efi        vfat    rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro  0   2

Save the RAID configuration:

# mdadm --detail --scan >> /etc/mdadm.conf

Edit mkinitcpio.conf to include your keyfile and add the proper hooks:

FILES=(/crypto_keyfile.bin)
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block mdadm_udev encrypt filesystems fsck)

See dm-crypt/System configuration#mkinitcpio for details.

Plain dm-crypt

Contrary to LUKS, dm-crypt plain mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow deniable encryption. See also wikipedia:Disk encryption#Full disk encryption.

Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with plain mode.

Plain dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using plain mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also Disk encryption#Cryptographic metadata. Using plain mode could also be considered if concerned with the problems explained in dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD).

Tip: If headerless encryption is your goal but you are unsure about the lack of key-derivation with plain mode, then two alternatives are:

The scenario uses two USB sticks:

  • one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;
  • another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also Wikipedia:Security through obscurity, follow dm-crypt/Device encryption#Keyfiles to prepare the keyfile.

The disk layout is:

+----------------------+----------------------+----------------------+ +----------------+ +----------------+
| Logical volume 1     | Logical volume 2     | Logical volume 3     | | Boot device    | | Encryption key |
|                      |                      |                      | |                | | file storage   |
| /                    | [SWAP]               | /home                | | /boot          | | (unpartitioned |
|                      |                      |                      | |                | | in example)    |
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1      | | /dev/sdc       |
|----------------------+----------------------+----------------------| |----------------| |----------------|
| disk drive /dev/sda encrypted using plain mode and LVM             | | USB stick 1    | | USB stick 2    |
+--------------------------------------------------------------------+ +----------------+ +----------------+
Tip:
  • It is also possible to use a single USB key physical device:
    • By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).
    • By copying the keyfile to the initramfs directly. An example keyfile /etc/keyfile gets copied to the initramfs image by setting FILES=(/etc/keyfile) in /etc/mkinitcpio.conf. The way to instruct the encrypt hook to read the keyfile in the initramfs image is using rootfs: prefix before the filename, e.g. cryptkey=rootfs:/etc/keyfile.
  • Another option is using a passphrase with good entropy.

Preparing the disk

It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.

See dm-crypt/Drive preparation and dm-crypt/Drive preparation#dm-crypt specific methods

Preparing the non-boot partitions

See dm-crypt/Device encryption#Encryption options for plain mode for details.

Using the device /dev/sda, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:

# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, and key file details.

We can now check a mapping entry has been made for /dev/mapper/cryptlvm:

# fdisk -l
Tip: A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.

Next, we setup LVM logical volumes on the mapped device. See LVM#Installing Arch Linux on LVM for further details:

# pvcreate /dev/mapper/cryptlvm
# vgcreate MyVolGroup /dev/mapper/cryptlvm
# lvcreate -L 32G MyVolGroup -n root
# lvcreate -L 10G MyVolGroup -n swap
# lvcreate -l 100%FREE MyVolGroup -n home

We format and mount them and activate swap. See File systems#Create a file system for further details:

# mkfs.ext4 /dev/MyVolGroup/root
# mkfs.ext4 /dev/MyVolGroup/home
# mount /dev/MyVolGroup/root /mnt
# mkdir /mnt/home
# mount /dev/MyVolGroup/home /mnt/home
# mkswap /dev/MyVolGroup/swap
# swapon /dev/MyVolGroup/swap

Preparing the boot partition

The /boot partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a partitioning tool of your choice.

Create a filesystem on the partition intended for /boot, if it is not already formatted as vfat:

# mkfs.ext4 /dev/sdb1
# mkdir /mnt/boot
# mount /dev/sdb1 /mnt/boot

Configuring mkinitcpio

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

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

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring the boot loader

In order to boot the encrypted root partition, the following kernel parameters need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):

cryptdevice=/dev/disk/by-id/disk-ID-of-sda:cryptlvm cryptkey=/dev/disk/by-id/disk-ID-of-sdc:0:64 crypto=:aes-xts-plain64:512:0:

The disk-ID-of-disk refers to the id of the referenced disk. See Persistent block device naming for details.

See dm-crypt/System configuration#Boot loader for details and other parameters that you may need.

Tip: If using GRUB, you can install it on the same USB as the /boot partition with:
# grub-install --recheck /dev/sdb

Post-installation

You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the noauto option can be added to the relevant line in /etc/fstab:

/etc/fstab
# /dev/sdb1
/dev/sdb1 /boot ext4 noauto,rw,noatime 0 2

However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with:

# mount /boot

Encrypted boot partition (GRUB)

This setup utilizes the same partition layout and configuration as the previous #LVM on LUKS section, with the difference that the GRUB boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted /boot. See also GRUB#Encrypted /boot.

The disk layout in this example is:

+---------------------+----------------------+----------------------+----------------------+----------------------+
| BIOS boot partition | EFI system partition | Logical volume 1     | Logical volume 2     | Logical volume 3     |
|                     |                      |                      |                      |                      |
|                     | /efi                 | /                    | [SWAP]               | /home                |
|                     |                      |                      |                      |                      |
|                     |                      | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |
| /dev/sda1           | /dev/sda2            |----------------------+----------------------+----------------------+
| unencrypted         | unencrypted          | /dev/sda3 encrypted using LVM on LUKS1                             |
+---------------------+----------------------+--------------------------------------------------------------------+
Tip:
  • All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in #LVM on LUKS.
  • You can use cryptboot script from cryptbootAUR package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against Evil Maid attacks with UEFI Secure Boot. For more information and limitations see cryptboot project page.

Preparing the disk

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation.

For BIOS systems create a BIOS boot partition with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.

For UEFI systems create an EFI system partition with an appropriate size, it will later be mounted at /efi.

Create a partition of type 8309, which will later contain the encrypted container for the LVM.

Create the LUKS encrypted container:

Warning: GRUB does not support LUKS2. Use LUKS1 (--type luks1) on partitions that GRUB needs to access.
# cryptsetup luksFormat --type luks1 /dev/sda3

For more information about the available cryptsetup options see the LUKS encryption options prior to above command.

Your partition layout should look similar to this:

# gdisk -l /dev/sda
...
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        68239360   32.0 GiB    8309  Linux LUKS

Open the container:

# cryptsetup open /dev/sda3 cryptlvm

The decrypted container is now available at /dev/mapper/cryptlvm.

Preparing the logical volumes

The LVM logical volumes of this example follow the exact layout as the #LVM on LUKS scenario. Therefore, please follow #Preparing the logical volumes above and adjust as required.

If you plan to boot in UEFI mode, create a mountpoint for the EFI system partition at /efi for compatibility with grub-install and mount it:

# mkdir /mnt/efi
# mount /dev/sda2 /mnt/efi

At this point, you should have the following partitions and logical volumes inside of /mnt:

$ lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                   8:0      0   200G  0 disk
├─sda1                8:1      0     1M  0 part
├─sda2                8:2      0   550M  0 part  /mnt/efi
└─sda3                8:3      0   100G  0 part
  └─cryptlvm          254:0    0   100G  0 crypt
    ├─MyVolGroup-swap 254:1    0     8G  0 lvm   [SWAP]
    ├─MyVolGroup-root 254:2    0    32G  0 lvm   /mnt
    └─MyVolGroup-home 254:3    0    60G  0 lvm   /mnt/home

Configuring mkinitcpio

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

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

If using the sd-encrypt hook with the systemd-based initramfs, the following needs to be set instead:

HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)

See dm-crypt/System configuration#mkinitcpio for details and other hooks that you may need.

Configuring GRUB

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

/etc/default/grub
GRUB_ENABLE_CRYPTODISK=y

Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the encrypt hook:

/etc/default/grub
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=device-UUID:cryptlvm ..."

If using the sd-encrypt hook, the following need to be set instead:

/etc/default/grub
GRUB_CMDLINE_LINUX="... rd.luks.name=device-UUID=cryptlvm ..."

See dm-crypt/System configuration#Boot loader and GRUB#Encrypted /boot for details. The device-UUID refers to the UUID of /dev/sda3 (the partition which holds the lvm containing the root filesystem). See Persistent block device naming.

install GRUB to the mounted ESP for UEFI booting:

# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck

install GRUB to the disk for BIOS booting:

# grub-install --target=i386-pc --recheck /dev/sda

Generate GRUB's configuration file:

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

If all commands finished without errors, GRUB should prompt for the passphrase to unlock the /dev/sda3 partition after the next reboot.

Avoiding having to enter the passphrase twice

Merge-arrows-2.pngThis article or section is a candidate for merging with Dm-crypt/Device encryption#With a keyfile embedded in the initramfs.Merge-arrows-2.png

Notes: Too much duplicated content, too much detail here for this overview page. (Discuss in Talk:Dm-crypt (Português)/Encrypting an entire system (Português)#Security Issue with Grub Keyfile)

While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.

This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by with a keyfile embedded in the initramfs.

First create a keyfile and add it as LUKS key:

# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock
# chmod 000 /root/cryptlvm.keyfile
# chmod 600 /boot/initramfs-linux*
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile

Add the keyfile to the initramfs image:

/etc/mkinitcpio.conf
FILES=(/root/cryptlvm.keyfile)

Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the encrypt hook:

GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"

Or, using the sd-encrypt hook:

GRUB_CMDLINE_LINUX="... rd.luks.key=device-UUID=/root/cryptlvm.keyfile"

If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.

Tip: If you want to encrypt the /boot partition to protect against offline tampering threats, the mkinitcpio-chkcryptoboot hook has been contributed to help.

Btrfs subvolumes with swap

The following example creates a full system encryption with LUKS1 using Btrfs subvolumes to simulate partitions.

If using UEFI, an EFI system partition (ESP) is required. /boot itself may reside on / and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is /dev/sda1 and is mounted at /efi. /boot itself is located on the system partition, /dev/sda2.

Since /boot resides on the LUKS1 encrypted /, GRUB must be used as the bootloader because only GRUB can load modules necessary to decrypt /boot (e.g., crypto.mod, cryptodisk.mod and luks.mod).

Additionally an optional plain-encrypted swap partition is shown.

Warning: Do not use a swap file instead of a separate partition on Linux kernels before v5.0, because this may result in data loss. See Btrfs#Swap file.
+----------------------+----------------------+----------------------+
| EFI system partition | System partition     | Swap partition       |
| unencrypted          | LUKS1-encrypted      | plain-encrypted      |
|                      |                      |                      |
| /efi                 | /                    | [SWAP]               |
| /dev/sda1            | /dev/sda2            | /dev/sda3            |
|----------------------+----------------------+----------------------+

Preparing the disk

Note: It is not possible to use btrfs partitioning as described in Btrfs#Partitionless Btrfs disk when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in dm-crypt/Drive preparation. If you are using UEFI create an EFI system partition with an appropriate size. It will later be mounted at /efi. If you are going to create an encrypted swap partition, create the partition for it, but do not mark it as swap, since plain dm-crypt will be used with the partition.

Create the needed partitions, at least one for / (e.g. /dev/sda2). See the Partitioning article.

Preparing the system partition

Create LUKS container

Warning: GRUB does not support LUKS2. Use LUKS1 (--type luks1) on partitions that GRUB needs to access.

Follow dm-crypt/Device encryption#Encrypting devices with LUKS mode to setup /dev/sda2 for LUKS. See the dm-crypt/Device encryption#Encryption options for LUKS mode before doing so for a list of encryption options.

Unlock LUKS container

Now follow dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper to unlock the LUKS container and map it.

Format mapped device

Proceed to format the mapped device as described in Btrfs#File system on a single device, where /dev/partition is the name of the mapped device (i.e., cryptroot) and not /dev/sda2.

Mount mapped device

Finally, mount the now-formatted mapped device (i.e., /dev/mapper/cryptroot) to /mnt.

Tip: You may want to use the compress=lzo mount option. See Btrfs#Compression for more information.

Creating btrfs subvolumes

Merge-arrows-2.pngThis article or section is a candidate for merging with Btrfs.Merge-arrows-2.png

Notes: The subvolume layout is not specific to an encrypted system. (Discuss in Talk:Dm-crypt (Português)/Encrypting an entire system (Português)#)

Layout

Subvolumes will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:

subvolid=5 (/dev/sda2)
   |
   ├── @ (mounted as /)
   |       |
   |       ├── /bin (directory)
   |       |
   |       ├── /home (mounted @home subvolume)
   |       |
   |       ├── /usr (directory)
   |       |
   |       ├── /.snapshots (mounted @snapshots subvolume)
   |       |
   |       ├── /var/cache/pacman/pkg (nested subvolume)
   |       |
   |       ├── ... (other directories and nested subvolumes)
   |
   ├── @snapshots (mounted as /.snapshots)
   |
   ├── @home (mounted as /home)
   |
   └── @... (additional subvolumes you wish to use as mount points)

This section follows the Snapper#Suggested filesystem layout, which is most useful when used with Snapper. You should also consult Btrfs Wiki SysadminGuide#Layout.

Create top-level subvolumes

Here we are using the convention of prefixing @ to subvolume names that will be used as mount points, and @ will be the subvolume that is mounted as /.

Following the Btrfs#Creating a subvolume article, create subvolumes at /mnt/@, /mnt/@snapshots, and /mnt/@home.

Create any additional subvolumes you wish to use as mount points now.

Mount top-level subvolumes

Unmount the system partition at /mnt.

Now mount the newly created @ subvolume which will serve as / to /mnt using the subvol= mount option. Assuming the mapped device is named cryptroot, the command would look like:

# mount -o compress=lzo,subvol=@ /dev/mapper/cryptroot /mnt

See Btrfs#Mounting subvolumes for more details.

Also mount the other subvolumes to their respective mount points: @home to /mnt/home and @snapshots to /mnt/.snapshots.

Create nested subvolumes

Create any subvolumes you do not want to have snapshots of when taking a snapshot of /. For example, you probably do not want to take snapshots of /var/cache/pacman/pkg. These subvolumes will be nested under the @ subvolume, but just as easily could have been created earlier at the same level as @ according to your preference.

Since the @ subvolume is mounted at /mnt you will need to create a subvolume at /mnt/var/cache/pacman/pkg for this example. You may have to create any parent directories first.

Other directories you may wish to do this with are /var/abs, /var/tmp, and /srv.

Mount ESP

If you prepared an EFI system partition earlier, create its mount point and mount it now.

Note: Btrfs snapshots will exclude /efi, since it is not a btrfs file system.

At the pacstrap installation step, the btrfs-progs must be installed in addition to the base meta package.

Configuring mkinitcpio

Create keyfile

In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow dm-crypt/Device encryption#With a keyfile embedded in the initramfs making sure to add the key to /dev/sda2 at the luksAddKey step.

Edit mkinitcpio.conf

After creating, adding, and embedding the key as described above, add the encrypt hook to mkinitcpio.conf as well as any other hooks you require. See dm-crypt/System configuration#mkinitcpio for detailed information.

Tip: You may want to add BINARIES=(/usr/bin/btrfs) to your mkinitcpio.conf. See the Btrfs#Corruption recovery article.

Configuring the boot loader

Install GRUB to /dev/sda. Then, edit /etc/default/grub as instructed in the GRUB#Additional arguments and GRUB#Encrypted /boot, following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.

Configuring swap

If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at dm-crypt/Swap encryption.