Difference between revisions of "User:Wacek/brudnopis Dm-crypt/Specialties"

From ArchWiki
Jump to: navigation, search
(1)
(1)
Line 211: Line 211:
 
# Utwórz hak {{ic|wifi}}  w {{ic|/etc/initcpio/hooks/wifi}}: {{bc|run_hook ()<br>{<br>&#09;# sleep a couple of seconds so wlan0 is setup by kernel<br>&#09;sleep 5<br><br>&#09;# set wlan0 to up<br>&#09;ip link set wlan0 up<br><br>&#09;# assocciate with wifi network<br>&#09;# 1. save temp config file<br>&#09;wpa_passphrase "''network ESSID''" "''pass phrase''" > /tmp/wifi<br><br>&#09;# 2. assocciate<br>&#09;wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi<br><br>&#09;# sleep a couple of seconds so that wpa_supplicant finishes connecting<br>&#09;sleep 5<br><br>&#09;# wlan0 should now be connected and ready to be assigned an ip by the net hook<br>}<br><br>run_cleanuphook ()<br>{<br>&#09;# kill wpa_supplicant running in the background<br>&#09;killall wpa_supplicant<br><br>&#09;# set wlan0 link down<br>&#09;ip link set wlan0 down<br><br>&#09;# wlan0 should now be fully disconnected from the wifi network<br>}|}}
 
# Utwórz hak {{ic|wifi}}  w {{ic|/etc/initcpio/hooks/wifi}}: {{bc|run_hook ()<br>{<br>&#09;# sleep a couple of seconds so wlan0 is setup by kernel<br>&#09;sleep 5<br><br>&#09;# set wlan0 to up<br>&#09;ip link set wlan0 up<br><br>&#09;# assocciate with wifi network<br>&#09;# 1. save temp config file<br>&#09;wpa_passphrase "''network ESSID''" "''pass phrase''" > /tmp/wifi<br><br>&#09;# 2. assocciate<br>&#09;wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi<br><br>&#09;# sleep a couple of seconds so that wpa_supplicant finishes connecting<br>&#09;sleep 5<br><br>&#09;# wlan0 should now be connected and ready to be assigned an ip by the net hook<br>}<br><br>run_cleanuphook ()<br>{<br>&#09;# kill wpa_supplicant running in the background<br>&#09;killall wpa_supplicant<br><br>&#09;# set wlan0 link down<br>&#09;ip link set wlan0 down<br><br>&#09;# wlan0 should now be fully disconnected from the wifi network<br>}|}}
 
# Utwórz plik instalacyjny hook w {{ic|/etc/initcpio/install/wifi}}: {{bc|build ()<br>{<br>&#09;add_runscript<br>}<br>help ()<br>{<br>cat<<HELPEOF<br>&#09;Enables wifi on boot, for dropbear ssh unlocking of disk.<br>HELPEOF<br>}|}}
 
# Utwórz plik instalacyjny hook w {{ic|/etc/initcpio/install/wifi}}: {{bc|build ()<br>{<br>&#09;add_runscript<br>}<br>help ()<br>{<br>cat<<HELPEOF<br>&#09;Enables wifi on boot, for dropbear ssh unlocking of disk.<br>HELPEOF<br>}|}}
# Add {{ic|1=ip=:::::wlan0:dhcp}} to the [[kernel parameters]]. Remove {{ic|1=ip=:::::eth0:dhcp}} so it does not conflict.
+
# Dodaj {{ic|1=ip=:::::wlan0:dhcp}} do [[kernel parameters|parametrów jądra]]. Usuń {{ic|1=ip=:::::eth0:dhcp}}, aby nie było konfliktu.
# Optionally create an additional boot entry with kernel parameter {{ic|1=ip=:::::eth0:dhcp}}.
+
# Opcjonalnie utwórz dodatkowy wpis rozruchowy z parametrem jądra {{ic|1=ip=:::::eth0:dhcp}}.
# [[Regenerate the initramfs]].
+
# [[Regenerate the initramfs|Zregenerować initramfs]].
# Zaktualizuj konfigurację swojego [[boot loader|bootloadera]].
+
# Update the configuration of your [[boot loader]].
  
