Szyfrowanie LUKS wspomagane układem TPM można doprowadzić do awarii i skłonić do udostępnienia ratunkowej konsoli administracyjnej. Problem brzmi jak coś poważnego, w praktyce unaocznia jedynie niespójność mechanizmu automatycznego odblokowywania dysków.
Michael Fincham z Pulse Security przyjrzał się implementacji automatycznego odblokowywania dysków za pomocą TPM. Zamiast pytania o hasło, system czyta je z układu TPM i używa go do odszyfrowania – jeżeli nie zaszły żadne przesłanki blokujące TPM, czyli poszlaki wskazujące na ręczną ingerencję w sprzęt lub ustawienia UEFI.
Tą metodę od lat stosuje Windows w swojej funkcji BitLocker: dyski są szyfrowane, ale odszyfrowują się automatycznie. Poproszą o hasło jedynie, gdy uruchomi się z nich system po wkręceniu do innego komputera (inny TPM) lub nastąpi zablokowanie układu wskutek jakichś potencjalnie nieuprawionych zmian. Choć Windows promuje takie rozwiązanie już od 10 lat (TPM zdecydowanie nie jest nowością, pojawił się w komputerach w roku 2006), wiele domyślnych konfiguracji szyfrowania w Linuksach konfiguruje swój mechanizm pełnodyskowego szyfrowania (LUKS FDE) stosując wyłącznie interaktywnie wpisywane hasło. Rozwiązanie to uniemożliwia rozruchy nienadzorowane.
LUKS i TPM
Jest jednak możliwe skonfigurowanie LUKS tak, aby stosował TPM. Wymaga to użycia rozwiązania Clevis i odpowiedniej konfiguracji dracut. Są to narzędzia opracowane przez Red Hata. Działają one, wykorzystując ten sam mechanizm pytania o hasło, co w przypadku „zwykłego” LUKS-a. Clevis implementuje agenta „wpisującego” hasło za pomocą TPM. Architektura agentów odpowiadających na żądanie hasła ma słabość, w postaci… wyświetlania prośby o hasło. Jej obecność oznacza, że mimo działania agentów, dalej możliwe jest interaktywne, ręczne wpisanie hasła.
Poprzez bardzo szybkie podanie wielu złych haseł (np. poprzez przytrzymanie klawisza Enter), systemd anuluje odblokowywanie dysku. Prowadzi to do nieobecności drzewa rootfs i niemożności przejęcia przez resztę systemu rozruchu zapoczątkowanego przez /boot. Dracut zapewnia w domyślnej konfiguracji, że taki problem kończy się otrzymaniem awaryjnej powłoki administracyjnej. Mając ją, można samodzielnie zrobić to, co chwilę później i tak miał zrobić clevis: odblokować dysk za pomocą TPM. Tylko, że zamiast otrzymać odblokowany dysk i ekran logowania, utrzymujemy odblokowany dysk i powłokę administracyjną.
To jeszcze nie katastrofa
Warto mieć na uwadze kilka kwestii. Po pierwsze, sposobów na uzyskanie powłoki ratunkowej dracut jest więcej. Wystarczy odpowiednio „zdenerwować” proces rozruchu: odpiąć dysk, odpiąć (specyficznie skonfigurowaną) sieć, podpiąć wadliwą sieć, podłączyć nieobsługiwane urządzenie itp. Jeżeli stosujemy szyfrowanie LUKS+TPM, powłoka ratunkowa powinna być więc wyłączona. Z tym, że błędne podanie hasła powinno zablokować TPM i uniemożliwić rozruch, a to nie miało miejsca – jest to kwestia niezależna od powłoki ratunkowej.
Windows z zabawnych powodów nie ma takiego problemu. Jeżeli dysk jest auto-odblokowywany przez TPM, użytkownik nigdy nie otrzyma interaktywnego pytania o hasło. Możliwe jest ręczne wymuszenie wejścia Windowsa do swojego odpowiednika powłoki ratunkowej (w tym wypadku Windows RE) i od Windows 11 nie zapyta ona o hasło (!), ale to nic nie da. Jeżeli dysk jest zaszyfrowany BitLockerem, rozruch z Windows RE nie odblokowuje dysku automatycznie. Środowisko odzyskiwania co prawda nie poprosi o hasło administratora, ale poprosi o hasło do dysku. I oczywiście, podobnie jak dracut emergency shell, Windows RE Agent także może być wyłączony, co czasem ma sens. Windows RE jest potencjalnie dziurawy.
Nie do końca wiadomo, kto miałby tu coś naprawić. Problem występuje na skrzyżowaniu wielu współpracujących za sobą mechanizmów i ukazuje słabość architektury agentów. Jednocześnie jest łatwy do powstrzymania, poprzez zablokowanie powłoki ratunkowej. Niemniej, uzyskanie powłoki administracyjnej poprzez naciskanie Enter jest naruszeniem bezpieczeństwa. Kolejnym. W 2016 roku, zbliżony problem zidentyfikowano w Debianie.
