BitLocker nie współpracuje z Secure Boot

BitLocker niewspółpracujący z Secure Boot wymaga sprawdzenia, czy Secure Boot jest włączony w BIOS-ie — te dwie funkcje bezpieczeństwa są ze sobą powiązane w pełnej ochronie integralności systemu.

BitLocker nie współpracuje z Secure Boot — co oznacza ten problem

Komunikat lub objaw określany jako „BitLocker nie współpracuje z Secure Boot” wskazuje na niespójność między mechanizmem szyfrowania dysku a funkcją bezpiecznego uruchamiania systemu Windows. BitLocker wykorzystuje informacje z procesu startowego, modułu TPM oraz ustawień firmware’u UEFI, aby ocenić, czy komputer uruchamia się w przewidywalnym i zaufanym środowisku. Secure Boot z kolei kontroluje podpisy składników ładowanych przed uruchomieniem systemu i blokuje elementy, które nie spełniają wymagań zaufanego rozruchu.

Nie zawsze oznacza to uszkodzenie samego szyfrowania. Przyczyną może być wyłączenie Secure Boot, przełączenie trybu rozruchu z UEFI na Legacy lub CSM, zmiana konfiguracji modułu TPM, aktualizacja firmware’u, modyfikacja tablicy partycji albo wymiana podzespołu odpowiedzialnego za identyfikację urządzenia. W takiej sytuacji system może zażądać klucza odzyskiwania BitLocker, ponieważ wykryta konfiguracja różni się od tej, która obowiązywała podczas wcześniejszego uruchomienia.

Problem należy rozpatrywać ostrożnie, ponieważ BitLocker chroni dane przed odczytem po podłączeniu dysku do innego urządzenia. Próba przypadkowego wyłączania zabezpieczeń, czyszczenia modułu TPM lub zmiany trybu startowego może doprowadzić do kolejnego żądania klucza odzyskiwania. Przed zmianami warto ustalić, czy klucz jest zapisany na koncie Microsoft, w koncie organizacyjnym, na wydruku, w pliku lub w innym bezpiecznym miejscu.

Jak Secure Boot, UEFI, TPM i BitLocker są ze sobą powiązane

Bezpieczny rozruch działa na poziomie firmware’u płyty głównej, jeszcze przed załadowaniem systemu Windows. Weryfikowane są wtedy podpisy cyfrowe programów startowych, sterowników rozruchowych oraz innych elementów uczestniczących w uruchamianiu systemu. Jeżeli podpis jest nieprawidłowy albo konfiguracja nie odpowiada zapisanym zasadom, Secure Boot może zatrzymać start lub przekazać systemowi informację o zmianie środowiska rozruchowego.

BitLocker nie jest jedynie funkcją ustawianą w systemie plików. Przy prawidłowej konfiguracji współpracuje z modułem TPM, który przechowuje dane potrzebne do weryfikacji zaufanego stanu urządzenia. Podczas uruchamiania porównywane są między innymi informacje dotyczące firmware’u, menedżera rozruchu i wybranej ścieżki startowej. Jeśli wartości kontrolne ulegną zmianie, automatyczne odblokowanie dysku może zostać wstrzymane, a wymagane staje się podanie klucza odzyskiwania.

W praktyce należy odróżnić trzy sytuacje. Pierwsza to wyłączony Secure Boot przy jednocześnie aktywnym szyfrowaniu. Druga polega na uruchamianiu systemu w trybie Legacy lub CSM, mimo że instalacja Windows została przygotowana dla UEFI. Trzecia obejmuje zmianę ustawień TPM albo jego wyczyszczenie, na przykład podczas konfiguracji firmware’u. Każdy z tych przypadków może wyglądać podobnie z punktu widzenia użytkownika, ale wymaga innego postępowania.

Nie powinno się włączać Secure Boot w ciemno, jeżeli nie ma pewności, że system został zainstalowany w trybie UEFI i korzysta z prawidłowego menedżera rozruchu. W starszej konfiguracji może pojawić się brak startu systemu, pętla naprawy automatycznej lub kolejne żądanie klucza. Z tego powodu najpierw sprawdza się bieżący tryb uruchamiania, status szyfrowania, obecność modułu TPM oraz stan kluczy odzyskiwania.

Typowe przyczyny błędów BitLocker i Secure Boot

Jedną z częstszych przyczyn jest ręczna zmiana ustawień w UEFI. Wyłączenie Secure Boot, aktywowanie trybu zgodności ze starszym sprzętem albo zmiana kolejności urządzeń startowych mogą zostać zinterpretowane jako naruszenie zaufanego procesu uruchamiania. Podobny efekt może wystąpić po przywróceniu ustawień domyślnych firmware’u, gdy wcześniejsze parametry rozruchu zostaną zastąpione innym zestawem wartości.