Remember to setup [[wifi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.
+
Pamiętaj, aby skonfigurować [[wifi]], aby móc zalogować się po pełnym uruchomieniu systemu. Jeśli nie możesz połączyć się z siecią Wi-Fi, spróbuj nieco wydłużyć czas uśpienia.
  
 
== Discard/TRIM support for solid state drives (SSD) ==
 
== Discard/TRIM support for solid state drives (SSD) ==

Revision as of 19:31, 16 July 2018

Zabezpieczanie niezaszyfrowanej partycji rozruchowej

Partycja /boot i Master Boot Record to dwa obszary dysku, które nie są zaszyfrowane, nawet w encrypted root. Zwykle nie można ich zaszyfrować, ponieważ boot loader i BIOS (odpowiednio) nie mogą odblokować kontenera dm-crypt, aby kontynuować proces uruchamiania. Wyjątkiem jest GRUB, który uzyskał funkcję odblokowania LUKSa zaszyfrowanego /boot - patrz dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB).

W tej sekcji opisano kroki, które można podjąć w celu zwiększenia bezpieczeństwa procesu rozruchu.

Warning: Należy pamiętać, że zabezpieczenie partycji /boot i MBR może złagodzić liczne ataki podczas rozruchu, ale systemy skonfigurowane w ten sposób mogą nadal być podatne na sabotaż BIOS/UEFI/firmware, sprzętowe keyloggery, zimne ataki rozruchowe i wiele innych zagrożeń, które są poza zakresem tego artykułu. Omówienie problemów związanych z zaufaniem systemu oraz ich związek z szyfrowaniem na pełnym dysku można znaleźć na stronie [1].

Uruchamianie z urządzenia wymiennego

Warning: Systemd wersja 230 generatora cryptsetup emituje RequiresMountsFor dla pliku kluczy crypto. Dlatego też, gdy system plików przechowujący ten plik zostanie odłączony, zatrzymuje również usługę cryptsetup. Takie zachowanie jest niepoprawne, ponieważ system plików i kryptokey są wymagane tylko raz, gdy kontener kryptograficzny jest początkowo skonfigurowany. Zobacz systemd issue 3816.

Używanie nośnika wymienego do uruchamiania systemu jest dość prostą procedurą i oferuje znaczną poprawę bezpieczeństwa przed niektórymi rodzajami ataków. Dwie wrażliwe części systemu wykorzystujące zaszyfrowany system plików root to

Te muszą być przechowywane niezaszyfrowane w celu uruchomienia systemu. Aby zabezpieczyć je przed manipulacją, zaleca się przechowywanie ich na wymiennym nośniku, takim jak dysk USB, i uruchamianie z tego dysku zamiast dysku twardego. Tak długo, jak utrzymujesz dysk ze sobą przez cały czas, możesz mieć pewność, że te komponenty nie zostały zmodyfikowane, dzięki czemu uwierzytelnianie będzie o wiele bezpieczniejsze podczas odblokowywania systemu.

Zakłada się, że masz już skonfigurowany system z dedykowaną partycją zamontowaną w /boot. Jeśli nie, wykonaj kroki opisane w dm-crypt/System configuration#Boot loader, zastępując dysk twardy dyskiem wymiennym.

Note: Musisz upewnić się, że twój system obsługuje uruchamianie z wybranego nośnika, czy to dysku USB, zewnętrznego dysku twardego, karty SD, czy cokolwiek innego.

Przygotuj dysk wymienny (/dev/sdx).

# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...
# mkfs.ext2 /dev/sdx1
# mount /dev/sdx1 /mnt

Copy your existing /boot contents to the new one.


Skopiuj istniejącą zawartość /boot na nową.

# cp -ai /boot/* /mnt/

Zainstaluj nową partycję. Nie zapomnij zaktualizować pliku [[fstab].

# umount /boot
# umount /mnt
# mount /dev/sdx1 /boot
# genfstab -p -U / > /etc/fstab

Zaktualizuj GRUB. grub-mkconfig powinien automatycznie wykryć nowy identyfikator UUID partycji, ale niestandardowe wpisy menu mogą wymagać ręcznej aktualizacji.

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx #install to the removable device, not the hard disk.

Uruchom ponownie i przetestuj nową konfigurację. Pamiętaj, aby odpowiednio ustawić kolejność uruchamiania urządzenia w systemie BIOS lub UEFI. Jeśli uruchomienie systemu nie powiedzie się, nadal można uruchomić komputer z dysku twardego, aby rozwiązać problem.

chkboot

Warning: chkboot makes a /boot partition tamper-evident, not tamper-proof. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.

Odnosząc się do artykułu z magazynu ct (wydanie 3/12, strona 146, 01.16.2012, [2]) poniższy skrypt sprawdza pliki w katalogu / boot pod kątem zmian sumy kontrolnej SHA-1, i-węzła i zajętych bloków na dysku twardym. Sprawdza także główny rekord rozruchowy. Skrypt nie może zapobiec pewnym typom ataków, ale wiele z nich jest trudniejszych. Konfiguracja samego skryptu nie jest przechowywana w niezaszyfrowanej partycji /boot. Z zablokowanym / wyłączonym zaszyfrowanym systemem, utrudnia to niektórym napastnikom, ponieważ nie jest oczywiste, że automatyczne porównywanie sumy kontrolnej partycji jest wykonywane po starcie systemu. Jednak osoba atakująca, która przewiduje takie środki ostrożności, może manipulować oprogramowaniem układowym, aby uruchomić własny kod nad jądrem i przechwycić dostęp do systemu plików, np. do rozruchu i przedstawienia niezakodowanych plików. Ogólnie rzecz biorąc, żadne środki bezpieczeństwa poniżej poziomu oprogramowania układowego nie są w stanie zagwarantować zaufania i fałszowania dowodów.

Dostępny jest skrypt z instrukcją instalacji(autor: Juergen Schmidt, ju at heisec.de; Licencja: GPLv2). Istnieje również pakiet chkbootAUR do zainstalowania.

Po instalacji dodaj plik usługi (pakiet zawiera jeden oparty na następujących elementach) i włącz go:

[Unit]
Description=Check that boot is what we want
Requires=basic.target
After=basic.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/chkboot.sh

[Install]
WantedBy=multi-user.target

Istnieje małe zastrzeżenie dla systemd. W chwili pisania tego tekstu oryginalny skrypt chkboot.sh zawiera puste miejsce na początku #! #!/bin/bash które musi zostać usunięte, aby usługa mogła pomyślnie się uruchomić.

Ponieważ /usr/local/bin/chkboot_user.sh musi zostać wykonany zaraz po zalogowaniu, musisz dodać go do autostartu (np. w KDE -> System Settings -> Startup and Shutdown -> Autostart; GNOME 3: gnome-session-properties).


With Arch Linux, changes to /boot are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:

W Arch Linuksie zmiany w /boot są dość częste, na przykład po aktualizacji kerneli. Dlatego pomocne może być korzystanie ze skryptów przy każdej pełnej aktualizacji systemu. Jednym ze sposobów, aby to zrobić:

#!/bin/bash
#
# Note: Insert your <user>  and execute it with sudo for pacman & chkboot to work automagically
#
echo "Pacman update [1] Quickcheck before updating" & 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
/usr/local/bin/chkboot.sh
sync							# sync disks with any results 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
/usr/local/bin/chkboot.sh
sync	
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user>
echo "Pacman update [3] All done, let us roll on ..."

mkinitcpio-chkcryptoboot

Warning: Ten hak nie szyfruje kodu rdzenia (MBR) GRUB-a ani kodu pośredniczącego EFI, ani nie chroni przed sytuacjami, gdy atakujący jest w stanie zmodyfikować zachowanie bootloadera, aby złamać jądro i / lub initramfs w czasie wykonywania.

mkinitcpio-chkcryptobootAUR jest haczykiem mkinitcpio, który przeprowadza kontrole integralności podczas wczesnej przestrzeni użytkownika i radzi, aby użytkownik nie wprowadzał swojego hasła do partycji głównej, jeśli system wydaje się być zagrożony. Bezpieczeństwo uzyskuje się za pomocą zaszyfrowanej partycji rozruchowej, która jest odblokowywana za pomocą modułu cryptodisk.mod GRUB-a oraz partycji root systemu plików, która jest szyfrowana hasłem innym niż poprzednie. W ten sposób initramfs i jądro są zabezpieczone przed ingerencją w trybie offline, a partycja root może pozostać bezpieczna, nawet jeśli hasło /boot partycji zostało wprowadzone na zaatakowanej maszynie (pod warunkiem, że hak chkcryptoboot wykryje kompromis i samo nie zostanie naruszone podczas uruchamiania w czasie wykonywania))

Ten haczyk wymaga odblokowania wersji grub > = 2.00 i dedykowanej partycji zaszyfrowanej / /boot LUKS z własnym hasłem, aby być bezpiecznym.

Instalacja

Zainstaluj mkinitcpio-chkcryptobootAUR i edytuj /etc/default/chkcryptoboot.conf. Jeśli chcesz wykryć, czy partycja rozruchowa została pominięta, zmodyfikuj zmienne CMDLINE_NAME i CMDLINE_VALUE , wartościami znanymi tylko Tobie. Możesz skorzystać z porady dotyczącej używania dwóch skrótów, jak sugeruje się tuż po instalacji. Należy również wprowadzić odpowiednie zmiany w linii poleceń jądra w /etc/default/grub. Zmodyfikuj linię HOOKS= w pliku /etc/mkinitcpio.conf i hak chkcryptoboot przed encrypt. Po zakończeniu zregeneruj initramfs.

Technical Overview

mkinitcpio-chkcryptobootAUR składa się z haka instalacyjnego i haka uruchomieniowego dla mkinitcpio. Hook instalacyjny uruchamia się za każdym razem, gdy initramfs jest przebudowywany i miesza skrót GRUB EFI $esp/EFI/grub_uefi/grubx64.efi) (w przypadku systemów UEFI) lub pierwsze 446 bajtów dysku, na którym zainstalowany jest GRUB (w przypadku systemów BIOS) i przechowuje wartości mieszania wewnątrz initramfs zlokalizowanych wewnątrz partycji zaszyfrowanej / /boot. Po uruchomieniu systemu GRUB pyta o hasło /boot, a następnie wywołuje tę samą operację skrótu i porównuje wynikowe hashy, zanim poprosi o hasło do partycji głównej. Jeśli nie pasują, hak wyświetli następujący błąd:

CHKCRYPTOBOOT ALERT!
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!
Please type uppercase yes to continue:

Oprócz skrótu programu ładującego, hak sprawdza również parametry działającego jądra względem tych skonfigurowanych w pliku /etc/default/chkcryptoboot.conf. Jest to sprawdzane zarówno w czasie wykonywania, jak i po zakończeniu procesu rozruchu. Pozwala to haczykowi wykryć, czy konfiguracja GRUB-a nie została ominięta w czasie wykonywania, a następnie wykryć, czy cała partycja {ic|/boot}} nie została ominięta.

W systemach BIOS hak tworzy hash pierwszego bootloadera GRUB-a (instalowanego do pierwszych 446 bajtów urządzenia rozruchowego) w celu porównania w późniejszych procesach rozruchowych. Główny drugi etap GRUB-a bootloadera core.img nie jest sprawdzany.

Inne metody

Alternatywnie do powyższych skryptów można skonfigurować za pomocą AIDE, którą można dostosować za pomocą bardzo elastycznego pliku konfiguracyjnego.

Chociaż jedna z tych metod powinna służyć większości użytkowników, nie rozwiązuje ona wszystkich problemów związanych z bezpieczeństwem związanym z niezaszyfrowaną partycją /boot. Jedno podejście, które stara się zapewnić w pełni uwierzytelniony łańcuch rozruchowy, zostało opublikowane w POTTS jako praca naukowa w celu wdrożenia struktury uwierzytelniania STARK.

Potwierdzenie koncepcji POTTS wykorzystuje Arch Linux jako podstawową dystrybucję i implementuje łańcuch rozruchowy systemu

  • POTTS - menu startowe dla monitu o jednorazowe potwierdzenie uwierzytelnienia
  • TrustedGrub - a implementacja GRUB Legacy, która uwierzytelnia jądro i initramfs względem rejestrów układów TPM
  • TRESOR - łatka jądra, która implementuje AES, ale utrzymuje klucz główny nie w pamięci RAM, ale w rejestrach procesora podczas pracy.

As part of the thesis installation instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.

W ramach pracy zostały opublikowane instrukcje instalacji oparte na Arch Linux (ISO od 2013-01). Jeśli chcesz go wypróbować, pamiętaj, że te narzędzia nie znajdują się w standardowych repozytoriach, a rozwiązanie będzie wymagało czasu.

Używanie zaszyfrowanych plików kluczy GPG, LUKS lub OpenSSL

