Ubuntu i szyfrowanie dysku z wykorzystaniem klucza na dysku USB
2009-06-25, Czwartek 05:13:22 +0200, autor Karol „Zal” Zalewski, licencja LPRCTKC
Wstęp
Już wiele razy wspominałem o możliwości szyfrowania dysków twardych z wykorzystaniem DM-Crypt oraz LUKS. Całość działa całkiem sprawnie zarówno pod Linuksem, jak i Windowsem (ten ostatni wymaga FreeOTFE), a do tego wiele dystrybucji Linuksa (m.in. Ubuntu) umożliwia utworzenie zaszyfrowanych partycji już podczas instalacji systemu. Po tej ostatniej operacji każda próba uruchomienia systemu zostanie poprzedzona prośbą o podanie hasła. I tutaj pojawia się pytanie.
A co gdyby tak zamiast mozolnego podawania hasła, wystarczyło podłączyć do komputera odpowiedni pendrive pełniący rolę sprzętowego klucza? Oto i rozwiązanie przeznaczone dla systemu Ubuntu 9.04 z zaszyfrowanym już dyskiem (DM-Crypt + LUKS)!
Przygotowanie klucza
Z powyższym problemem poradzimy sobie umieszczając na pamięci Flash plik będący kluczem umożliwiającym odszyfrowanie danych. Zacznijmy zatem od przygotowania dysku USB.
Na samym początku dzielimy dysk na partycje, lub tworzymy jedną dużą partycję przy pomocy programu cfdisk, lub fdisk. Jest to konieczne ze względu na sposób działania skryptu, który zostanie pokazany w późniejszej części wpisu. Następnie formatujemy wybraną partycję z wykorzystaniem systemu plików Ext2. Mój dysk USB ma obecnie oznaczenie /dev/sdb i na nim wykonuję wszystkie operacje.
sudo cfdisk /dev/sdb sudo mkfs.ext2 /dev/sdb1
Co dalej? Przygotujmy klucz!
sudo mkdir /media/Crypto sudo mount /dev/sdb1 /media/Crypto sudo dd if=/dev/urandom of=/media/Crypto/klucz bs=512 count=4
Plik nie powinien być ukryty (np. poprzez dodanie "." na początku jego nazwy), ani zawierać liter spoza ASCII. Teraz wystarczy dodać obsługę naszego klucza do wcześniej zaszyfrowanej partycji. W moim przypadku mowa o partycji /dev/sda3. Poniżej znajduje się komenda, którą należy wykonać. Należy pamiętać, iż do jej wykonania są potrzebne nie tylko uprawnienia administratora, ale również jedno z haseł LUKS-a, które posłużyły do zaszyfrowania dysku twardego.
sudo cryptsetup luksAddKey /dev/sda3 /media/Crypto/klucz
I to właściwie koniec zabawy po stronie dysku USB. Możemy go odmontować i na jakiś czas schować w bezpiecznym miejscu.
Przygotowanie systemu operacyjnego
Problem z Ubuntu polega na tym, iż twórcy dystrybucji dostarczają jedynie skrypt niezbędny do deszyfrowania dysków przy pomocy hasła podanego przez użytkownika. My zaś chcemy uzyskać możliwość automatycznego pobrania pliku z hasłem z dysku USB, a w przypadku jego braku - podać je ręcznie. W tym celu wykorzystamy skrypt stworzony przez Wejna.
Nim to jednak nastąpi - ostrzegam! Zmiany, które teraz wprowadzamy mają istotny wpływ na sposób funkcjonowania systemu operacyjnego. Błędy w ich wprowadzaniu mogą doprowadzić nie tylko do problemów z jego uruchomieniem, ale również do zniszczenia danych na dysku! Wszystko, co tutaj zawarłem zostało przeze mnie przetestowane i funkcjonuje w moim systemie. Nie oznacza to jednak, iż biorę odpowiedzialność za straty spowodowane poniższym opisem. Wybrany system plików, stworzenie partycji na dysku USB, czy też nawet nazwa pliku mają znaczenie. I to duże, o czym sam się przekonałem w ciągu kilku godzin zabawy z tym rozwiązaniem.
cd /usr/local/sbin sudo wget http://blog.4zal.net/files/beckman-crypto-usb-key.sh sudo mv beckman-crypto-usb-key.sh keyscript sudo chmod 755 keyscript
Skrypt ten jest o tyle interesujący, iż sam wykrywa podłączone do komputera dyski USB w trakcie uruchamiania systemu operacyjnego, a następnie usiłuje pobrać z nich plik z kluczem o podanej przez użytkownika nazwie. Jego nazwę określa się poprzez edycję pliku /etc/crypttab. Poniżej widać poprawną zawartość tego pliku tekstowego. "Klucz" oznacza nazwę pliku z kluczem (normalnie znajduje się tam wartość "none"), a dodatkowy atrybut "keyscript" pokazuje lokalizację ww. skryptu.
# [target name] [source device] [key file] [options] sda3_crypt /dev/disk/by-uuid/54f....-751a3a4f239a klucz luks,keyscript=/usr/local/sbin/keyscript
Jesteśmy już prawie na końcu. Należy teraz jeszcze dodać do pliku /etc/initramfs-tools/modules informację o jednym module, który będziemy chcieli załadować jeszcze przed uzyskaniem dostępu do głównego systemu plików. Jest on odpowiedzialny za obsługę dysków USB.
usb_storage
Po wykonaniu wszystkich powyższych czynności czas na stworzenie nowego pliku initrd.img odpowiedzialnego za tworzenie podczas bootowania systemu pierwotnego, najprostszego środowiska w którym funkcjonuje jądro. Należy pamiętać, iż błędy w ww. skrypcie, czy też w pliku crypttab mogą w znaczący sposób uniemożliwić nam dostęp do naszych danych, a w skrajnych przypadkach nawet je zniszczyć. Przed wykonaniem poniższego polecenia zalecam zrobienie kopi zapasowej obecnego pliku initrd.img z folderu /boot, gdyż zostanie on nadpisany. Co ważniejsze - warto przygotować GRUB-a do wykorzystania jego starej wersji na wypadek porażki przy uruchamianiu systemu przy obecności nowej wersji tego pliku.
sudo update-initramfs -u ALL
Po ponownym uruchomieniu system powinien samodzielnie przeszukać podłączone dyski USB pod kątem opisanego pliku z kluczem, a w przypadku jego nieodnalezienia - poprosi o podanie hasła przez użytkownika.
Należy pamiętać, iż wprowadzone w ten sposób ustawienia są stałe i nie znikną wraz z aktualizacją jądra systemu Linux z tego względu, iż initrd.img, w którym znajdują się wprowadzone zmiany, jest generowany na komputerze użytkownika nawet przy aktualizacji kernela.
Podsumowanie
Jeżeli wszystko poszło po naszej myśli, od teraz system możemy uruchamiać tradycyjnie, podając hasło przy starcie, lub podłączając na czas startu pendrive zawierającego klucz umożliwiający dostęp do dysku. LUKS obsługuje bodajże do ośmiu różnych kluczy przypadających na jeden zaszyfrowany wolumen.
Mam nadzieję, iż opis ten okaże się przydatny i zachęci Was do samodzielnych eksperymentów. Nic nie stoi przecież na przeszkodzie, aby wspomniany skrypt pobierał dane tylko i wyłącznie z jednego, konkretnego dysku USB (korzystając z informacji o jego numerze seryjnym, czy też UUID), co mogłoby stanowić dodatkowe utrudnienie przy próbie dostępu do komputera. Powodzenia!
2009-06-25 o Czwartek 05:38:37 +0200
U mnie funkcjonuje bardzo podobne rozwiązanie oparte o Truecrypt, ale daleko prostrze. Ogranicza się do mount /media/pendrive; truecrypt [z odpowiednimi paramatrami]; umount /media/pendrive. Wkładam pendriva przy starcie i działa.
(system nie jest szyfrowany (po co?) - szyfrowana jest osobna partycja z danymi z /home, /var i czegoś tam jeszcze)
Wielkie dzięki za wpisy o szyfrowaniu. Rozważam przejście na DM-Crypt + LUKS. Z TC były (ponoć) jakieś problemy z licencją, a Twoje rozwiązanie wydaje się być coraz bardziej 'natywne' dla Linuksa. W TC używam potrójnego algorytmu (Twofish-Serpent-AES). Czuję się przez to bezpieczniej ^^. Chociaż pewnie i tak nie ma dużej różnicy. Poza tym ONI i tak już wszystko wiedzą. Nie mniej jednak mam zamiar zacząć się tym bawić (częściowo dla tego, że to wszystko zbyt długo działa bezawaryjnie).
2009-06-25 o Czwartek 06:43:10 +0200
Nie masz co robić w nocy ? ;>
2009-06-25 o Czwartek 07:21:21 +0200
Czy to rozwiązanie działa bez TPM?
2009-06-25 o Czwartek 09:28:20 +0200
@q84_fH: Dobrze ujęte, DM-Crypt + LUKS to rozwiązanie bliższe Linuksowi i stające się, a może już nawet będące, standardem. Swoją drogą to interesujące - nadal nie wiem, czy DM-Crypt pozwala na szyfrowanie z wykorzystaniem kaskadowego połączenia kilku cipherów. Muszę poczytać manuala, albo tutoriala :D
A co do wydajności, bo wiem, że niektórych może to interesować - można znaleźć wiele informacji na ten temat w I-necie np. na blogu WPKG (nie uwzględniono dod. obciążenia procesora i pamięci).
@Szymon: Przecież nie będę się do egzaminów uczyć! :D A tak serio - wiesz, jak to jest, "jeszcze jeden restart i na pewno zacznie działać". I tak do białego rana.
@Karol: Pewnie. Do tej pory tylko jeden konkretniejszy wpis poświęciłem TPM-owi. Niestety, po dłuższych przemyśleniach uważam, że TPM nie jest aż tak szczęśliwym rozwiązaniem, jakby się mogło wydawać. Najwięcej korzyści przynosi chyba osobom chcącym wykorzystać w nieco bardziej finezyjny sposób "dobrodziejstwa" DRM. Gdyby tak jeszcze przyśpieszał działanie szyfrowania symetrycznego.
Tak, czy inaczej - zarówno TrueCrypt (Linux + Windows), jak i para DM-Crypt + LUKS (pod Windowsem FreeOTFE) nie wymagają wsparcia ze strony sprzętu.
2009-06-25 o Czwartek 09:39:51 +0200
q84_fH: O jakich problemach z licencją TrueCrypta mówisz? Wygląda na standardową licencję z cyklu free and open-source z ochroną marki (nie można rozpowszechniać zmodyfikowanej wersji pod oryginalną nazwą ani korzystać z logo), zbliżoną licencję ma Firefox.
2009-06-25 o Czwartek 09:42:33 +0200
@Grzegorz: Wiem, że cytowanie Wikipedii jest "BE", bo to źródło wtórne, ale załóżmy, że do dyskusji w Internecie "może być" :D
Na marginesie - nie będę poprawiać obecnie Twojego komentarza (omsknął Ci się palec z dwukropka podczas korzystania z Textile). Po mojej poprawce w ogóle utraciłbyś możliwość jego edycji :]
[EDIT] Widzę, że już poprawiłeś :)
2009-06-25 o Czwartek 09:53:16 +0200
Zal: Wikipedia praktycznie nie wyjaśnia, o co konkretnie chodzi. Szybka lektura odnośników ze źródeł też nic szczegółowego nie mówi:
Deweloperzy Debiana nazwali punkt III.1.d prawniczą bombą, zwykły użytkownik jestem, ale mi to wygląda na "gwarancję" udostępniania zmodyfikowanego kodu (jak w GPL). Jest tego więcej, ale powiem szczerze to dość pogmatwana sprawa i nie chce mi się tego czytać po angielsku...
P.S. Poprawiłem jeszcze zanim odpowiedziałeś na mój komentarz ;) Teraz Ty usuń indeksy przypisów w cytacie z Wikipedii bo prowadzą donikąd.
2009-06-25 o Czwartek 15:43:54 +0200
@Grzegorz: W sprawy licencyjne, szczególnie w sprawy autorskich licencji, staram się nie mieszać :D Szczególnie, gdy taka licencja ma więcej, niż trzy linie tekstu. Brr... Prawo
BTW - poprawiłem w tekście kilka błędów merytorycznych, które przed chwilą zauważyłem, a które na całe szczęście w żaden sposób nie wpływają na działanie opisanej metody. M.in. zmieniłem /boot/initramfs na /boot/initrd.img ;]
2009-06-25 o Czwartek 15:49:36 +0200
Zal: A jest możliwość "miksowania" wprowadzania hasła, teraz podajemy hasło lub podłączamy pendrve. Masz kontener lub partycję szyfrowaną, nazwijmy ją A. Zastanawiam się nad takim scenariuszem: (1) podajesz hasło - montowany jest wolumen A-poziom 1, podajesz hasło i pendrive - montowany jest wolumen A-poziom 2. TrueCrypt potrafi tworzyć ukryte wolumeny, w ramach jednej partycji lub szyfrowanego kontenera, montowanie zależy właśnie od podanego hasła. Dwa źródła hasła z pewnością dodatkowo skomplikowałyby próby jego złamania.
2009-06-25 o Czwartek 15:53:47 +0200
@Grzegorz: Wiem, co masz na myśli. Kojarzę tę funkcjonalność z TrueCrypt - pomysłowe i przydatne w przypadku konieczności zdradzenia hasła dostępu do danych. Niestety, w przypadku DM-Crypt i LUKS nie spotkałem się z tym rozwiązaniem. LUKS umożliwia jedynie obsługę do 8 kluczy (hasła, pliki na pendrive, czy poszczególne jego sektory) dających możliwość dostania się do tych samych danych. A posiadanie jednego klucza umożliwia usuwanie/dodawanie innych kluczy.