Bitlocker Drive Encryption – jak to ugryźć, cz. II

Opublikowano: 23 listopada 2006

Bitlocker jest jedną z najciekawszych funkcjonalności wprowadzonych w Windows Vista. W przeciwieństwie do wielu innych nowości w systemie, Bitlocker nie jest mniej lub bardziej wyszukanym udoskonaleniem czegoś, co już wszyscy widzieli wcześniej, ale innowacją w pełnym znaczeniu tego słowa. Jak przy każdej nowince w branży IT, potencjalnym użytkownikom nasuwają się dwa pytania: o co tak naprawdę w tym chodzi i co można na tym zyskać. Odpowiedź na te pytania nie jest trudna, a niniejszy artykuł powinien jej uważnemu czytelnikowi dostarczyć.

*
Zawartość strony
KluczeKlucze
OdzyskiwanieOdzyskiwanie
TeoriaTeoria
PraktykaPraktyka
PodsumowaniePodsumowanie
Przeczytaj pozostałe części artykułuPrzeczytaj pozostałe części artykułu

Klucze

Jak już zostało to wyjaśnione, dla rozszyfrowania partycji potrzebny jest VEK czyli Volume Encryption Key. Klucz VEK jest zapisany na niezaszyfrowanej partycji, ale sam zaszyfrowany jest kluczem SRK wyliczanym przez TPM na podstawie wykonywanego przez procesor kodu. Gdyby Bitlocker ograniczał się do takiej funkcjonalności, to jakakolwiek zmiana w komputerze lub systemie prowadziłaby do otrzymania dysku, którego nikt nie umiałby rozszyfrować, włącznie z właścicielem. Aż tak dobre zabezpieczenie informacji jest zazwyczaj niepożądane.

Aby uniknąć takich sytuacji, VEK można obliczyć nie tylko tą jedną metodą przy użyciu TPM. W praktyce, klucz ten szyfrowany jest kilkoma różnymi metodami i dla każdej z nich zapisywany na partycji boot. Jeżeli TPM policzy właściwą sumę, to VEK wyliczany jest automatycznie a partycja staje się dostępna. Jeżeli modułowi TPM nie uda się wyliczyć właściwego klucza SRK, podejmowana jest próba odszyfrowania innego egzemplarza VEK zaszyfrowanego przy użyciu klucza liczbowego złożonego z 48 cyfr i wprowadzonego z klawiatury. Klucz VEK można też podać na nośniku USB! Ważne tylko, żeby system go dostał, a natychmiast umożliwi dostęp do zaszyfrowanej partycji. Liczba takich kluczy pomocniczych nie jest niczym ograniczona i równocześnie może istnieć dowolna ich ilość.

Możliwe jest również zapisanie klucza VEK na partycji boot bez żadnego szyfrowania, co oznacza w praktyce zdjęcie jakiejkolwiek ochrony z dysku! Ale czasem to właśnie jest niezbędne. Przykładowo - wiedząc, że instalowany będzie Service Pack lub modyfikowany BIOS, w systemie można wskazać, że na partycji boot ma się znaleźć VEK w formie jawnej. W takiej sytuacji system ma dostęp do danych niezależnie od tego, co policzy TPM. Po zakończeniu prowadzonych modyfikacji TPM liczy nową sumę kontrolną, szyfruje nią jawną postać klucza VEK i zapisuje na dysku. Od tej pory znowu tylko TPM i oryginalny kod umożliwiają automatyczne rozszyfrowanie dysku.

Warto wiedzieć, że poza kluczem chronionym TPM, kluczem chronionym 48 cyframi, i kluczem w formie jawnej (chwilowo na partycji boot lub trwale na nośniku USB) istnieją jeszcze inne formy zapisania informacji potrzebnej do odszyfrowania partycji. W szczególności są to klucze chronione przez napęd USB, klucze chronione równocześnie przez TPM i napęd USB oraz klucze chronione przez TPM i pin. W przypadku ostatnim, niezależnie od wyliczenia prawidłowej wartości przez TPM, konieczne jest podanie prawidłowego pinu złożonego z 4 do 20 cyfr. Podobnie jak w innych obszarach Bitlockera, pin ten nie jest nigdzie zapisywany, więc nie istnieje możliwość odczytania go z dysku czy rejestru. Jeżeli użytkownik poda dobry pin, dane (a w zasadzie VEK) zostaną odszyfrowane poprawnie. Jeżeli pin będzie zły, to system nie uruchomi się. Ochrona przy pomocy nośnika USB nie wydaje się szczególnie skuteczna. Wprawdzie cały dysk jest zaszyfrowany, ale w przypadku kradzieży notebooka, klucz USB prawdopodobnie będzie znajdował się w tej samej teczce, w której przenoszony był komputer. Połączenie TPM z napędem USB jest możliwe, jednak trudno uznać, że poziom ochrony jest wyższy niż w przypadku samego TPM, podczas gdy wyraźnie wzrasta uciążliwość związana z użyciem takiego rozwiązania.

