W poprzednim artykule, który traktował o odszyfrowaniu kontenera LUKS przez SSH z poziomu initramfs/initrd na Raspberry Pi, została poruszona kwestia adresacji IP, która w opisanym tam rozwiązaniu miała pewne ograniczenia. Chodziło o to, że połączenie SSH do RPI mogło być realizowane jedynie przez przewodowy interfejs sieciowy eth0 . Trzeba było zatem się zastanowić nad rozwiązaniem, które umożliwiłoby korzystanie również z bezprzewodowego interfejsu WiFi, tj. wlan0 . Celem niniejszego wpisu jest pokazanie w jaki sposób można dorobić wsparcie dla połączeń WiFi w naszej malinie, tak by szło odszyfrować kontener LUKS przez SSH, w sytuacji gdy z jakiegoś powodu nie chcemy lub też nie możemy korzystać z przewodowego interfejsu sieciowego tego minikomputera z zainstalowanym system RasPiOS/Raspbian.

Od paru dni bawię się swoim Raspberry Pi w kontekście zaszyfrowania jego systemu RasPiOS/Raspbian. O ile samo zaszyfrowanie tego minikomputera przy pomocy mechanizmu LUKS nie było jakoś specjalnie trudne, to trzeba było pomyśleć nad rozwiązaniami mającymi ułatwić otworzenie takiego zaszyfrowanego kontenera przy starcie systemu. Póki co udało się wypracować w miarę zadowalające rozwiązanie wykorzystujące dedykowane urządzenia USB w roli klucza, bez którego system się nie uruchomi. Są jednak i inne rozwiązania, które mogą nam pomóc odszyfrować system RPI bez potrzeby fatygowania się do pomieszczenia i wtykania w jej port USB jakiegoś pendrive. Mowa o zaprzęgnięciu usługi SSH, która by została uruchomiona w fazie initramfs/initrd, chwilę przed wpisaniem hasła do kontenera LUKS. Takie rozwiązanie wymaga jednak zainstalowania innego serwera SSH, tj. Dropbear, pogodzenia go z serwerem OpenSSH oraz też trzeba odpowiednio przygotować sam obraz initramfs/initrd. Po pomyślnym skonfigurowaniu systemu, będziemy się logować do Raspberry Pi przez SSH i wpisywać hasło do kontenera LUKS, a jeśli to hasło będzie prawidłowe, to system zostanie odszyfrowany i uruchomiony.

Ostatnio udało mi się zaszyfrować swojego Raspberry Pi 4B przez wdrożenie kontenera LUKS i upchnięcie w nim wszystkich danych z partycji / zainstalowanego w tym urządzeniu systemu RasPiOS/Raspbian. To jednak nie był koniec pracy, bo taki zaszyfrowany system na RPI ma szereg wad. Tym główniejszym uniedogodnieniem jest wpisywanie hasła na początku fazy boot, by pełny start systemu był w ogóle możliwy. Sytuacja się komplikuje, gdy do naszego minikomputera nie mamy podłączonego monitora i/lub klawiatury. Ten zaistniały problem można rozwiązać na kilka sposobów, np. przez zaprzęgnięcie do pracy dodatkowego nośnika USB w celu umieszczenia na nim pliku klucza (keyfile). Niemniej jednak, można pójść o krok dalej i wykorzystać samo urządzenie jako klucz i gdy takiego pendrive nie podłączymy do portu USB naszej maliny, to system nam się nie uruchomi. Te dwa rozwiązania są bardzo podobne do siebie ale to drugie jest nieco bardziej odporne na ewentualne problemy ze skasowaniem pliku klucza, co może nam się przytrafić, gdy taki pendrive jest wykorzystywany w roli regularnego nośnika danych przechowującego dla niepoznaki jakieś pliki. Tak czy inaczej oba te sposoby zostaną opisane w niniejszym artykule.

Ostatnio napisał do mnie pewien osobnik, który miał dość spory problem z zaszyfrowaniem swojego Raspberry Pi. Po wymianie kilku maili zacząłem tracić rozeznanie w całej tej sytuacji i doszedłem do wniosku, że najwyraźniej zaszyfrowanie systemu maliny nie jest rzeczą trywialną. Postanowiłem zatem rzucić okiem na swojego RPI i sprawdzić czy są tutaj faktycznie jakieś odstępstwa od tradycyjnego szyfrowania na bazie LUKS w stosunku do szyfrowania spotykanego w pierwszej lepszej dystrybucji linux'a, takiej jak Debian czy Ubuntu. Pobrałem więc ze strony Raspberry Pi najnowszy obraz systemu RasPiOS/Raspbian, wrzuciłem go na kartę SD przy pomocy dd i okazało się, że w zasadzie większych problemów z zaszyfrowaniem mojej maliny nie było. Przyznać trzeba, że informacje na temat szyfrowania RPI, które można spotkać na internetach, są w przeważającej większości bardzo słabej jakości i mam wrażenie, że pisane przez osoby, które nie do końca się zainteresowały poruszanym przez siebie zagadnieniem. Postanowiłem zatem na przykładzie mojego Raspberry Pi 4B opisać w miarę dokładny sposób od początku do końca jak przeprowadzić cały ten proces szyfrowania danych na karcie SD, którą podpinamy do naszego minikomputera.

Eksperymentując ostatnio z moją maszynką Raspberry Pi 4B, zaszła potrzeba, by zejść do systemu RasPiOS/Raspbian przy pomocy mechanizmu chroot. Problem w tym, że system wyrzuca komunikat: chroot: failed to run command ‘/bin/bash’: Exec format error . Niby wszystko jest na swoim miejscu ale ta widoczna wyżej wiadomość nie chce zniknąć uniemożliwiając tym samym dalszą zabawę z RPI. Okazało się, że winna jest tutaj architektura CPU. Mój laptop działa pod kontrolą 64-bitowego Intel'owskiego procesora (x64, x86-64, AMD64), na którym uruchomiony jest również 64-bitowy Debian linux. Z kolei Raspberry Pi ma 64-bitowy procesor ARM (ARMv8-A) działający pod kontrolą 32-bitowego systemu operacyjnego. Te dość spore rozbieżności sprawiają, że nie damy rady skorzystać z chroot, przynajmniej nie bez zaprzęgnięcia do tego celu emulatora QEMU.