Paweł Goleń, blog

Scenariusz

Dla ułatwienia wszystkie eksperymenty będę przeprowadzał na wolumenie TrueCrypt o rozmiarze 64MiB założony w pliku (file hosted), lecz równie dobrze może się to odnosić do wolumenów, które są device hosted. Nie zajmuję się funkcją Hidden Volume, jak również pomijam dynamic volumes.

To, co chcę przede wszystkim sprawdzić, a właściwie eksperymentalnie potwierdzić, to:

• jak "łatwo" jest uszkodzić wolumen,
• czy można modyfikować pliki wewnątrz wolumenu,

Format pliku TrueCrypt

Format pliku jest opisany w dokumentacji projektu w TrueCrypt Volume Format Specification. Interesujący fragment poniżej:

Upraszczając plik TrueCrypt składa się z:

• nagłówka,
• nagłówka wolumenu ukrytego,
• "danych właściwych",
• kopii nagłówka "głównego" wykorzystujący inny salt,
• kopii nagłówka wolumenu ukrytego wykorzystującej inny salt,

Co by tu zepsuć...

Uszkodzenie nagłówka

Co zepsuć, by uniemożliwić dostęp do zaszyfrowanych "danych właściwych"? Wystarczy uszkodzić klucze wykorzystane do szyfrowania danych, patrz Modes of Operation. Wykorzystywane są dwa klucze, które zapisane są w nagłówku pliku w formie zaszyfrowanej z wykorzystaniem hasła oraz salt (też zapisanego w nagłówku pliku). Można więc:

• zmodyfikować salt (0-64),
• uszkodzić zaszyfrowane klucze (256-512),

Zgodnie z przewidywaniami modyfikacja nawet jednego bitu salta lub kluczy powoduje, że plik nie może zostać podmontowany, pojawia się wiele mówiący komunikat Incorrect password for TrueCrypt volume. Ten sam efekt osiągnie się modyfikując zaszyfrowany ciąg TRUE (64-68). Jeśli po wyliczeniu kluczy i rozszyfrowaniu tej wartości otrzymany rezultat nie jest TRUE właśnie, oznacza to (z założenia), że podane hasło nie było prawidłowe (dokładniejsze informacje: Encryption Scheme).

"Prawdziwy twardziel nie robi backupu", na szczęście twórcy TrueCrypt pomyśleli za twardzieli i backup nagłówka został umieszczony domyślnie w pliku. UWAGA: w przypadku system encryption ta automatyczna kopia zapasowa nie jest wykonywana.

By skorzystać z zapasowego nagłówka, należy w GUI wybrać opcję Mount Options i zaznaczyć Use backup header embeded in volume if available.

Niezależnie od zapobiegliwości twórców TrueCrypt we własnym interesie należy wykonywać kopię zapasową nagłówka. Bez tego odzyskanie zaszyfrowanych danych może okazać się niemożliwe.

"Dane właściwe"

Zgodnie ze specyfikacją formatu pliku, "dane właściwe" znajdują się od 131072 (0x20000) do S-131072, gdzie S jest rozmiarem pliku. Oczywiste jest, że modyfikacja danych zaszyfrowanych spowoduje jednocześnie modyfikację danych rozszyfrowanych. Co więcej w przypadku niektórych trybów szyfrowania modyfikacja ta może być przewidywalna. Ciekawą lekturą (na wprowadzenie) może być Disk encryption theory. TrueCrypt korzysta obecnie z trybu XTS.

Jak będzie wyglądała modyfikacja tekstu jawnego, w przypadku modyfikacji lub uszkodzenia pliku TrueCrypt? Można zrobić prosty eksperyment. W zaszyfrowanym wolumenie utworzyłem plik tekstowy, następnie sprawdziłem gdzie plik został utworzony (offset w wolumenie) i uwzględniając format pliku TC wyliczyłem gdzie dane z założonego pliku powinny się znajdować. Wygląda to mniej więcej następująco:

• offset w zaszyfrowanym systemie plików: 0x1E92000,
• offset w pliku TC (uwzględniając nagłówek): 0x1EB2000,

Różnica między plikami TC jest niewielka:

Różnica wewnątrz jest jednak większa:

Konkretnie w tym przypadku po rozszyfrowaniu zmodyfikowanych zostało 128 bitów, co zresztą odpowiada rozmiarowi bloku:

Tak zmodyfikowany plik TrueCrypt można jednak swobodnie podmontować i przeglądać jego zawartość. Modyfikacja ta nie uszkodziła systemu plików, więc pliki można również porównać otwierając je z obu wersji wolumenu:

Podsumowanie: integralność i dostępność

Integralność