W przypadku szyfrowania partycji innych niż systemowa, klucze nie mogą być chronione przez TPM. Użytkownikowi pozostaje klucz liczbowy, klucz zapisany na nośniku USB lub klucz w rejestrze. Ta ostatnia opcja jest jedyną możliwością automatycznego podłączania zaszyfrowanej partycji. Skorzystanie z klucza w rejestrze sprawia, że dysk rozszyfrowywany jest bez ingerencji użytkownika, co w przypadku Bitlockera jest szczególnie cenne.

Ostatnim już miejscem, gdzie klucze można przechować, jest Active Directory. Tam zapisywane są (oczywiście po rozszerzeniu schemy) klucze liczbowe. Nie są one w żaden sposób automatycznie wykorzystywane, jednak w razie potrzeby dobrze jest mieć centralne repozytorium kluczy.

Ciekawostką związaną z kluczami liczbowymi jest ich wartość. Złożony z 48 cyfr klucz podzielony jest na 8 pól po 6 cyfr. Każda taka sześciocyfrowa sekcja zawsze jest mniejsza od 720896 i zawsze podzielna przez 11. Szyfrując dysk, klucz taki można wygenerować automatycznie lub podać samodzielnie. Wymogi arytmetyczne sprawiają jednak, że własnoręczne wymyślanie takiego klucza nie jest często spotykane w praktyce.

Do początku stronyDo początku strony

Odzyskiwanie

Zanim stanie się coś złego, warto zapewnić sobie możliwość awaryjnego dotarcia do danych. Rozważyć można kilka scenariuszy w zależności od tego czy zawiedzie mechanizm tworzenia kluczy przez TPM, czy sam system operacyjny na partycji, do której udało się poprawnie wyliczyć klucze. W przypadku, kiedy poprawny klucz do odszyfrowania VEK nie zostanie wygenerowany przez TPM, system wyświetli komunikat z prośbą o podanie klucza "ręcznie". W praktyce, w takiej sytuacji najłatwiej dotrzeć do kluczy liczbowych (najlepiej w Active Directory) i podać taki klucz systemowi, który powinien bez dalszych kłopotów dać się uruchomić. Jeżeli system zostanie uruchomiony, stosunkowo łatwo można w TPM wygenerować nowy SRK, który będzie już od tej pory działał automatycznie.

W przypadku, kiedy system na zaszyfrowanej partycji przestanie się nadawać do użycia, w zasadzie najlepszą metodą jest podłączenie dysku do innego komputera. Dysk taki oczywiście nie zostanie automatycznie udostępniony, jednak podając właściwy klucz liczbowy można go podłączyć do czasu najbliższego restartu. Tak podłączony dysk można albo rozszyfrować albo po prostu zgrać z niego dane. Należy pamiętać, że powodzenie operacji odzyskania danych zależy od tego, czy klucze liczbowe zostały wygenerowane i bezpiecznie zapisane. W przypadku GUI Bitlockera jest to dość łatwe. Użycie narzędzi wiersza poleceń wymaga pamiętania o tym, że kiedyś może się przydać awaryjna metoda dostępu.

Do początku stronyDo początku strony

Teoria

Od strony teoretycznej algorytmy kryptograficzne postawiły twórców Bitlockera przed niemałym wyzwaniem. Wynika ono z tego, że należało wybrać algorytm, który będzie szybki i bezpieczny równocześnie. Bezpieczny oznacza tu między innymi, że wprowadzone przez atakującego zmiany w zaszyfrowanym sektorze nie mogą przełożyć się w żaden przewidywalny sposób na jawną formę jego zawartości. Parametr ten nazywany jest dyfuzją i określa, ile bitów postaci jawnej zmieni się w sektorze przy zmianie jednego bitu przed rozszyfrowaniem. Sytuacja idealna zakłada, że zmieni się 50% bitów losowo rozłożonych w całym sektorze. Ponadto, kluczowym wymaganiem było, aby zaszyfrowane dane z sektora nie przekroczyły rozmiaru sektora. Jeden sektor ma zazwyczaj 512B i po zaszyfrowaniu nie może powstać ani jeden bajt więcej, ponieważ nie będzie go gdzie zapisać.

