Czy używanie TrueCrypta jest bezpiecznie? Czy są w nim ukryte tylne furtki zainstalowane przez NSA, CIA, MOSAD, KGB czy kto wie jeszcze czyje? Czy czarne, szare i białe kapelusze mogą spać spokojnie? Dziś już jesteśmy bliżej odpowiedzi na to pytanie.
Właśnie ukazał się raport z pierwszego etapu analizy kodu źródłowego TrueCrypta, pomysłu zapoczątkowanego w październiku 2013. Pomijając zbędne budowanie napięcia przez kilka akapitów które nawet Alfred Hitchcock uważałby za nudne – ogłaszamy wszem i wobec: JEST DOBRZE.
Co udało się sprawdzić?
Na pierwszy rzut audytorzy wzięli dwa elementy: bootloader TrueCrypta oraz sterowniki pod Windows. Oprócz przeglądnięcia kodu i sposobu budowy oprogramowania dokonali oni również fuzzingu (testowanie poprzez wprowadzanie zarówno poprawnych jak i błędnych i nieoczekiwanych danych lub parametrów). Etap ten był bardzo ważny ze względu na to, że system Windows jest jedynym obsługującym i wspierającym pełne szyfrowanie dysku w TrueCrypcie oraz to, że kod który był audytowany, jest tym samym który udostępniany jest w skompilowanych plikach binarnych. Testy przeprowadzane były na udostępnianych plikach binarnych, a nie na ręcznie kompilowanej wersji.
Jakie błędy wyszły?
Mimo wielu uwag co do samej jakości kodu (w szczególności jakości (oraz braku) komentarzy), zanotowano w sumie tylko 11 błędów, z czego cztery z nich określone były jako średnio ważne, cztery o niskiej wartości i trzy informacyjne, mające jednak częściowy wpływ na całość bezpieczeństwa aplikacji.
Wśród błędów o średnim znaczeniu, znalazł się np. błąd związany z zapisaniem do pliku wymiany wrażliwych informacji (w tym informacji o kluczu), w sytuacji, gdy atakujący doprowadzi do zapełnienia pamięci operacyjnej systemu ofiary (oczywiście problem ten opisany jest w dokumentacji technicznej, gdzie należy albo wyłączyć wspomniany plik wymiany, albo przechowywać go również na zaszyfrowanej partycji). Na podobnym problemie bazuje inny błąd o tym samym znaczeniu, a jego wyeliminowanie możliwe jest poprzez zastosowanie zamiast funkcji memset() funkcji burn(), dzięki czemu można uniknąć przesunięcia nieużywanych już danych z pamięci do pliku wymiany.
Kolejnym błędem o średnim znaczeniu, był tzw. atak złej pokojówki, gdzie poprzez modyfikację kodu bootloadera możliwe jest zmuszenie go do zapisania hasła w momencie wpisywania go przez użytkownika. Problem ten związany jest głównie z kiepską jakością kodu, o której piszemy w kolejnej części.
Wskazany został również problem związany z weryfikacją nagłówka wolumenu. Obecnie zamiast zastosowania dostępnych funkcji umożliwiających weryfikację integralności oraz autentyczności zaszyfrowanych danych (HMAC), stosowany jest dosyć słaby algorytm CRC32 (na podstawie deszyfrowania czterech pierwszych bajtów zawierających słowo „TRUE”, oraz sumy kontrolnej ostatnich 256 bajtów sprawdzana jest zgodność tych danych z danymi zawartymi w 8 bajcie zaszyfrowanych danych).
Przejrzystość kodu
Audytorzy zwrócili uwagę, że o ile sama aplikacja nie posiada większych problemów, o tyle, jakość kodu, jego przejrzystość jak i sposób komentowania nie spełniają ogólnie przyjętych standardów bezpieczeństwa. W tym wypadku nie powoduje to występowania problemów, ale przywołując przypadek nginx, warto zwracać szczególną uwagę na przedziały w jakich operują zmienne, choćby po to by uniknąć błędów przepełnienia bufora.
Co dalej?
To jeszcze nie koniec prac. W kolejnej części audytu analizie zostaną poddane błędy związane z samym szyfrowaniem. Weryfikację przejdą sposoby implementacji funkcji szyfrujących dane, poprawności wykorzystania dostępnych algorytmów oraz podatności na znane metody i ścieżki deszyfrowania danych, o czym z przyjemnością napiszemy ponownie. Niech Bruce Schneier będzie z wami!
Komentarze
Kamień spadł mi z serca.
Tobie kamień z serca, a mi..
s/przeglądnięcia/przejrzenia
to synonim
Skąd mam wiedzieć, czy tego raportu nie utworzyli agenci NSA?
to jest dobre pytanie, niemniej, gdyby tak było – to firma która się pod tym podpisała, jak i osoby, byłyby skończone na rynku. Osoby które nad projektem czuwają, zdają się mieć głowę na kartu
Na dobrą sprawę najlepiej dla różnych służb specjalnych które ingerowałyby w kod byłoby samemu ogłosić audyt, a następnie wybrać do tego ludzi którzy zrobili by raport taki jaki chcą. I nie ma co gadać o „spaleniu w branży” bo tacy ludzie mogliby pracować później dla rządu…
Oczywiście jest to tylko paranoiczna teoria, bo wątpię aby NSA czy innym służbą opłacało się wprowadzanie backdoorów w TC – znając życie to mają lepsze sposoby na zdobycie tego co chcą.
Jak nie TC to co?
chowaj bajty w skarpecie.
To chociażby: https://diskcryptor.net
Można mieć te same zastrzeżenia co do TC i choć pochodzi od „ruskich” to jest to jakaś alternatywa.
safeguard
Nie „wszem i wobec”. Poprawnie jest „wszem wobec”.
http://poradnia.pwn.pl/lista.php?id=1287
Zapytam z ciekawości. Czy TC działa sam na sobie? Nie odwołuje się do niczego i z niczego nie korzysta (oczywiście poza wymienionym juz plikiem wymiany)?
A pułapki hardwarowe, jakiś chip np. TPM też przetestują?
A ja szygruję rotem13, a potem, dla pewności jeszcze raz pliki w środku. ;-D
To jak bezpieczny jest TC zależy od tego kto pierwszy podaje publicznie informacje z testów i na ile (i czy w ogóle) tester jest w 100% instytucjonalnie niezależny.
Nie „przeglądnięcia” tylko „przejrzenia”.
Posłuchaj może Bralczyka.
http://jerzybralczyk.bloog.pl/id,337545443,title,Rozne-roznosci,index.html