Schemat szyfrowania LUKS oparty jest na algorytmie AES-256. AES (Advanced Encryption Standard), czy bardziej precyzyjnie Rijndael, został wybrany z uwagi na połączenie oczekiwanego poziomu bezpieczeństwa z bardzo dobrą wydajnością procesów szyfrowania i deszyfrowania - a do tego algorytm ten jest tak zaprojektowany, że relatywnie łatwo jest go zaimplementować sprzętowo. W efekcie od czasu jego wyboru jako standard FIPS-197, powstał cały szereg różnych rozwiązań sprzętowych, włączając w to rozszerzenie AES-NI dla wielu (obecnie większości) procesorów Intela.
Funkcjonariusz z jednej strony potrafi eksfiltrować dane z dysków zaszyfrowanych LUKS (oraz trzema innymi popularnymi metodami), z drugiej zaś używa szyfrowania LUKS, aby chronić Twoje dane przed dostępem osób trzecich - a więc pośrednio Ciebie przed konsekwencjami utraty nośnika.
LUKS czy brak szyfrowania - porównanie wydajności
Na procesorach wspierających AES-NI, szyfrowanie LUKS będzie powodować większe obciążenie procesora (widoczne szczególnie gdy komputer pracuje w trybie graficznym, albo obsługuje jednocześnie jakieś intensywne obliczeniowo aplikacje), natomiast nie powinno w żaden sposób spowalniać procesów I/O - szczególnie że wąskim gardłem i tak są napędy dyskowe oraz kontrolery SATA.
Aby to zweryfikować, przeprowadziliśmy kilka testów:
- Core 2 Duo E8400, 4GB RAM (standardowy komputer Dell OptiPlex 780, wyprodukowany w 2010)
- eksfiltracja danych z dysku Samsung SSD 850 EVO 500GB
- na dysk Samsung Portable SSD T5 1TB USB 3.1, ale podłączony do portu USB 2.0 (z obsługą protokołu UASP)
- zestaw plików typowy dla programisty aplikacji C++ dla systemu Windows w niewielkiej firmie:
- Windows 10 Home
- Visual Studio z dużą ilością zainstalowanych dodatków
- Embarcadero RAD Studio
- łącznie 27GB danych w ~134000 plikach (już po zaaplikowaniu reguł wykluczeń rsync)
Porównaliśmy ze sobą 2 warianty: w pierwszym oba dyski były nieszyfrowane. W drugim dysk docelowy (T5) był szyfrowany LUKS (aes-xts-plain64 z kluczem 512 bitów, algorytmem hashującym sha512 i czasem przetwarzania hasła zwiększonym do 5 sekund - dokładnie takie ustawienia sugerujemy w instrukcji instalacji).
Uśrednione wyniki czasowe (mniejszy czas jest lepszy):
- Bez szyfrowania - 14m 5s.
- Z szyfrowaniem LUKS - 14m 2s. Natomiast obciążenie całego systemu było zauważalnie większe.
Więcej ciekawych testów znajdziesz na tej stronie.
Problematyczny sprzęt
Szyfrowanie LUKS wymaga działającego generatora liczb losowych crng. Na większości sprzętu, nawet bardzo starego, to działa bez żadnych problemów. Natomiast w trakcie testowania Funkcjonariusza na różnych platformach sprzętowych, zidentyfikowaliśmy kilka modeli komputerów, na których crng nie działa prawidłowo.
Kali Linux, zależnie od ustawień BIOS/UEFI, może w trakcie rozruchu wyświetlać ekran tekstowy (z typowymi komunikatami rozruchowymi jądra Linuxa, a następnie uruchamiania poszczególnych usług przez systemd) lub graficzny (z logotypem Kali Linux). W trybie tekstowym na większości komputerów, tuż przed pytaniem o hasło LUKS, zobaczysz następujący komunikat:
random: crng init done
Na problematycznych komputerach zobaczysz zamiast tego:
uninitialized urandom read (4 bytes read)
a następnie pytanie o hasło - przy czym niezależnie od tego, co odpowiesz, po wciśnięciu Enter zobaczysz mniej więcej taki komunikat błędu:
Please unlock disk /dev/sda3:*****************************
There was an error decrypting /dev/sda3 ... Retry (Y/n)
Not enough available memory to open a keyslot.Nie ma na to rozwiązania - po prostu aby być w stanie eksfiltrować dane z takich komputerów, przygotuj sobie jeden zapasowy dysk z Funkcjonariuszem, z nieszyfrowaną partycją na dane. I używaj go tylko jako ostatniej szansy.
Lista problematycznego sprzętu
- Acer Aspire One D270
- Asus Eee Box B202 (najprawdopodobniej wszystkie warianty B20x)
- Dell OptiPlex FX160 (najprawdopodobniej również niektóre warianty modelu FX170)
- Fit-PC2 by CompuLab
- HP ThinClient T5740 (tylko wersje ze starszym firmware, identyfikujące się jako "T5000 series")