następujące posty na forum podają instrukcje użycia uwierzytelniania dwuetapowego, gpg lub openssl zaszyfrowanych kluczy, zamiast pliku klucza tekstowego opisanego wcześniej w tym artykule wiki System Encryption using LUKS with GPG encrypted keys:

Zauważ, że:

  • Możesz wykonać powyższe instrukcje tylko z dwiema partycjami podstawowymi, jedną partycją rozruchową (wymaganą z powodu szyfrowania) i jedną podstawową partycją LVM. Na partycji LVM możesz mieć tyle partycji, ile potrzebujesz, ale co najważniejsze powinna zawierać przynajmniej partycje woluminu root, swap i home logical wolumin. Dodatkową zaletą jest posiadanie tylko jednego pliku klucza dla wszystkich partycji oraz możliwość hibernacji komputera (zawieszenie na dysk), w którym partycja wymiany jest szyfrowana. Jeśli zdecydujesz się na to, twoje haki w /etc/mkinitcpio.conf powinny wyglądać tak:
    HOOKS=( ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... )
    i powinieneś dodać
resume=/dev/<VolumeGroupName>/<LVNameOfSwap>
do parametrów jądra.
  • Jeśli musisz tymczasowo przechowywać zaszyfrowany plik klucza gdzieś, nie przechowuj ich na niezaszyfrowanym dysku. Nawet lepiej pamiętaj o zapisaniu ich w pamięci RAM, takich jak /dev/shm
  • Jeśli chcesz użyć pliku klucza szyfrowanego GPG, musisz użyć statycznie skompilowanej wersji GnuPG 1.4 lub możesz edytować haki i użyć tego pakietu AUR gnupg1AUR
  • Możliwe, że aktualizacja OpenSSL może przerwać niestandardowe ssldec wymienione w drugim poście na forum.

Zdalne odblokowanie partycji root (lub innej)

Jeśli chcesz móc zdalnie ponownie uruchomić system w pełni zaszyfrowany LUKS lub uruchomić go za pomocą usługi Wake-on-LAN będziesz potrzebował sposobu na wprowadzenie hasła dla partycji / woluminu root podczas uruchamiania. Można to osiągnąć, uruchamiając hak mkinitcpio, który konfiguruje interfejs sieciowy. Niektóre pakiety wymienione poniżej udostępniają różne konfiguracje mkinitcpio w celu ułatwienia konfiguracji.

Note:
  • Pamiętaj, aby używać nazw urządzeń jądra dla interfejsu sieciowego (np. eth0)), a nie dla udev's (np. enp1s0), ponieważ te nie będą działać.
  • Konieczne może być dodanie modułu do karty sieciowej do tablicy MODULES.

Zdalne odblokowanie (haki: systemd, systemd-tool)

AUR pakiet mkinitcpio-systemd-toolAUR zapewnia systemd-centric mkinitcpio hook o nazwie systemd-tool z następującym zestawem funkcji dla systemd w initramfs:

Podstawowe funkcje zapewniane przez hak:

  • ujednolicona konfiguracja systemd + mkinitcpio
  • automatyczne przydzielanie zasobów binarnych i konfiguracyjnych
  • wywoływanie skryptów mkinitcpio i funkcji wbudowanych na żądanie

Funkcje oferowane przez dołączone jednostki serwisowe:

  • initrd debugging
  • wczesna konfiguracja sieci
  • interaktywna powłoka użytkownika
  • zdalny dostęp ssh w initrd
  • cryptsetup + niestandardowy agent hasła

Pakiet mkinitcpio-systemd-toolAUR wymaga haka systemowego. Aby uzyskać więcej informacji, zapoznaj się z plikiem README projektu oraz dostępnymi domyślnymi plikami jednostek usług systemowych, aby rozpocząć.

Zalecane haki to: base autodetect modconf block filesystems keyboard fsck systemd systemd-tool.

Zdalne odblokowanie (haki: netconf, dropbear, tinyssh, ppp)