Pokazany eksperyment pokazuje, że umieszczenie plików w szyfrowanym kontenerze TrueCrypt daje jedynie poufność, w żaden sposób natomiast nie gwarantuje ich integralności. Co więcej, bez wykorzystania dodatkowych narzędzi (np. sumy kontrolne plików) w zasadzie nie ma możliwości, by ustalić, czy plik nie został zmodyfikowany przez niepożądaną akcję z zewnątrz. Pocieszający jest natomiast fakt, że modyfikacja taka nie zmienia zawartości pliku w sposób przewidywalny.

Ciekawe konsekwencje ma to w przypadku stosowania szyfrowania partycji systemowej. Uruchamiając system z zaszyfrowanego dysku nie można zakładać, że nie został on zmodyfikowany przez intruza, który nie zna hasła/nie posiada kluczy. Intruz taką modyfikację może wykonać. Z drugiej strony szansa, że działając w taki sposób intruz osadzi w takim systemie swój kod, który będzie działał zgodnie z jego oczekiwaniami jest... dość niska (sprawdzić, czy nie Bruce Schneier: When Bruce Schneier does a brute force search, it never needs to be exhaustive).

Zupełnie innym tematem jest kwestia ewentualnego bootkita, który zresztą został zaprezentowany już na Black Hat, prezentował go Peter Kleissner, bootkit ten nazywa się Stoned.

Innym ciekawą kwestią jest wstrzyknięcie określonego tekstu do zaszyfrowanego wolumenu. Czy jeśli w zawartości pliku TrueCrypt znajduje się jakiś tekst, to można zakładać z absolutną pewnością, że został on zapisany przez osobę znającą hasło do wolumenu? Krótka odpowiedź: nie, choć trzeba przyznać, że przypomina to trochę wyszukiwanie określonego tekstu w /dev/(a|u)random, czasami się udaje:

dd if=/dev/arandom bs=1024 count=65536 | strings | grep -i test
TesTS#6
65536+0 records in
65536+0 records out
67108864 bytes transferred in 11.035 secs (6080945 bytes/sec)

Podsumowując: szyfrowanie danych przy pomocy TrueCrypt nie gwarantuje integralności tych danych, możliwa jest modyfikacja danych/plików wewnątrz szyfrowanego kontenera, przy czym modyfikacja ta ma charakter losowy.

Dostępność

Bardziej real life problem jest dostępność danych. W tym wypadku chodzi głównie o sytuację, w której użytkownik nie może się dostać do swoich zaszyfrowanych danych. Jest do tego jak najbardziej uprawniony, zna hasło, ma zainstalowane narzędzie i... jego dane są doskonale zabezpieczone nawet przed nim.

Uszkodzenie nagłówka pliku, modyfikacja nawet jednego bitu może uniemożliwić odszyfrowanie danych. Co prawda format pliku TC uwzględnia taką sytuację i automatycznie zachowuje kopię nagłówka na końcu pliku, ale warto zrobić dodatkowy backup. Wówczas nawet w przypadku uszkodzenia pliku, istnieje duża szansa, że dane uda się odszyfrować. Można oczywiście zakładać, że przypadki losowej wartości bitów/bajtów na nośnikach współcześnie używanych nie zdarzają się, takie założenie bywa jednak ryzykowne, pisałem kiedyś o dziwnym zachowaniu jednej karty CompactFlash: Zagadka: CompactFlash, swoją drogą tego dziwnego zachowania nie udało mi się odtworzyć "w spoczynku", co może oznaczać, że problemem nie był sam nośnik, ale na przykład kontroler.

Własnoręcznie wykonana kopia nagłówka, lub skorzystanie z osadzonej w pliku kopii powoduje, że dane mogą zostać odszyfrowane, zupełnie odmienną kwestią jest to, jakie będą rezultaty tej operacji. Na przykładzie pokazałem, że zmiana nawet jednego bita w efekcie skutkuje zmianą 128 bitów (16 bajtów) w rozszyfrowanych danych. Skutki pojawienia się 128 bitów śmieci mogą być dość "interesujące", zależne na przykład od wykorzystanego systemu plików i tego, w co się trafi. Pocieszające jest to, że na podmontowanym wolumenie TC można uruchamiać dowolne narzędzia do odzyskiwania danych.

Ciekawą kwestią jest to, co się stanie, gdy uszkodzeniu ulegnie system plików, na którym zapisany jest wolumen TrueCrypt, ale o tym to może napiszę następnym razem.

Podsumowując: korzystanie z TrueCrypt może zmniejszyć dostępność danych. Uszkodzenie nagłówka pliku może spowodować, że odszyfrowanie danych będzie niemożliwe. Jeśli uszkodzony kontener uda się podmontować (zapasowy nagłówek), to odszyfrowane dane mogą być uszkodzone i, co istotne, mogą być uszkodzone "bardziej" (uszkadzane są całe bloki, na których wykonywane są operacje szyfrowania), niż gdyby nie były szyfrowane.