Problemy pojawiają się również po aktualizacji BIOS-u lub UEFI. Sama aktualizacja nie musi być wadliwa, jednak zmiana wersji firmware’u może wpłynąć na pomiary przekazywane do TPM. Po zakończeniu procesu system może zażądać klucza BitLocker, a po poprawnym odblokowaniu wymagać ponownej synchronizacji zabezpieczeń. W takich przypadkach ważne jest, aby nie przerywać uruchamiania i nie usuwać zawartości TPM bez wcześniejszego potwierdzenia, że klucz odzyskiwania jest dostępny.

Inny scenariusz dotyczy modyfikacji partycji rozruchowych. Zmiana rozmiaru partycji systemowej, przebudowa partycji EFI, klonowanie dysku, naprawa programu rozruchowego lub odtwarzanie obrazu systemu może zmienić elementy obserwowane przez BitLocker. Jeżeli po takiej operacji pojawi się komunikat o niezgodności, konieczne bywa odtworzenie prawidłowej struktury rozruchowej, ponowne zarejestrowanie konfiguracji albo czasowe zawieszenie ochrony przed wykonaniem kontrolowanej zmiany.

Do podobnych objawów może prowadzić uszkodzenie plików startowych Windows, niezgodny sterownik ładowany przed systemem, awaria płyty głównej lub wymiana dysku bez wcześniejszego przygotowania zabezpieczeń. Niekiedy przyczyną jest także nieprawidłowa data i godzina w firmware’ze, błędny wpis startowy albo podłączenie dysku do innego komputera. Przed przywracaniem systemu należy ustalić, czy celem jest odzyskanie dostępu do danych, naprawa uruchamiania, czy zachowanie istniejącego szyfrowania.

Podstawowa diagnostyka obejmuje sprawdzenie komunikatów pojawiających się przed startem Windows, statusu Secure Boot w UEFI, trybu UEFI lub Legacy, stanu modułu TPM oraz informacji dostępnych w narzędziach systemowych. Warto także potwierdzić, czy klucz odzyskiwania odpowiada konkretnemu urządzeniu. Samo posiadanie kilku kluczy nie wystarcza, jeżeli nie można rozpoznać właściwego identyfikatora. Bez klucza odzyskiwania odblokowanie zaszyfrowanych danych może nie być możliwe, nawet gdy sprzęt działa poprawnie.

Kiedy trzeba poprosić o ocenę stanu sprzętu - BitLocker nie współpracuje z Secure Boot

Zgłoszenie do serwisu jest uzasadnione, gdy po zmianie ustawień UEFI komputer przestał uruchamiać Windows, BitLocker wielokrotnie żąda klucza odzyskiwania, Secure Boot samoczynnie przechodzi w stan wyłączony albo nie można ustalić, czy system pracuje w trybie UEFI. Pomocy warto poszukać również przed czyszczeniem TPM, wymianą płyty głównej, klonowaniem dysku i naprawą partycji rozruchowej, ponieważ niekontrolowana zmiana może utrudnić dostęp do danych.

Podczas przyjmowania urządzenia powinno się przekazać informacje o ostatnich zmianach: aktualizacji firmware’u, instalacji systemu, wymianie dysku, resetowaniu ustawień UEFI lub pojawieniu się konkretnego komunikatu. Jeżeli dostępny jest klucz odzyskiwania BitLocker, należy przygotować go do bezpiecznej weryfikacji. Nie należy publikować go w wiadomości do przypadkowych osób ani zapisywać w miejscu dostępnym dla niepowołanych użytkowników.

W przypadku laptopa w Warszawie można skorzystać z Warszawskiego Pogotowia Komputerowego 24/7, gdzie przed rozpoczęciem naprawy wykonywana jest darmowa diagnoza laptopa. Pozwala to ustalić, czy przyczyną jest jedynie konfiguracja Secure Boot, problem z TPM, uszkodzenie środowiska UEFI, czy też szersza awaria związana z rozruchem systemu. Po rozpoznaniu sytuacji można dobrać sposób postępowania tak, aby ograniczyć ryzyko utraty danych i nie wyłączać szyfrowania bez wyraźnej potrzeby.

Jeżeli system nadal działa, nie powinno się wyłączać BitLocker bez przygotowania kopii zapasowej i potwierdzenia, że dane można odtworzyć. W pierwszej kolejności sprawdza się stan ochrony, dostępność klucza odzyskiwania i zgodność trybu rozruchu z ustawieniami UEFI. Dopiero potem można rozważyć naprawę wpisów startowych, zmianę konfiguracji Secure Boot albo ponowne powiązanie zabezpieczeń z modułem TPM.