Zastosowanie jakiegoś egzotycznego, lub co gorsza własnego, opracowanego w Microsoft algorytmu, sprawiłoby, że nikt nie ufałby takiemu rozwiązaniu. Z drugiej jednak strony, ilość powszechnie stosowanych bezpiecznych algorytmów kryptograficznych jest na tyle niewielka, że możliwe było kolejne ich weryfikowanie pod kątem zgodności z wymaganiami oraz pod kątem szybkości działania. W obecnych komputerach, w czasie potrzebnym do odczytania jednego bajta danych, zegar procesora wykonuje około 40-60 taktów w zależności od sprzętu. Przyjąć można, że około 35 taktów na samo szyfrowanie i rozszyfrowanie bajta informacji jest wartością krytyczną, powyżej której użytkownik zacznie odczuwać problemy z wydajnością systemu.

Testy prowadzone w Microsoft objęły różne rozwiązania, takie jak algorytmy strumieniowe (całkowity brak dyfuzji), "Bear and Lion" (wymagający niemal 100 cykli na bajt), "Beast" (nieco szybszy jednak nie gwarantujący dobrej dyfuzji danych), VIL (brak dyfuzji i dziwne wymagania związane z patentami), Mercy (zaprojektowany specjalnie do takich rozwiązań, jednak złamany w 2001 roku), LRW (posiadający zbyt mały, ograniczony do 16 bajtów blok, na którym operuje pojedynczy przebieg), CMC i EME (zaprojektowane do szyfrowania dysków, jednak chronione patentami i tak naprawdę szerzej nieznane, przez co słabo zbadane).

W efekcie zdecydowano się na dobry i uznany algorytm AES-CBC, wymagający około 20 cykli na bajt. Wątpliwości pozostawiała kwestia dyfuzji danych. Aby rozwiązać ten problem, opracowano własny dyfuzor pracujący z prędkością około 10 cykli na bajt. Dyfuzor ten miesza dane, które następnie przekazywane są do zaszyfrowania algorytmem AES-CBC. Jak łatwo udowodnić, rozwiązanie takie z punktu widzenia analizy kryptograficznej jest nie słabsze niż sam AES-CBC, który powszechnie uznany jest za algorytm gwarantujący dobre bezpieczeństwo. Algorytm dyfuzora jest znany i opublikowany jednak nie istnieją jeszcze poważne opracowania dotyczące jego skuteczności. Zdając sobie sprawę, że w niektórych (głównie rządowych) środowiskach, użycie jakiegokolwiek niezatwierdzonego algorytmu jest niedozwolone, Microsoft pozostawił możliwość wyłączenia mechanizmów dyfuzora.

W efekcie powstało rozwiązanie, które otrzymując dane do zapisania w sektorze wykonuje następujące operacje:

Na podstawie klucza VEK i numeru sektora wylicza klucz sektora

Miesza dane sektora poprzez dwukrotne użycie dyfuzora Szyfruje dane algorytmem AES-CBC

Kieruje otrzymane dane do zapisania na dysk. W efekcie powstało rozwiązanie, które zapewniając dobrą dyfuzję i używając uznanych algorytmów, powoduje stratę wydajności systemu nie przekraczającą zwykle 5%.

Do początku stronyDo początku strony

Praktyka

W praktycznym użyciu Bitlockera warto zwrócić uwagę na fakt, że dla poprawnej współpracy z TPM niezbędne jest zainicjowanie tego modułu. Wykonuje się to jeden raz na każdym komputerze przy użyciu przystawki tpm.msc. Ewentualne kłopoty na tym etapie oznaczają, że BIOS komputera jest nie w pełni zgodny z wymaganiami Windows Vista. Zazwyczaj, dla wszystkich komputerów wyposażonych w TPM w wersji 1.2 oznacza to, że konieczna jest aktualizacja Biosu płyty głównej. Ponieważ jednak Windows Vista nie jest jeszcze (listopad 2006) oficjalnie wspieranym systemem, to aktualizacja taka często nie jest łatwo dostępna. W praktyce, mimo braku oficjalnego wsparcia, kontakt z producentem pozwala dotrzeć do specjalnych wersji BIOSu w ciągu kilku minut.

Choć Bitlocker wyposażony został w GUI (dostępne w panelu sterowania – security) to jednak należy przyjąć, że z wyjątkiem sytuacji szyfrowania partycji Windows z użyciem TPM, interfejs ten oferuje zbyt małą funkcjonalność. W szczególności nie daje on dostępu do żadnych opcji związanych z dyskami innymi niż systemowy.

Aby uzyskać dostęp do całej potęgi Bitlockera, należy użyć narzędzia manage-bde.wsf znajdującego się w katalogu system32. Uruchamiając ten skrypt, w linii poleceń należy wpisać "cscript manage-bde.wsf". Co ważne, dostęp do funkcji związanych z zarządzaniem Bitlockerem ma wyłącznie administrator systemu. Z tego powodu, z takimi właśnie uprawnieniami musi być uruchomiony wiersz poleceń. Albo poprzez wybranie z menu kontekstowego "Run as Administrator", albo poprzez reset hasła, odblokowanie konta i polecenie "runas /u:administrator cmd.exe".