Inną kombinacją pakietów zapewniającą zdalne logowanie do initcpio jest mkinitcpio-netconfAUR i mkinitcpio-pppAUR (do zdalnego odblokowania za pomocą połączenia PPP przez Internet) along w z serwerem SSH. Możesz użyć albo mkinitcpio-dropbearAUR lub mkinitcpio-tinysshAUR. Te haki nie instalują żadnej powłoki, więc musisz także zainstalować mkinitcpio-utilsAURpakiet. Poniższe instrukcje mogą być używane w dowolnej kombinacji powyższych pakietów. Gdy istnieją różne ścieżki, zostanie to odnotowane.

  1. Jeśli nie masz jeszcze pary kluczy SSH, wygeneruj ją w systemie klienta (tym, który będzie używany do odblokowania zdalnego komputera). Jeśli zdecydujesz się użyć mkinitcpio-tinysshAUR, masz możliwość użycia klawiszy Ed25519 keys.
  2. Wstaw swój klucz publiczny SSH (tj. Ten, który zwykle umieszczasz na hostach, abyś mógł wejść bez hasła lub tego, które właśnie utworzyłeś i który kończy się na .pub) do pliku /etc/dropbear/root_key lub /etc/tinyssh/root_key.
    Tip: Ta metoda może później zostać użyta do dodania innych kluczy publicznych SSH w razie potrzeby; W przypadku zwykłego skopiowania zawartości plików ~/.ssh/authorized_keys, należy sprawdzić, czy zawiera on tylko klucze, których zamierzasz użyć do odblokowania zdalnego komputera. Dodając dodatkowe klucze, zregeneruj swój initrd również za pomocą mkinitcpio. Zobacz też Secure Shell#Protection.
  3. Dodaj wszystkie trzy <netconf and/or ppp> <dropbear lub tinyssh> encryptssh hooks przed filesystems w tablicy "HOOKS" w /etc/mkinitcpio.conf (encryptssh zastępuje hook encrypt). Następnie zregeneruj initramfs.
    Note: Hak net dostarczony przez mkinitcpio-nfs-utils nie jest potrzebny.
  4. Skonfiguruj wymagany parametr cryptdevice= dodaj parametr polecenia ip= parametr komendy jądra do bootloadera za pomocą odpowiednich argumentów. Na przykład, jeśli serwer DHCP nie przypisuje statycznego adresu IP do systemu zdalnego, co utrudnia dostęp przez SSH po ponownym uruchomieniu, można jawnie podać adres IP, który ma być używany
    ip=192.168.1.1:::::eth0:none
    Alternatywnie można również określić maskę podsieci i bramę wymaganą przez sieć:
    ip=192.168.1.1::192.168.1.254:255.255.255.0::eth0:none
    Note: Od wersji 0.0.4 programu mkinitcpio-netconfAUR można zagnieżdżać wiele parametrów ip= w celu skonfigurowania wielu interfejsów. Nie można mieszać go z ip=dhcp (ip=:::::eth0:dhcp) sam. Interfejs musi zostać określony.
    ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none
    Aby uzyskać szczegółowy opis, spójrz na odpowiednią sekcję mkinitcpio. Po zakończeniu zaktualizuj konfigurację swojego bootloadera.
  5. Na koniec zrestartuj system zdalny i spróbuj ssh do niego, jawnie określając nazwę użytkownika "root" (nawet jeśli konto root jest wyłączone na komputerze, ten użytkownik root jest używany tylko w initrd w celu odblokowania systemu zdalnego). Jeśli korzystasz z pakietu mkinitcpio-dropbearAUR i masz zainstalowany pakiet openssh, najprawdopodobniej nie otrzymasz żadnych ostrzeżeń przed zalogowaniem się, ponieważ konwertuje on i używa tych samych kluczy hosta, co używa openssh (oprócz kluczy Ed25519, ponieważ dropbear ich nie obsługuje). Jeśli używasz mkinitcpio-tinysshAUR, masz możliwość zainstalowania tinyssh-convertAUR lub tinyssh-convert-gitAUR, dzięki czemu możesz użyć tych samych kluczy, co twoja instalacja openssh (obecnie tylko klucze Ed25519). W obu przypadkach powinieneś uruchomić [[Secure_Shell#Daemon_management|demona ssh] przynajmniej raz, używając dostarczonych jednostek systemd, aby klucze mogły zostać wygenerowane jako pierwsze. Po ponownym uruchomieniu komputera pojawi się monit o podanie hasła w celu odblokowania urządzenia root. System zakończy proces uruchamiania, a następnie możesz ssh do niego, jak zwykle (z wybranym użytkownikiem zdalnym).
Tip: Jeśli chcesz po prostu dobre rozwiązanie do zdalnego montowania innych zaszyfrowanych partycji (takich jak /home), możesz zajrzeć do [https://bbs.archlinux.org/viewtopic.php?pid=880484 tego wątku na forum.

Zdalne odblokowanie przez Wi-Fi (haki: buduj własne)

Hak sieciowy jest zwykle używany z połączeniem ethernetowym. Jeśli chcesz skonfigurować komputer tylko z siecią bezprzewodową i odblokować go przez Wi-Fi, możesz utworzyć niestandardowy hak, aby połączyć się z siecią Wi-Fi przed uruchomieniem haka sieciowego.

Poniższy przykład pokazuje konfigurację za pomocą adaptera USB, łączącego się z siecią Wi-Fi chronioną WPA2-PSK. Jeśli użyjesz na przykład WEP lub innego programu ładującego, być może będziesz musiał zmienić niektóre rzeczy.

  1. Zmodyfikuj /etc/mkinitcpio.conf:
    • Dodaj potrzebny moduł jądra do konkretnego adaptera Wi-Fi
    • Dołącz pliki binarne wpa_passphrase i wpa_supplicant.
    • Dodaj hak wifi (lub nazwę do wyboru, jest to niestandardowy hak, który zostanie utworzony) przed hakiem net.
      MODULES=(module)
      BINARIES=(wpa_passphrase wpa_supplicant)
      HOOKS=(base udev autodetect ... wifi net ... dropbear encryptssh ...)
  2. Utwórz hak wifi w /etc/initcpio/hooks/wifi:
    run_hook ()
    {
    # sleep a couple of seconds so wlan0 is setup by kernel
    sleep 5

    # set wlan0 to up
    ip link set wlan0 up

    # assocciate with wifi network
    # 1. save temp config file
    wpa_passphrase "network ESSID" "pass phrase" > /tmp/wifi

    # 2. assocciate
    wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi

    # sleep a couple of seconds so that wpa_supplicant finishes connecting
    sleep 5

    # wlan0 should now be connected and ready to be assigned an ip by the net hook
    }

    run_cleanuphook ()
    {
    # kill wpa_supplicant running in the background
    killall wpa_supplicant

    # set wlan0 link down
    ip link set wlan0 down

    # wlan0 should now be fully disconnected from the wifi network
    }
  3. Utwórz plik instalacyjny hook w /etc/initcpio/install/wifi:
    build ()
    {
    add_runscript
    }
    help ()
    {
    cat<<HELPEOF
    Enables wifi on boot, for dropbear ssh unlocking of disk.
    HELPEOF
    }
  4. Dodaj ip=:::::wlan0:dhcp do parametrów jądra. Usuń ip=:::::eth0:dhcp, aby nie było konfliktu.
  5. Opcjonalnie utwórz dodatkowy wpis rozruchowy z parametrem jądra ip=:::::eth0:dhcp.
  6. Zregenerować initramfs.
  7. Update the configuration of your boot loader.

Pamiętaj, aby skonfigurować wifi, aby móc zalogować się po pełnym uruchomieniu systemu. Jeśli nie możesz połączyć się z siecią Wi-Fi, spróbuj nieco wydłużyć czas uśpienia.

Discard/TRIM support for solid state drives (SSD)

Solid State Drive users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the discard option unless you override the default.

The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.[3][4] Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled. An illustration and discussion of the issues arising from activating TRIM is available in the blog of a cryptsetup developer. If you are worried about such factors, keep also in mind that threats may add up: for example, if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher --cipher aes-cbc-essiv, more information leakage may occur from trimmed sector observation than with the current default.

The following cases can be distinguished:

  • The device is encrypted with default dm-crypt LUKS mode:
    • By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives? and Full disk encryption on an ssd.
    • TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.
See also Securely wipe disk#Flash memory.
  • The device is encrypted with dm-crypt plain mode, or the LUKS header is stored separately:
    • If plausible deniability is required, TRIM should never be used because of the considerations at the top of this section, or the use of encryption will be given away.
    • If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.
Warning: Before enabling TRIM on a drive, make sure the device fully supports TRIM commands, or data loss can occur. See Solid State Drives#TRIM.

In linux 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add :allow-discards to the cryptdevice option. The TRIM option may look like this:

cryptdevice=/dev/sdaX:root:allow-discards

For the main cryptdevice configuration options before the :allow-discards see Dm-crypt/System configuration.

If you are using a systemd based initrd, you must pass:

rd.luks.options=discard
Note: The rd.luks.options=discard kernel option does not have any effect on devices included in the initramfs image's /etc/crypttab file (/etc/crypttab.initramfs on real root). You must specify option discard in /etc/crypttab.initramfs.

Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab. For details, please refer to the TRIM page.

For LUKS devices unlocked via /etc/crypttab use option discard, e.g.:

/etc/crypttab
luks-123abcdef-etc UUID=123abcdef-etc none discard

When manually unlocking devices on the console use --allow-discards.

With LUKS2 you can set allow-discards as a default flag for a device by opening it once with the option --persistent:

# cryptsetup --allow-discards --persistent open --type luks2 /dev/sdaX root

You can confirm the flag is persistently set in the LUKS2 header by looking at the cryptsetup luksDump output:

# cryptsetup luksDump /dev/sdaX | grep Flags
Flags:          allow-discards

In any case, you can verify whether the device actually was opened with discards by inspecting the dmsetup table output:

# dmsetup table
luks-123abcdef-etc: 0 1234567 crypt aes-xts-plain64 000etc000 0 8:2 4096 1 allow_discards

The encrypt hook and multiple disks

Tip: sd-encrypt hook supports unlocking multiple devices. They can be specified on the kernel command line or in /etc/crypttab.initramfs. See dm-crypt/System configuration#Using sd-encrypt hook.

The encrypt hook only allows for a single cryptdevice= entry (FS#23182). In system setups with multiple drives this may be limiting, because dm-crypt has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the encrypt hook.

The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a LUKS on LVM setup to a new disk. The second with modifying the encrypt hook to unlock multiple disks in LUKS setups without LVM.

Expanding LVM on multiple disks

The management of multiple disks is a basic LVM feature and a major reason for its partitioning flexibility. It can also be used with dm-crypt, but only if LVM is employed as the first mapper. In such a LUKS on LVM setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk.

Warning: Back up! While resizing filesystems may be standard, keep in mind that operations may go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.

Adding a new drive

First, it may be desired to prepare a new disk according to dm-crypt/Drive preparation. Second, it is partitioned as a LVM, e.g. all space is allocated to /dev/sdY1 with partition type 8E00 (Linux LVM). Third, the new disk/partition is attached to the existing LVM volume group, e.g.:

# pvcreate /dev/sdY1
# vgextend MyStorage /dev/sdY1

Extending the logical volume

For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the cryptdevice root partition, but in this case the procedure has to be performed from an Arch Install ISO.

In this example, it is assumed that the logical volume for /home (lv-name homevol) is going to be expanded with the fresh disk space:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Now the logical volume is extended and the LUKS container comes next:

# cryptsetup open /dev/MyStorage/homevol home
# umount /home      # as a safety, in case it was automatically remounted
# cryptsetup --verbose resize home

Finally, the filesystem itself is resized:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home

Done! If it went to plan, /home can be remounted and now includes the span to the new disk:

# mount /dev/mapper/home /home

Note that the cryptsetup resize action does not affect encryption keys, and these have not changed.

Modifying the encrypt hook for multiple partitions

Root filesystem spanning multiple partitions

It is possible to modify the encrypt hook to allow multiple hard drive decrypt root (/) at boot. One way:

# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
# cp /usr/lib/initcpio/hooks/encrypt  /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2

Add cryptdevice2= to your boot options (and cryptkey2= if needed), and add the encrypt2 hook to your mkinitcpio.conf before rebuilding it. See dm-crypt/System configuration.

Multiple non-root partitions

Maybe you have a requirement for using the encrypt hook on a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.

The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of /etc/fstab (at least).

Of course, if the cryptsetup package gets upgraded, you will have to change this script again. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.

Tango-inaccurate.pngThe factual accuracy of this article or section is disputed.Tango-inaccurate.png

Reason: Why not use the supported Grub2 right away? See also mkinitcpio#Using RAID (Discuss in User talk:Wacek/brudnopis Dm-crypt/Specialties#)

If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like

kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5

If you set up your root partition as a RAID, you will notice the similarities with that setup. GRUB can handle multiple array definitions just fine:

kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

Encrypted system using a detached LUKS header

This example follows the same setup as in dm-crypt/Encrypting an entire system#Plain dm-crypt, which should be read first before following this guide.

By using a detached header the encrypted blockdevice itself only carries encrypted data, which gives deniable encryption as long as the existence of a header is unknown to the attackers. It is similar to using plain dm-crypt, but with the LUKS advantages such as multiple passphrases for the masterkey and key derivation. Further, using a detached header offers a form of two factor authentication with an easier setup than using GPG or OpenSSL encrypted keyfiles, while still having a built-in password prompt for multiple retries. See Disk encryption#Cryptographic metadata for more information.

See dm-crypt/Device encryption#Encryption options for LUKS mode for encryption options before performing the first step to setup the encrypted system partition and creating a header file to use with cryptsetup:

# dd if=/dev/zero of=header.img bs=4M count=1 conv=notrunc
# cryptsetup luksFormat --type luks2 /dev/sdX --align-payload 8192 --header header.img
Tip: When using option --header, --align-payload allows specifying the start of encrypted data on a device. By reserving a space at the beginning of device you have the option of later reattaching the LUKS header. See cryptsetup(8) for values supported by --align-payload.

Open the container:

# cryptsetup open --header header.img /dev/sdX enc

Now follow the LVM on LUKS setup to your requirements. The same applies for preparing the boot partition on the removable device (because if not, there is no point in having a separate header file for unlocking the encrypted disk). Next move the header.img onto it:

# mv header.img /mnt/boot

Follow the installation procedure up to the mkinitcpio step (you should now be arch-chrooted inside the encrypted system).

Tip: You will notice that since the system partition only has "random" data, it does not have a partition table and by that an UUID or a LABEL. But you can still have a consistent mapping using the Persistent block device naming#by-id and by-path. E.g. using disk id from /dev/disk/by-id/.

There are two options for initramfs to support a detached LUKS header.

Using systemd hook

First create /etc/crypttab.initramfs and add the encrypted device to it. The syntax is defined in crypttab(5)

/etc/crypttab.initramfs
enc	/dev/disk/by-id/your-disk_id	none	header=/boot/header.img

Modify /etc/mkinitcpio.conf to use systemd and add the header to FILES.

/etc/mkinitcpio.conf
...
FILES=(/boot/header.img)
...
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)
...

Regenerate the initramfs and you are done.

Note: No cryptsetup parameters need to be passed to the kernel command line, since/etc/crypttab.initramfs will be added as /etc/crypttab in the initramfs. If you wish to specify them in the kernel command line see dm-crypt/System configuration#Using sd-encrypt hook for the supported options.

Modifying encrypt hook

This method shows how to modify the encrypt hook in order to use a detached LUKS header. Now the encrypt hook has to be modified to let cryptsetup use the separate header (FS#42851; base source and idea for these changes published on the BBS). Make a copy so it is not overwritten on a mkinitcpio update:

# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
/etc/initcpio/hooks/encrypt2 (around line 52)
warn_deprecated() {
    echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
    echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
}

local headerFlag=false
for cryptopt in ${cryptoptions//,/ }; do
    case ${cryptopt} in
        allow-discards)
            cryptargs="${cryptargs} --allow-discards"
            ;;  
        header)
            cryptargs="${cryptargs} --header /boot/header.img"
            headerFlag=true
            ;;
        *)  
            echo "Encryption option '${cryptopt}' not known, ignoring." >&2 
            ;;  
    esac
done

if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
    if $headerFlag || cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
        [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
        dopassphrase=1

Now edit the mkinitcpio.conf to add the encrypt2 and lvm2 hooks, the header.img to FILES and the loop to MODULES, apart from other configuration the system requires:

/etc/mkinitcpio.conf
...
MODULES=(loop)
...
FILES=(/boot/header.img)
...
HOOKS=(base udev autodetect keyboard keymap consolefont modconf block encrypt2 lvm2 filesystems fsck)
...

This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up the initramfs is created.

Next the boot loader is configured to specify the cryptdevice= also passing the new header option for this setup:

cryptdevice=/dev/disk/by-id/your-disk_id:enc:header

To finish, following dm-crypt/Encrypting an entire system#Post-installation is particularly useful with a /boot partition on an USB storage medium.

Encrypted /boot and a detached LUKS header on USB

Rather than embedding the header.img and keyfile into the initramfs image, this setup will make your system depend entirely on the usb key rather than just the image to boot, and on the encrypted keyfile inside of the encrypted boot partition. Since the header and keyfile are not included in the initramfs image and the custom encrypt hook is specifically for the usb's by-id, you will literally need the usb key to boot.

For the usb drive, since you are encrypting the drive and the keyfile inside, it is preferred to cascade the ciphers as to not use the same one twice. Whether a meet-in-the-middle attack would actually be feasible is debatable. You can do twofish-serpent or serpent-twofish.

Preparing the disk devices

sdb will be assumed to be the USB drive, sda will be assumed to be the main hard drive.

Prepare the devices according to dm-crypt/Drive preparation.

Preparing the USB key

Use gdisk to partition the disk according to the layout shown here, with the exception that it should only include the first two partitions. So as follows:

# gdisk /dev/sdb
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624         1460223   200.0 MiB   8300  Linux filesystem

Before running cryptsetup, look at the Encryption options for LUKS mode and Ciphers and modes of operation first to select your desired settings.

Prepare the boot partition but don't mount any partition yet and Format the EFI System Partition.

# mount /dev/mapper/cryptboot /mnt
# dd if=/dev/urandom of=/mnt/key.img bs=filesize count=1
# cryptsetup --align-payload=1 luksFormat /mnt/key.img
# cryptsetup open /mnt/key.img lukskey

filesize is in bytes but can be followed by a suffix such as M. Having too small of a file will get you a nasty Requested offset is beyond real size of device /dev/loop0 error. As a rough reference, creating a 4M file will encrypt it successfully. You should make the file larger than the space needed since the encrypted loop device will be a little smaller than the file's size.

With a big file, you can use --keyfile-offset=offset and --keyfile-size=size to navigate to the correct position. [5]

Now you should have lukskey opened in a loop device (underneath /dev/loop1), mapped as /dev/mapper/lukskey.

The main drive

# truncate -s 2M /mnt/header.img
# cryptsetup --key-file=/dev/mapper/lukskey --keyfile-offset=offset --keyfile-size=size luksFormat /dev/sda --align-payload 4096 --header /mnt/header.img

Pick an offset and size in bytes (8192 bytes is the maximum keyfile size for cryptsetup).

# cryptsetup open --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=offset --keyfile-size=size /dev/sda enc 
# cryptsetup close lukskey
# umount /mnt

Follow Preparing the logical volumes to set up LVM on LUKS.

See Partitioning#Discrete partitions for recommendations on the size of your partitions.

Once your root partition is mounted, mount your encrypted boot partition as /mnt/boot and your ESP or EFI partition as /mnt/boot/efi.

Installation procedure and custom encrypt hook

Follow the installation guide up to the mkinitcpio step but do not do it yet, and skip the partitioning, formatting, and mounting steps as they have already been done.

In order to get the encrypted setup to work, you need to build your own hook, which is thankfully easy to do and here is the code you need. You will have to follow Persistent block device naming#by-id and by-path to figure out your own by-id values for the usb and main hard drive (they are linked -> to sda or sdb).

You should be using the by-id instead of just sda or sdb because sdX can change and this ensures it is the correct device.

You can name customencrypthook anything you want, and custom build hooks can be placed in the hooks and install folders of /etc/initcpio. Keep a backup of both files (cp them over to the /home partition or your user's /home directory after you make one). /usr/bin/ash is not a typo.

/etc/initcpio/hooks/customencrypthook
#!/usr/bin/ash

run_hook() {
    modprobe -a -q dm-crypt >/dev/null 2>&1
    modprobe loop
    [ "${quiet}" = "y" ] && CSQUIET=">/dev/null"

    while [ ! -L '/dev/disk/by-id/usbdrive-part2' ]; do
     echo 'Waiting for USB'
     sleep 1
    done

    cryptsetup open /dev/disk/by-id/usbdrive-part2 cryptboot
    mkdir -p /mnt
    mount /dev/mapper/cryptboot /mnt
    cryptsetup open /mnt/key.img lukskey
    cryptsetup --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' open /dev/disk/by-id/harddrive enc
    cryptsetup close lukskey
    umount /mnt
}

usbdrive is your USB drive by-id, and harddrive is your main hard drive by-id.

Tip: You could also close cryptboot using cryptsetup close, but having it open makes it easier to mount for system updates using Pacman and regenerating the initramfs with mkinitcpio. The /boot partition must be mounted for updates that affect the kernel or Initramfs, and the initramfs will be automatically regenerated after these updates.
# cp /usr/lib/initcpio/install/encrypt /etc/initpcio/install/customencrypthook

Now edit the copied file and remove the help() section as it is not necessary.

/etc/mkinitcpio.conf (edit this only do not replace it, these are just excerpts of the necessary parts)
MODULES=(loop)
...
HOOKS=(base udev autodetect modconf block customencrypthook lvm2 filesystems keyboard fsck)

The files=() and binaries=() arrays are empty, and you should not have to replace HOOKS=(...) array entirely just edit in customencrypthook lvm2 after block and before filesystems, and make sure systemd, sd-lvm2, and encrypt are removed.

Boot Loader

Finish the Installation Guide from the mkinitcpio step. To boot you would need either GRUB or efibootmgr. Note you can use GRUB to support the encrypted disks by Configuring the boot loader but editing the GRUB_CMDLINE_LINUX is not necessary for this set up.

Or use Direct UEFI Secure boot by generating keys with cryptbootAUR then signing the initramfs and kernel and creating a bootable .efi file for your /boot/efi directory with sbupdate-gitAUR. Before using cryptboot or sbupdate note this excerpt from Secure Boot#Using your own keys:

Tip: Note that cryptbootAUR requires the encrypted boot partition to be specified in /etc/crypttab before it runs, and if you are using it in combination with sbupdate-gitAUR, sbupdate expects the /boot/efikeys/db.* files created by cryptboot to be capitalized like DB.* unless otherwise configured in /etc/default/sbupdate. Users who do not use systemd to handle encryption may not have anything in their /etc/crypttab file and would need to create an entry.
# efibootmgr -c -d /dev/device -p partition_number -L "Arch Linux Signed" -l "EFI\Arch\linux-signed.efi"

See efibootmgr(8) for an explanation of the options.

Make sure the boot order puts Arch Linux Signed first. If not change it with efibootmgr -o XXXX,YYYY,ZZZZ.

Changing the LUKS keyfile

Merge-arrows-2.pngThis article or section is a candidate for merging with dm-crypt/Device encryption#Keyfiles.Merge-arrows-2.png

Notes: Changing the keyfile is not a required action in this setup. (Discuss in User talk:Wacek/brudnopis Dm-crypt/Specialties#)
# cryptsetup --header /boot/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=offset --keyfile-size=size luksChangeKey /dev/mapper/enc /dev/mapper/lukskey2 --new-keyfile-size=newsize --new-keyfile-offset=newoffset

Afterwards, cryptsetup close lukskey and shred or dd the old keyfile with random data before deleting it, then make sure that the new keyfile is renamed to the same name of the old one: key.img or other name.