Poważne utrudnienia dla Linuxa. Klucze Microsoftu tracą ważność

Zbliżająca się data 11 września 2025 roku może okazać się kłopotliwa dla użytkowników systemów opartych na Linuxie. Tego dnia wygaśnie ważność klucza kryptograficznego podpisanego przez Microsoft, który do tej pory był szeroko wykorzystywany przez wiele dystrybucji do obsługi Secure Boot.

Choć z pozoru może się to wydawać techniczną ciekawostką, zmiana ta może znacząco wpłynąć na zdolność wielu użytkowników do uruchamiania systemu w trybie zapewniającym podstawowe zabezpieczenia na poziomie oprogramowania sprzętowego. W konsekwencji wiele urządzeń może przestać wspierać tę funkcję bez aktualizacji firmware’u, która nie zawsze zostanie dostarczona przez producenta.

Czym jest Secure Boot?

Secure Boot, będący częścią specyfikacji UEFI, ma za zadanie uniemożliwić uruchamianie nieautoryzowanego oprogramowania przy starcie komputera. Mechanizm ten został stworzony przez grupę producentów sprzętu, by ograniczyć ryzyko ataków polegających na modyfikowaniu systemu jeszcze przed jego uruchomieniem. Kluczowe dane konfiguracyjne Secure Boot, w tym bazy podpisów, bazy cofniętych certyfikatów i rejestry kluczy rejestracyjnych, są przechowywane w nieulotnej pamięci systemowej. W teorii aktualizacja tych danych wymaga obecności fizycznego użytkownika lub odpowiednio podpisanego pakietu, zgodnego z kluczem platformy PK.

Problem z kluczem i jego następstwem

Microsoft poinformował, że przestanie wykorzystywać stary klucz podpisujący, a jego nowy odpowiednik – dostępny od 2023 roku – nie został jeszcze wgrany na wiele istniejących urządzeń. Zastąpienie starego certyfikatu nowym nie nastąpi automatycznie. W wielu przypadkach niezbędne będzie udostępnienie przez producenta odpowiedniej aktualizacji firmware’u lub bazy danych KEK. Jednak aktualizacja ta może nigdy nie nadejść. Trudno oczekiwać, by producenci sprzętu masowo wspierali niszowe potrzeby użytkowników alternatywnych systemów operacyjnych, zwłaszcza na starszych płytach głównych, które przestały być objęte regularnym wsparciem. Nawet jeśli teoretycznie możliwe jest wdrożenie nowego klucza poprzez aktualizację samej bazy KEK, mechanizm ten jest mało znany i niesprawdzony w praktyce.

Opcje dystrybutorów i ograniczenia użytkowników

W obliczu tej sytuacji dystrybutorzy systemów operacyjnych muszą podejmować trudne decyzje. Niektóre projekty, takie jak NetBSD i OpenBSD, porzuciły już ideę wspierania Secure Boot. Inne, jak wiele dystrybucji Linuksa oraz FreeBSD, zdecydowały się na współpracę z Microsoftem, tworząc specjalne „podkładki” – niewielkie warstwy kodu startowego, które umożliwiają dalszy rozruch systemu. Te rozwiązania bazują jednak na certyfikatach Microsoftu, a więc także na aktualnych kluczach. Po wrześniu takie podejście może przestać działać na wielu komputerach, które nie otrzymają niezbędnych aktualizacji.

Użytkownicy znajdą się w niełatwym położeniu. Nie wszyscy wiedzą, czym jest UEFI, jak się po nim poruszać i jak wyłączyć lub ponownie włączyć Secure Boot. Nawet ci, którzy potrafią to zrobić, nie zawsze mają możliwość samodzielnego podpisywania kluczy czy wgrywania ich do pamięci firmware'u. W rezultacie osoby chcące zainstalować Linuxa mogą być zmuszone do całkowitego wyłączenia Secure Boot – i zrezygnowania z jednej z ważniejszych warstw ochrony przed złośliwym oprogramowaniem.

Między bezpieczeństwem a dostępnością

Secure Boot miał chronić użytkowników przed zagrożeniami takimi jak bootkity i rootkity. Teoretycznie mechanizm ten podnosi poziom bezpieczeństwa, uniemożliwiając uruchomienie nieautoryzowanego kodu już na etapie startu systemu. Jednak w praktyce funkcja ta wielokrotnie sprawiała problemy. W przeszłości jej luki bezpieczeństwa, jak BootHole czy BlackLotus, umożliwiały obejście zabezpieczeń na poziomie firmware'u. Jednocześnie wiele osób wykorzystywało istniejące luki właśnie po to, by ominąć ograniczenia narzucane przez Microsoft – na przykład instalując Windows 11 na sprzęcie niespełniającym oficjalnych wymogów, jak brak modułu TPM 2.0.

Trudno nie zauważyć, że dla wielu użytkowników funkcja Secure Boot stała się nie tylko narzędziem ochrony, lecz także barierą technologiczną. Rosnąca frustracja związana z tym mechanizmem, jego ograniczeniami i zależnością od działań producentów sprzętu sprawia, że coraz więcej osób wybiera pozostanie przy systemie Windows – lub całkowite wyłączenie tej funkcji. Równocześnie rośnie liczba użytkowników, którzy chcieliby spróbować innych systemów operacyjnych, zwłaszcza w obliczu zbliżającego się końca wsparcia dla Windows 10.