Najważniejszym parametrem wiersza poleceń dla pracy ze skryptem "manage-bde.wsf" jest parametr "–h". Parametr ten wyświetla pomoc związaną z konkretnymi funkcjami skryptu. Funkcje te to przede wszystkim:

"status" - wyświetla bieżące informacje na temat dysków. W informacjach tych znajdują się dane na temat rozmiaru partycji, postępu szyfrowania, stosowanego algorytmu oraz dane o sposobie zaszyfrowania VEK. Ponadto, wyświetlana jest informacja o tym, czy dany dysk został podłączony do systemu i czy to podłączanie odbywa się automatycznie

"on" - włącza szyfrowanie dla wybranego dysku. Opcja ta pozwala na wybranie algorytmu szyfrowania (z dyfuzorem lub bez, AES128 lub AES256) oraz wybranie metody, którą wyliczany jest VEK. Może być to klucz liczbowy lub klucz w pliku na nośniku USB, a w przypadku dysku systemowego również klucz chroniony przez TPM i ewentualnie pin. Klucze liczbowe mogą być podane jako parametr lub mogą być wygenerowane automatycznie, przy czym nie wolno zapomnieć o ich zapisaniu w bezpiecznym miejscu

"off" - rozszyfrowuje wskazany dysk

"pause" i "resume" - opcje pozwalające wstrzymywać i wznawiać proces szyfrowania całego dysku

"lock" i "unlock" - włącza i wyłącza dostęp do dysku w systemie. Domyślnie, po restarcie wszystkie niesystemowe dyski są w stanie "lock" i trzeba podając klucz je włączyć, żeby móc z nich skorzystać

"autounlock" - umożliwia zapisanie klucza w rejestrze, przez co dysk ma automatycznie wykonywaną operację "unlock" przy każdym starcie systemu. Jest to w praktyce bardzo użyteczna funkcjonalność

"protectors" - zarządza kluczami pozwalającymi rozszyfrować VEK. Dzięki tej opcji możliwe jest dodanie dowolnej ilości kluczy liczbowych i plikowych dla każdego zabezpieczanego dysku.

Podsumowując, stwierdzić można, że zarządzanie przez skrypt manage-bde.wsf pozwala uzyskać funkcjonalność o wiele większą niż w przypadku GUI. W praktyce, użycie GUI w ogóle nie wydaje się niezbędne. Ciekawym przypadkiem użycia Bitlockera jest system dual boot, w którym obie partycje systemowe są zaszyfrowane. Aby mieć dostęp do dysków obu systemów, należy "na krzyż" dodać klucz drugiej partycji do rejestru przy użyciu opcji autounlock. Wymaga to oczywiście wprowadzenia poprawnego klucza liczbowego.

Do początku stronyDo początku strony

Podsumowanie

Kończąc rozważania na temat Bitlockera należy postawić zasadnicze - dla każdego właściciela informacji - pytanie "Czy to zabezpieczenie można złamać?". Odpowiedź brzmi "Tak można, bo nie ma zabezpieczeń nie do złamania". W praktyce jednak, tak teoretyczna analiza zastosowanych rozwiązań, jak i praktyczne badania wykazują, że złamanie takie nie jest realne w dostępnych zwykłym śmiertelnikom warunkach. Oznacza to, że tak naprawdę, najsłabszym ogniwem okazuje się hasło użytkownika. Dobrze skonfigurowany Bitlocker może być zupełnie niezauważalny i równocześnie naprawdę chronić informacje. Prowadzi to do jedynego uzasadnionego w takiej sytuacji wniosku, że w przypadku komputerów przenośnych, niezastosowanie Bitlockera tam, gdzie zastosować go można, jest bardzo marnym pomysłem.

Do początku stronyDo początku strony

Przeczytaj pozostałe części artykułu

Bitlocker Drive Encryption – jak to ugryźć, cz. I


Grzegorz Tworek

Grzegorz Tworek (Konsultant ISCG, MVP)
Inżynier systemowy, komputerowiec w drugim pokoleniu. Od wielu lat aktywnie promuje idee związane z bezpieczeństwem informatyki, zwłaszcza w powiązaniu z systemami Microsoft. Autor artykułów i książek na temat security, prelegent na rozmaitych konferencjach. Aktywnie uczestniczy w działaniach SEClub. Równie duży zapał do tworzenia jak i do psucia systemów sprawia, że w projektach najchętniej uczestniczy jako audytor. W lipcu 2007 został nagrodzony tytułem Most Valuable Professional w kategorii Enterprise Security. Prowadzi polski blog TechNet.


Do początku stronyDo początku strony